PolarDB:Add and manage secondary clusters

Pricing

Charges for a Global Database Network (GDN) consist of the cluster costs and any applicable cross-border data replication fees. The billing rules are as follows:

• Free scenarios:

  Your primary and secondary clusters are both deployed in regions within the Chinese mainland, or both are deployed in the China (Hong Kong) region or other overseas regions. Examples:

  • Both the primary and secondary clusters are in the Chinese mainland. For example, the primary cluster is in China (Chengdu) and the secondary clusters are in regions such as China (Hangzhou) or China (Shenzhen).

  • Both the primary and secondary clusters are in the China (Hong Kong) region or other overseas regions. For example, the primary cluster is in Singapore and the secondary cluster is in Philippines (Manila).

• Billable scenarios:

  Cross-border fees apply when a GDN spans the Chinese mainland border—for example, if one cluster is in the Chinese mainland and another is in China (Hong Kong) or an overseas region. Examples:

  • The primary cluster is in the Chinese mainland and the secondary cluster is outside the Chinese mainland. For example, the primary cluster is in China (Chengdu) and the secondary cluster is in a region such as China (Hong Kong) or Singapore.

  • The primary cluster is outside the Chinese mainland and the secondary cluster is in the Chinese mainland. For example, the primary cluster is in Singapore and the secondary cluster is in a region such as China (Hangzhou) or China (Shenzhen).

• Billing rule: USD 0.80 per GB, billed hourly. The fee is calculated hourly based on the volume of redo log data physically replicated from the primary cluster to a cross-border secondary cluster. This traffic fee can be estimated by querying the physical position converted from the log sequence number (LSN).

  Billing example

  Example

  At 09:00, you query the physical write position of the log and find it is ib_logfile1/648143676. At 10:00, the position is updated to ib_logfile3/648142342. The amount of data written in this hour is the difference between the two positions.

  1. Amount written to the start file (ib_logfile1):
     Subtract the start offset from the total file size. Each log file is 1 GB (1,073,741,824 bytes). The amount written is 1073741824 - 648143676 = 425598148 bytes.
     
     
     
     

  2. Amount written to the intermediate file (ib_logfile2):
     After ib_logfile1 is full, the system completely writes ib_logfile2. This amount is 1,073,741,824 bytes (1 GB).
     
     
     
     

  3. Amount written to the end file (ib_logfile3):
     This is the offset at the end, which is 648142342 bytes.
     
     
     
     

  Therefore, the total amount written is 425598148 + 1073741824 + 648142342 = 2147482314 bytes. This is 2147482314 / 1024 / 1024 / 1024 = 1.999998 GB (rounded down to six decimal places). The cross-border data transfer fee for this hour is approximately 1.999998 GB × USD 0.80/GB = USD 1.5999984.

  Query the log write progress and physical file offset

  -- 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  |
  +------------------------+

Usage notes

A Global Database Network (GDN) synchronizes data by using a physical replication mechanism based on redo logs. Therefore, enabling the binary log is not required by default. If your workload requires binary log synchronization between clusters (for example, for data subscription), you must ensure that the binary log parameter (loose_polar_log_bin) is configured identically on the primary and secondary clusters. Otherwise, you risk binary log data inconsistency after a primary/secondary switchover.

Add a secondary cluster

A Global Database Network (GDN) uses China Unicom's cross-border Express Connect and cross-border Cloud Enterprise Network (CEN) to support adding cross-border secondary clusters. A configuration is cross-border when the primary and secondary clusters are in different types of regions, as defined below. Adding a cross-border secondary cluster requires additional preparation.

• Chinese mainland: 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-side navigation pane, click Global Database Network (GDN).

2. On the Global Database Network (GDN) page, find the target GDN and click its GDN ID to go to the details page.

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

   Note

   • The removal process takes about five minutes.

   • During the removal process, all cluster connection endpoints in the GDN, including those of the cluster being removed, remain available for normal database access.

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

   • After a secondary cluster is removed from a GDN, it stops synchronizing data with the primary cluster and is set to read/write mode.

   • After a cluster is removed from a GDN, it cannot be re-added as a secondary cluster. Perform this action with caution.

4. Read the notes in the pop-up dialog box carefully, then click OK to remove the secondary cluster.

Switch the primary cluster

1. Log on to the PolarDB console. In the left-side navigation pane, click Global Database Network (GDN).

2. On the Global Database Network (GDN) page, find the target GDN and click its GDN ID to go to the details page.

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

4. In the Primary/Secondary Switchover dialog box, select the secondary cluster to become the new primary cluster and click OK.

   Note

   • A primary/secondary switchover does not swap the connection endpoints of the two clusters. You may need to update your application's configuration. For example, if the original primary cluster had a public endpoint, ensure the new primary cluster also has one to avoid application access issues. To view connection endpoints, see View connection endpoints and ports.

   • A primary/secondary switchover in a GDN completes within 10 minutes (typically within 5 minutes based on test results). During the switchover, transient disconnections of up to 160 seconds may occur. We recommend that you perform the switchover during off-peak hours and ensure that your application has a reconnection mechanism.

   • If you enable the Forced Switchover switch in the Primary/Secondary Switchover dialog box:

     • You cannot specify a target cluster for a forced switchover. Instead, the system promotes the secondary cluster with the highest log sequence number (LSN) to be the new primary.

     • A forced switchover carries a risk of data loss. The original primary cluster is automatically removed after the switchover. Perform this action with caution.

Recreate a secondary cluster

FAQ

Related documentation

• Connect to a Global Database Network: Describes how to establish a connection to a GDN.

• Create a global domain name: Explains how to create a unified connection endpoint that provides nearest-region access and persists through a primary cluster switchover.

Related APIs