PolarDB:Three data centers across two regions

Weighted election

PolarDB-Xintroduces election weights in the three data centers across two regions design. The working principles are as follows:

• Optimistic weighted election: In the Paxos majority consensus protocol, nodes that are more likely to initiate elections tend to become leaders. To optimize this, a weight concept is introduced to set random delays for different nodes before they initiate leader elections, ensuring that higher-weight nodes initiate elections first.

• Mandatory weighted election: When a newly elected leader discovers that it does not have the highest weight among all nodes (this check is skipped when all weights are equal), it does not immediately accept writes. Instead, it enters an abdication phase and waits for one election timeout. During this phase, the node sends heartbeat probes to other nodes at regular intervals (for example, every 1 to 2 seconds). If a node with a higher weight responds, leadership is transferred to the highest-weight responding node.

PolarDB-XThe following table shows the election weights of replicas in the three data centers across two regions:

For example, if the leader replica in Primary Data Center 1 fails, the follower replica in the same data center (weight 7) is prioritized to become the new leader, keeping traffic local.

Dynamic adjustment of replica quantities

In the three data centers across two regions architecture, a five-replica majority group requires synchronization responses from at least three replicas. By default, the four replicas in the primary data centers complete majority synchronization locally over low-latency networks, with a typical latency of approximately 1 millisecond. When a data center-level failure leaves only three replicas, synchronization must include the replica in the secondary data center, increasing the majority protocol latency by approximately 30 milliseconds (typical cross-region latency in industries such as financial services).

Common replica adjustment scenarios:

• Downgrade from five replicas to three replicas: use the downgrade_followercommand to demote two followers to learners.

• Upgrade from three replicas to five replicas: use the upgrade_learnercommand to promote two learners back to followers. Make sure replication logs are current before upgrading.

• Upgrade from one replica to three replicas: use the add_followercommand to add replicas dynamically. New replicas start as learners and are automatically promoted to followers after their logs are current.

Forced start of a single replica

When the entire primary region fails, the remaining single replica in the secondary data center cannot satisfy the majority consensus requirement, so it cannot serve data on its own.

PolarDB-Xsupports forced start of a single replica. Use the force_single_modecommand to force the system into single-replica mode and sideline all followers. After the primary data centers recover, use the dynamic replica adjustment capability to restore the system from one replica to three and then five replicas.

Remote secondary instance

Financial industry disaster recovery standards define fine-grained RPO and RTO requirements for geo-disaster recovery, as shown in the following table:

PolarDB-XTo meet RTO requirements for geo-disaster recovery, the architecture provides a remote secondary instance based on five replicas plus a primary-secondary cluster pair. When the primary region fails completely, business traffic can be quickly switched to the remote secondary instance for disaster recovery.

Key design points of the primary-secondary cluster architecture:

• PolarDB-Xprimary instance uses the cross-region Paxos replication protocol and requires synchronization responses from at least three replicas. By default, the four replicas in the primary data centers complete majority synchronization locally, while the remote replica responds asynchronously. Cross-region latency does not affect primary instance performance.

• PolarDB-Xsecondary instance is deployed in the remote region and uses PolarDB-X CDC log nodes to build near-real-time cross-cluster primary-secondary replication. Although the remote secondary instance may have some replication latency, atomic transaction replication is ensured to avoid transaction inconsistency.

• Cross-cluster replication in the three data centers across two regions scenario requires CDC log nodes deployed in the remote region to sort and reorganize distributed transactions. This provides atomic transaction replication and ensures that no partially committed transactions occur during cross-cluster replication. Atomic transaction replication guarantees data integrity during both routine disaster recovery drills and real failovers when traffic is switched to the remote secondary instance.

Create an instance

When creating a PolarDB-X instance, set the deployment mode to Three Data Centers Across Two Regions.

View instance topology

On the Basic Information page, find the Topology Information section to view the zone information of the corresponding resources.

Perform a failover

1. Log on to the PolarDB Distributed Edition console.

2. In the top navigation bar, select the region where the instance is deployed.

3. On the Instances page, click the PolarDB-X 2.0 tab.

4. Find the instance and click Instance ID to go to the instance details page.

5. On the Basic Information page, find the Topology Information section, click Specify Primary Zone.

6. In the Specify Primary Zone dialog box, set the Data Center, Primary Zone, and Switch Mode parameters.

7. Click OK.