Help Center/ TaurusDB/ User Guide/ RegionlessDB Clusters (OBT)/ Using a RegionlessDB Cluster for Remote Multi-Active DR

Updated on 2026-02-14 GMT+08:00

View PDF

Using a RegionlessDB Cluster for Remote Multi-Active DR

Scenarios

If your workloads are deployed in multiple regions, you can create a RegionlessDB cluster to access databases from the nearest region. As shown in Figure 1, a RegionlessDB cluster contains a primary instance and two standby instances. The primary instance receives and processes read and write requests, while the standby instances receive only read requests. After write forwarding is enabled, the standby instances can receive write requests and then forward them to the primary instance for processing. After data is written to the primary instance, the data is synchronized to the standby instances, reducing the cross-region network latency. Write forwarding simplifies the data write process. You can directly connect a database service through a standby instance's IP address to perform read and write operations. In addition, consistency is ensured and the nearby read is not affected.

Figure 1 Remote multi-active principle

RegionlessDB Cluster Constraints

For details, see Constraints.

Write Forwarding Constraints

When write forwarding is enabled, user _@gdb_WriteForward@_ is created. Do not modify or delete the user, or write forwarding cannot run properly.
For commands that can be implicitly committed, if write forwarding is not supported, the transactions corresponding to the current node and primary node are automatically committed.
For the global consistency level, before accessing data for the first time, each transaction needs to use a connection in the session pool to obtain a data point (LSN) from the primary node. If no sessions are available, the command for reading data may fail.
If there is a connection error when a user uses a session for write forwarding and the user is in a multi-statement transaction, the server proactively closes the connections to the client and the primary node, ensuring that the client can detect the error.
The versions of the primary and standby instances must be the latest.
Write operations are finally forwarded to and processed by the primary node. If a temporary table with the same name exists in the given database of the primary and read replicas, the data on the primary node is used.
If there is a failover for a standby instance in a RegionlessDB cluster, the write forwarding parameters (rds_open_write_forwarding and rds_write_forward_read_consistency) are restored to the default values.

Table 1 lists all supported and unsupported scenarios.

**Table 1** Scenarios supported and not supported by write forwarding
Constraints	Description
Supported scenarios	Write forwarding is only available when the transaction isolation level of the standby instances is RR. Write forwarding supports the following commands: SQLCOM_UPDATE SQLCOM_INSERT SQLCOM_DELETE SQLCOM_INSERT_SELECT SQLCOM_REPLACE SQLCOM_REPLACE_SELECT SQLCOM_DELETE_MULTI SQLCOM_UPDATE_MULTI SQLCOM_ROLLBACK If an unsupported command is executed, the following error information is displayed. ERROR xxx (yyy): This version of MySQL doesn't yet support 'operation with write forwarding'. operation indicates the operation type that is not supported.
Unsupported scenarios	In the current version, WARNING and RECORD information cannot be displayed when a standby instance forwards write requests. In the current version, SQL requests that are being executed cannot be interrupted when a standby instance forwards write requests. SELECT FOR UPDATE statements are not supported. EXPLAIN write forwarding statements are not supported. The statements for write forwarding cannot contain SET VARIABLE. SAVEPOINT is not supported when write forwarding is enabled. Write forwarding is not supported in XA transactions. Currently, START TRANSACTION READ WRITE is not supported. You can directly use START TRANSACTION to test write forwarding. Write forwarding is not supported in stored procedures. When write forwarding is enabled, temporary tables cannot be created. To create temporary tables, disable write forwarding temporarily.

Procedure

Step 1: Create a RegionlessDB Cluster

Log in to the TaurusDB console.
Click in the upper left corner and select a region and project.
On the RegionlessDB page, click Create RegionlessDB in the upper right corner.
Figure 2 Creating a RegionlessDB cluster

In the Create RegionlessDB dialog box, configure RegionlessDB Name, Primary Instance Region, and Primary Instance.

Figure 3 Configuring the RegionlessDB cluster information
Click to enlarge

**Table 2** Parameter description
Parameter	Description
RegionlessDB Name	The name must start with a letter and consist of 4 to 64 characters. Only letters (case-sensitive), digits, hyphens (-), and underscores (_) are allowed.
Primary Instance Region	Select a region where the primary instance is located.
Primary Instance	Select an existing pay-per-use or yearly/monthly instance as the primary instance of the RegionlessDB cluster.

Click OK.
After the primary instance is created, view and manage it.
During the creation process, the instance status is Creating. To view the detailed progress and result of the creation, go to the Task Center page. After the status of the primary instance is Available, you can use the instance.

Step 2: Add a Standby Instance

On the RegionlessDB page, locate the RegionlessDB cluster.
Click Add Standby Instance in the Operation column.
Figure 4 Adding a standby instance

On the displayed page, configure related parameters.

**Table 3** Basic information
Parameter	Description
Billing Mode	Yearly/Monthly: a prepaid billing mode in which you pay for resources before using them. Bills are settled based on the subscription period. The longer the subscription, the bigger the discount. This mode is a good option for long-term, stable workloads. Pay-per-use: a postpaid billing mode. You pay as you go and just pay for what you use. The prices are calculated by the second but billed every hour. This mode allows you to adjust resource usage easily. You neither need to prepare for resources in advance, nor end up with excessive or insufficient preset resources.
Region	Region where the standby instance is deployed. Products in different regions cannot communicate with each other through a private network. After a DB instance is purchased, the region cannot be changed.
Creation Method	Create new
DB Instance Name	The name must start with a letter and consist of 4 to 64 characters. Only letters, digits, hyphens (-), and underscores (_) are allowed.
DB Engine	TaurusDB
Kernel Version	Kernel version of the standby instance. It must be 2.0.54.240600 or later. For details about the updates in each kernel version, see TaurusDB Kernel Version Release History. NOTE: To specify the kernel version, submit a service ticket.
DB Instance Type	Only Cluster can be selected. There are 2 to 10 read replicas in a cluster instance in the RegionlessDB cluster.
Storage Type	Shared
AZ Type	An AZ is a physical region where resources have their own independent power supply and networks. AZs are physically isolated but interconnected through an internal network. Some regions support both single-AZ and multi-AZ deployment and some only support single-AZ deployment. Single AZ: The primary node and read replicas are deployed in the same AZ. Multi-AZ: The primary node and read replicas are deployed in different AZs to ensure high reliability.
Time Zone	You need to select a time zone for your instance based on the region hosting your instance. The time zone is selected during instance creation and cannot be changed after the instance is created.
Instance Specifications	For details about the specifications supported by TaurusDB, see Instance Specifications. TaurusDB is a cloud-native database that uses the shared storage. To ensure workload stability in high read/write pressure, the system controls the read/write peaks of DB instances based on instance specifications. For details about how to select instance specifications, see Performance White Paper.
CPU Architecture	The CPU architecture can be x86 or Kunpeng. Under a CPU architecture, you need to select vCPUs and memory of the instance.
Nodes	All nodes of the standby instance are read replicas. You can apply for a maximum of 10 read replicas at once for a pay-per-use instance. After an instance is created, you can add read replicas as required. Up to 15 read replicas can be created for a standby instance in a cluster.
Storage	Storage will be scaled up dynamically based on the amount of data that needs to be stored, and is billed hourly on a pay-per-use basis.
VPC	A dedicated virtual network in which your TaurusDB instance is located. It isolates networks for different workloads. You can select an existing VPC or create a VPC. For details about how to create a VPC, see Creating a VPC. If no VPC is available, TaurusDB allocates a VPC to you by default. CAUTION: Ensure that the VPC selected for the standby instance is connected to the VPC selected for the primary instance through a VPN. After a TaurusDB instance is created, the VPC cannot be changed. A subnet provides dedicated network resources that are logically isolated from other networks for network security. A private IP address is automatically assigned when you create a DB instance. You can also enter an idle private IP address in the subnet CIDR block.
Security Group	It can enhance security by controlling access to TaurusDB from other services. When you select a security group, you must ensure that it allows the client to access instances. If no security group is available or has been created, TaurusDB allocates a security group to you by default. To ensure subsequent database connection and access, you need to allow all IP addresses to access your DB instance through port 3306 and over ICMP. Configure private network security group rules to ensure that the primary and standby instances in a cluster can communicate with each other.
Parameter Template	Contains engine configuration values that can be applied to one or more instances. You can modify the instance parameters as required after the instance is created. If you use a custom parameter template when creating a DB instance, the specification-related parameters in the custom template will not be applied. Instead, the default values are used. For details, see What Parameters Should I Pay Attention to When Creating a DB Instance? After a DB instance is created, you can adjust its parameters as needed. For details, see Modifying Parameters in a Parameter Template.
Enterprise Project	An enterprise project provides a way to manage cloud resources and enterprise members on a project-by-project basis. You can select an enterprise project from the drop-down list. The default project is default. To create an enterprise project, click Enterprise > Project Management in the upper right corner of the console. For details, see Creating an Enterprise Project.
Tag	This parameter is optional. Adding tags helps you better identify and manage your DB instances. Each DB instance can have up to 20 tags. After a DB instance is created, you can view its tag details on the Tags tab. For details, see Tag Management.

The instance password and table name case sensitivity are the same as those of the primary instance. You do not need to set them separately.

Click Next.
Confirm the information and click Submit.
Go to the Instances page to view and manage the instance.
During the creation process, the instance status is Creating. To view the detailed progress and result of the creation, go to the Task Center page. After the status of the instance is Available, you can use the instance.

If there is a large amount of data in the primary instance, it may take a long time to complete a full backup during standby instance creation.

Step 3: Enable Write Forwarding

On the RegionlessDB page, locate the RegionlessDB cluster.
Click Set Write Forwarding in the Operation column to create a write forwarding account.

Figure 5 Creating a write forwarding account

The system automatically creates an internal account (_@gdb_WriteForward@_) so that write requests can be forwarded to the primary instance for processing. You cannot modify or delete the internal account, or write forwarding will be affected.
In the Set Write Forwarding dialog box, confirm the information and click OK.

Figure 6 Setting write forwarding
On the Instances page, click the name of the standby instance in the RegionlessDB cluster.
In the navigation pane, choose Parameters.
Search for rds_open_write_forwarding in the upper right corner of the Parameters page and change its value to ON.
Click Save in the upper left corner to enable write forwarding.

Search for rds_write_forward_read_consistency in the upper right corner of the Parameters page and change the read consistency level of write forwarding.

You can modify the parameters to set the read consistency range. For details, see Table 4.

If read consistency is required, you are advised to set the consistency level to SESSION. The consistency level GLOBAL will cause a large extra cost for all read requests. For example, if any client is used to connect to TaurusDB and the GLOBAL level is used, the time for accessing the MySQL command line is prolonged.
The read consistency level in write forwarding cannot be changed to SESSION in a transaction.
Before enabling write forwarding, ensure that the transaction isolation levels of standby instances are RR.
When write forwarding is enabled, the transaction isolation level of the current session cannot be changed.
The read consistency level cannot be changed within a transaction.

**Table 4** Parameter description
Parameter	Description
NONE	Write forwarding is disabled.
EVENTUAL	Results of write operations are not visible until the write operations are performed on the primary instance. The query does not wait for data synchronization between primary and standby instances to complete, so data that is not updated may be read.
SESSION	All queries executed by a standby instance with write forwarding enabled see the results of all data writes performed in this session. The queries wait for the results of forwarded write operations to be replicated.
GLOBAL	A session can view all committed changes of all sessions and instances in a RegionlessDB cluster. The query may wait for a certain period, which is related to the replication latency.

Click Save in the upper left corner.

Step 4: Connect to the RegionlessDB Cluster for Service Management

After a RegionlessDB cluster is created, no unified connection address is provided. The primary and standby instances in the RegionlessDB cluster provide independent connection addresses. You can use the nearest primary or standby instance based on the service access region to connect to the RegionlessDB cluster. The RegionlessDB cluster automatically forwards write requests to the primary instance for processing and read requests to the instance of the nearest region for processing.

Example:

Connect to the primary instance and write data to the database.

mysql> CREATE DATABASE mydatabase;
mysql> CREATE TABLE orders (order_id INT PRIMARY KEY, customer_name VARCHAR(255), order_date DATE);
mysql> INSERT INTO orders (order_id, customer_name, order_date) VALUES (1, 'UserA', '2023-12-18'), (2, 'UserB', '2023-12-17'), (3, 'UserC', '2023-12-16');

Use the nearest standby instance to access the database and query the data written in 1.

mysql> select * from mydatabase.orders;
+----------+---------------+------------+
| order_id | customer_name | order_date |
+----------+---------------+------------+
|        1 | UserA         | 2023-12-18 |
|        2 | UserB         | 2023-12-17 |
|        3 | UserC         | 2023-12-16 |
+----------+---------------+------------+

Connect to database through the primary instance and run the following SQL statements to create the mydatabase database and orders table.

mysql> CREATE DATABASE mydatabase;
Query OK, 1 row affected (0.00 sec)
mysql> USE mydatabase;
Database changed
mysql> CREATE TABLE orders (order_id INT PRIMARY KEY, customer_name VARCHAR(255), order_date DATE);
Query OK, 0 rows affected (0.01 sec)

Connect to the database from a standby instance, run the following SQL statements to write three data records to the orders table, and query the written data.

mysql> INSERT INTO orders (order_id, customer_name, order_date) VALUES (1, 'UserA', '2023-12-18'), (2, 'UserB', '2023-12-17'), (3, 'UserC', '2023-12-16');
Query OK, 3 rows affected (0.00 sec)
mysql> SELECT * FROM mydatabase.orders;
+----------+---------------+------------+
| order_id | customer_name | order_date |
+----------+---------------+------------+
|        1 | UserA         | 2023-12-18 |
|        2 | UserB         | 2023-12-17 |
|        3 | UserC         | 2023-12-16 |
+----------+---------------+------------+
3 rows in set (0.01 sec)

Connect to the database through the primary instance and run the following SQL statements to query the data inserted by the standby instance in 4.

mysql> SELECT * FROM mydatabase.orders;
+----------+---------------+------------+
| order_id | customer_name | order_date |
+----------+---------------+------------+
|        1 | UserA         | 2023-12-18 |
|        2 | UserB         | 2023-12-17 |
|        3 | UserC         | 2023-12-16 |
+----------+---------------+------------+
3 rows in set (0.00 sec)

Parent Topic: RegionlessDB Clusters (OBT)

Previous topic: Introduction to RegionlessDB Clusters

Next topic: Using a RegionlessDB Cluster for Remote DR