Lindorm multi-zone deployment distributes replicas across zones for data-center or city-level disaster recovery, with strong or eventual consistency per table. Failover is automatic.
Features
For workloads that require resilience against server failures, network outages, or city-level disasters, multi-zone deployment provides:
-
Disaster recovery at the data center or city level.
-
Support for both strong and eventual data consistency.
-
Automatic fault detection and failover without manual intervention.
Limitations
-
Open-source clients, such as the HBase client, do not support multi-zone deployment.
-
Multi-zone deployment applies only to LindormTable. LindormTable features such as secondary indexes, dynamic columns, and wildcard columns are supported. Engine-dependent features such as search indexes and columnar indexes are not.
-
Cold storage and hot-cold data separation are not supported.
How multi-zone deployment works
In a multi-zone deployment, each wide table partition has an independent replica in every zone. Lindorm synchronizes replicas through its consensus protocol, which requires data from at least two replicas. Write-ahead log (WAL) entries are stored in LindormDFS in Zone C. If Zone A fails, the WAL in Zone C restores data to Zone B.
Lindorm supports two consistency levels: strong and eventual. Configure each table to match your requirements.
Strong consistency
With strong consistency, all reads and writes go through the primary partition. Secondary partitions receive data through the consensus protocol. Reads always return the most recently written data.
If all servers in the primary zone are terminated or the zone becomes unavailable, Lindorm automatically promotes a secondary zone. A brief transition period is required.
Eventual consistency
Eventual consistency allows reads and writes on both primary and secondary partitions. Data synchronizes across zones asynchronously, typically within 100 ms.
Clients read and write in the nearest zone. If read and write clients are in the same zone, they always see the latest data. When a zone becomes unavailable, Lindorm routes requests to an available zone without waiting for promotion, reducing latency spikes.
Choosing the right consistency level
New tables default to eventual consistency, which suits most workloads:
-
Data written within the last 100 ms can typically be read.
-
Clients can read and write from the nearest zone.
-
Local partitions remain available during transient disruptions or server shutdowns.
Choose strong consistency if you need:
-
Immediate read-after-write consistency.
-
Atomic operations such as Increment and CheckAndPut.
-
Secondary indexes on the table.
Note In strong consistency mode, all reads go through the primary partition and cannot be distributed across replicas. If the primary zone fails, promoting a secondary zone takes time.
Architecture comparison
Traditional primary/secondary disaster recovery
In traditional primary/secondary disaster recovery, two instances are deployed in separate zones. Lindorm Tunnel Service (LTS) synchronizes data bidirectionally. When the primary instance or zone fails, you manually switch to the secondary.
This approach has several drawbacks:
-
No strong data consistency. Inter-instance synchronization is asynchronous. During failover, the secondary may lack the latest data. Atomic operations such as Increment and CheckAndPut may produce out-of-order or rolled-back results. Network issues in the primary zone leave the secondary incomplete until recovery.
-
Low resource utilization. The secondary instance sits idle except during failover.
-
Manual failover required. You must monitor the primary instance and implement your own failover logic.
Multi-zone deployment resolves these issues.
Feature comparison
The following table compares multi-zone deployment, primary/secondary disaster recovery, and Paxos/Raft-based protocols.
| Feature | Multi-zone high-availability deployment | Primary/secondary disaster recovery | Paxos-based or Raft-based consensus protocol | |
|---|---|---|---|---|
| Strong consistency | Eventual consistency | |||
| Data loss (RPO) | 0 | < 100 ms | < 1s | 0 |
| Service recovery (RTO) | 1 minute | 10s to 30s | Depends on failover time | 30 seconds to 3 minutes |
| Access response time | Access data in the primary zone. Reads and writes may cross zones. | Access data in the nearest zone. Reads and writes go to multiple zones, reducing latency spikes. | Access data in the primary zone. Reads and writes may cross zones. | Access data in the primary zone. Reads and writes may cross zones. |
| Ease of use | No impact on business applications. | No impact on business applications. | Requires application changes. Uses an external synchronization link that you manage. | No impact on business applications. |
| Minimum number of zones for logs | 3 | 2 | 2 | 3 |
| Minimum number of zones for data | 2 | 2 | 2 | 3 |
Compared with the alternatives, multi-zone deployment offers more flexible data access, shorter recovery time, and greater ease of use.
Note Lindorm handles fault detection and failover automatically for all wide tables, regardless of consistency level. Connect to a single instance; no middleware is needed. If your workload does not require strong consistency, use eventual consistency for lower latency. If your workload requires strong consistency, set the table consistency level to strong.
Purchase a multi-zone Lindorm instance
To purchase a multi-zone instance, create an instance in the Lindorm console.
Use a multi-zone Lindorm instance
Create a table and configure the consistency level
Note The HBase API and HBase Shell do not ensure data consistency. Tables created through the HBase API or HBase Shell default to eventual consistency. Modify the CONSISTENCY attribute as described below.
-
Connect to LindormTable with Lindorm-cli. Use Lindorm-cli to connect to and use LindormTable.
-
Configure the CONSISTENCY attribute for the table.
-
Create a table with strong consistency: ``
CREATE TABLE dt ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='strong');`` -
Create a table with eventual consistency: ``
CREATE TABLE dt2 ( p1 INT, p2 INT, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1) ) WITH (CONSISTENCY='eventual');`` -
Change a table to eventual consistency: ``
ALTER TABLE dt SET CONSISTENCY='eventual';`` -
Change a table to strong consistency: ``
ALTER TABLE dt2 SET CONSISTENCY='strong';``
-
Write data to a wide table
Writing data to a multi-zone instance works the same as a single-zone instance. Use Lindorm-cli to connect to and use LindormTable.
Import data to a wide table
-
To import data through an API, use the instance endpoint from the Lindorm console. The process is the same for multi-zone instances.
-
With BulkLoad, import a copy of data in each zone. Contact technical support for assistance.