PolarDB:Add and manage a secondary cluster

Prerequisites

Before you begin, ensure that you have:

• A GDN. See Create a global database network

Supported regions

Secondary clusters can be added in the following regions: all regions in the Chinese mainland, China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London).

Limitations

GDN composition

• A GDN supports one primary cluster and up to four secondary clusters.

  To increase this limit, go to Quota Center, find quota ID polardb_mysql_gdn_region, and click Apply in the Actions column.

• A cluster can belong to only one GDN.

• Only new clusters can be added as secondary clusters. Existing clusters cannot be added.

Version and engine requirements

• Primary and secondary clusters must use the same database engine version: MySQL 8.0, MySQL 5.7, or MySQL 5.6.

Node requirements

• Non-serverless secondary clusters: each compute node must have at least 4 CPU cores.

• Each cluster in a GDN contains 2 nodes by default and supports up to 16 nodes.

In-Memory Column Index (IMCI)

GDN clusters support the In-Memory Column Index (IMCI) feature. To add a read-only column store node, enable the loose_polar_enable_imci_with_standby cluster parameter first. The cluster version must also meet one of the following requirements:

• MySQL 8.0.1 with revision version 8.0.1.1.48 or later

• MySQL 8.0.2 with revision version 8.0.2.2.27 or later

Serverless clusters

GDN clusters can be serverless clusters or fixed-specification clusters with the serverless feature enabled. If the primary cluster's minor engine version is earlier than the following versions, all GDN clusters must have at least one read-only node:

• MySQL 8.0.1 earlier than 8.0.1.1.42

• MySQL 8.0.2 earlier than 8.0.2.2.23

Unsupported features

• Database and table restoration is not supported for GDN clusters.

Billing

GDN costs include the cluster fees and inter-region data transfer fees. Transfer fees depend on whether replication crosses the border between the Chinese mainland and other regions.

Cross-border fees are calculated based on the amount of redo log data physically replicated from the primary cluster to the cross-border secondary cluster each hour. Estimate this traffic by querying the physical position converted from the log sequence number (LSN).

<details> <summary>View a billing example</summary>

Example

At 09:00, you query the log write position and it is ib_logfile1/648143676. At 10:00, it is ib_logfile3/648142342. Each log file is 1 GB (1,073,741,824 bytes). The amount of data written in this hour is:

1. Written to ib_logfile1 (start file): 1,073,741,824 - 648,143,676 = 425,598,148 bytes

2. Written to ib_logfile2 (intermediate file): 1,073,741,824 bytes (entire file)

3. Written to ib_logfile3 (end file): 648,142,342 bytes

Total: 425,598,148 + 1,073,741,824 + 648,142,342 = 2,147,482,314 bytes, approximately 1.999998 GB

Cross-border transfer fee for this hour: 1.999998 GB x USD 0.80/GB = approximately USD 1.5999984

Query the log write position

-- Query the current write progress of the log system.
SHOW STATUS LIKE 'Innodb_log_write_lsn';
+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| Innodb_log_write_lsn | 1721889596 |
+----------------------+------------+

-- Query the physical file offset in bytes.
SELECT lsn_to_pos(1721889596);
+------------------------+
| lsn_to_pos(1721889596) |
+------------------------+
| ib_logfile1/648143676  |
+------------------------+

</details>

If you use the global domain name feature, additional fees apply for PrivateZone DNS resolution and inter-region data transfer. For details, see Global domain name pricing.

Usage notes

A GDN synchronizes data using physical replication based on redo logs, so redo logsbinary logging is not required by default. If your workload requires binlog synchronization between clusters (for example, for change tracking), the loose_polar_log_bin parameter must be identical on the primary and all secondary clusters. A mismatch can cause binlog data inconsistency after a primary/secondary switchover.

Add a secondary cluster

A GDN supports cross-border secondary clusters using China Unicom's Express Connect and Cloud Enterprise Network (CEN). A configuration is cross-border when the primary and secondary clusters are in different types of regions:

• Chinese mainland regions: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Heyuan), China (Guangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), and China (Chengdu)

• Other regions: China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Germany (Frankfurt), US (Silicon Valley), US (Virginia), and UK (London)

Remove a secondary cluster

1. Log on to the PolarDB console. In the left navigation pane, click Global Database Network.

2. On the GDN page, find the target GDN and click its GDN ID/Name to open the details page.

3. In the Clusters section, find the target secondary cluster and click Remove in the Actions column.

   

4. In the dialog box, read the notes and click OK.

The removal process takes approximately 5 minutes. After it completes:

• The removed cluster stops receiving data from the primary cluster.

• The cluster becomes a standalone PolarDB cluster in read/write mode.

• During the removal process, all cluster endpoints in the GDN remain available.

Only secondary clusters can be removed. The primary cluster cannot be removed from a GDN.

Switch the primary cluster

Use a primary/secondary switchover to promote a secondary cluster to primary.

1. Log on to the PolarDB console. In the left navigation pane, click Global Database Network.

2. On the GDN page, find the target GDN and click its GDN ID/Name to open the details page.

3. In the Clusters section, find the secondary cluster to promote and click Switch to Primary Cluster in the Actions column.

   

4. In the Primary/Secondary Switchover dialog box, select the ID of the secondary cluster to promote and click OK.

A switchover typically completes in less than 5 minutes, with a maximum of 10 minutes. During the switchover, a transient disconnection of up to 160 seconds may occur. Perform this operation during off-peak hours and make sure your application has a reconnection mechanism.

Recreate a secondary cluster

Recreating a secondary cluster rebuilds it from the primary cluster. Use this operation in the following situations:

• A secondary cluster fails and cannot be recovered.

• The secondary cluster's data has been out of sync with the primary cluster for an extended period.

• The underlying configuration or environment of the secondary cluster needs to be updated.

1. Log on to the PolarDB console. In the left navigation pane, click Global Database Network.

2. On the GDN page, find the target GDN and click its GDN ID/Name to open the details page.

3. In the Clusters section, find the target secondary cluster and click Recreate Secondary Cluster in the Actions column.

   

4. In the dialog box, read the notes and click OK.

FAQ

Next steps

• Connect to a global database network: Connect to your GDN after adding secondary clusters.

• Create a global domain name: Set up a unified endpoint that provides nearest-region access and remains unchanged after a primary cluster switchover.

API reference