Tablestore:Global tables

How it works

Global Tables use Tablestore's multi-region replication technology to create data synchronization channels between instances in different regions. When data in a table in one region changes, the change is automatically synchronized to replica tables in other regions. This process ensures cross-region data consistency. You can dynamically add or remove table replicas across different instances and regions.

The entire replication process runs automatically in the background without manual intervention. This mechanism achieves an acceptable recovery point objective (RPO) while ensuring data consistency. It effectively meets the disaster recovery and business continuity requirements of most business systems.

For daily use, users or applications can access the nearest replica for read and write operations. This significantly reduces access latency. In the event of a regional failure or a major disaster, such as a data center outage or natural disaster, you can quickly initiate a disaster recovery switchover using the multiple replicas. This helps you rebuild critical applications and data, ensuring business continuity.

Features

Scenarios

Global Tables are suitable for business scenarios that require high availability, low-latency cross-region reads and writes, and cross-region disaster recovery. Typical scenarios are as follows:

• Cross-region backup: If the primary region fails, you can switch to the secondary region to continue providing read services and ensure business continuity. For example, an e-commerce system stores its primary user tables in a Tablestore instance in the China (Hangzhou) region and a replica table in the China (Beijing) region. If the China (Hangzhou) region fails, the instance in China (Beijing) continues to provide query services.

• Write in one region, read in multiple regions: Write data to the nearest region and read it from other nearby regions. This is suitable for scenarios that require accelerated remote access. For example, the primary write operations for a service are directed to the China (Hangzhou) region. Read-only replicas are deployed in the China (Beijing) and China (Ulanqab) regions to meet the demand for low-latency cross-region reads.

Global Table region support: Global Tables are currently supported in the China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Guangzhou), and China (Chengdu) regions.

Create a global table

Activate the service and create an instance. Create instances in both the primary region and the target replica region.

Read and write data in a global table

Reading and writing data in the replica tables of a global table is the same as reading data and writing data in a standard data table.

• To read data, use the Endpoint of the instance where the corresponding replica table is located.

• In active-passive mode, only the primary replica allows writes through the Endpoint of its instance. Other replicas are read-only, except during an active-passive switchover.

Modify the active-passive relationship

In active-passive mode, if the primary replica table fails or the application layer needs to switch the write region, you can set another replica table as the new primary to continue providing services.

1. On the Global Table tab, click Switch to Primary Table in the Actions column of the passive table.

2. In the Modify Active-Passive Relationship dialog box, submit the primary table switchover task and start data synchronization.

   Important

   Data synchronization will continue. The duration depends on the data volume, system resources, and other factors. During data synchronization, both the primary replica table and the replica table selected as the new primary are writable. This may pose a risk of data inconsistency.

   1. In the Data Synchronization step, click Start Data Synchronization.

      

   2. In the Active-Passive Table Switchover dialog box, click View Details to check the RPO status of the data synchronization.

3. Switch the application layer write path.

   Confirm that the data in the primary and passive tables is consistent before switching the application layer write path.

   1. Click Confirm Write Path Switch in the Synchronization Mode column of any table.

   2. In the Application Layer Write Path Switch step, confirm that data synchronization is complete and that you have changed all write endpoints in your application to the new primary's Endpoint. Then, click Write Path Switched.

      

4. Confirm the switch to the primary table.

   After switching the write path, confirm the primary table switch as soon as possible.

   Important

   After this operation, the write capability of the original primary table will be disabled.

   1. Click View in the Synchronization Mode column of any table.

   2. In the Confirm Switch to Primary Table step, click Synchronization Complete, Switch to Primary Table Now.

      Note

      To cancel the active-passive table switchover, click Cancel Primary Table Switch and complete the cancellation confirmation.

      

   3. In the confirmation dialog box, click OK.

      After the modification is successful, the original primary replica will become read-only, and the new primary replica will provide read and write capabilities.

Add a global region

Add one or more global regions to a global table.

1. On the Global Table tab, click Add Global Region in the Actions column of the replica table.

2. In the Add Global Region dialog box, select the region and instance name of the destination instance.

   To add multiple global regions, click Add Instance and continue.

   Note

   If a data table with the same name as the global table already exists in the destination instance, adding the global region will fail.

3. Click OK.

Remove synchronization

Remove the synchronization relationship for a global table.

1. On the Global Table tab, choose one of the following methods to start removing the synchronization relationship.

   • Remove a single replica: Click Remove Synchronization in the Actions column of the replica table.

   • Remove multiple replicas in a batch: Select the replica tables to be removed, and click Remove Synchronization below the list.

2. In the confirmation dialog box, click OK.

Developer integration

You can use global tables with the Java SDK.

Going live

• Recommendations for global table operations

  • Create a global table for an existing table: The original read and write APIs remain unchanged. Data is automatically synchronized to the new replica. The new replica can share the read load.

  • Create a new global table from scratch: Determine the table schema, create the base table, and then create the global table. Global tables do not support modifying the table schema. Make sure the base table passes all tests before creating the global table.

  • Dynamically attach a new replica: While using a global table, you can dynamically add new replicas without affecting the read and write operations of existing replicas. The new replica will have the latest data from the global table.

  • Detach existing replicas: If a replica table is no longer needed, you can detach it first. After detaching, the replica will no longer synchronize data from other replicas, but the table and its data are retained. To delete the replica, you must manually delete it after detaching it.

• Choose a reasonable region combination: Select appropriate primary and secondary regions based on user distribution and business needs.

• Primary region failover: In active-passive mode, if the primary region becomes unavailable, you can first select a new primary replica table in the console, then switch the application's write path. Wait for the data to synchronize to the new primary replica table, and then promote it to the primary replica table. There may be a brief write interruption during the switchover. We recommend implementing a retry mechanism on the business side.

  Important

  Your business application should manage the order and timing of application and service switchovers to prevent data loss.

Billing

Global tables incur fees for data storage, data reads, data writes, and cross-region replication traffic.

The fees are described as follows:

• Data storage fee: Each replica table stores data independently. You are billed separately for the actual amount of data stored in each table's region.

• Data read fee: This fee is for local read operations on all replica tables.

• Data write fee: Write operations can be performed only on writable replicas. Write fees are incurred only on the table to which data is directly written. Replica tables that synchronize data through asynchronous replication do not incur write fees.

• Cross-region replication traffic fee: This fee is charged for the cross-region data transfer traffic that is generated when data is asynchronously replicated to each replica table.

  Important

  The cross-region replication traffic fee for each replica is calculated separately. The fee is charged to the instance from which the data is pulled.

FAQ