This topic describes the concepts and O&M of Paxos multi-replica in PolarDB-X Standard Edition.
Deployment modes
PolarDB-X supports multiple deployment modes and disaster recovery architectures. For example, in a PolarDB-X instance, you can deploy its nodes in a single zone, in three zones, or in three data centers across two regions.
Working principles and benefits
Working principles
Paxos is one of the pioneering consensus algorithms. It operates on a leader-based approach. In a PolarDB-X Standard Edition cluster, only one node can serve as the leader, responsible for the write operation, and the other nodes serve as followers, responsible for majority voting and data synchronization.
The consensus log of Paxos integrates the binary log content of MySQL. The leader node adds the consensus-related binary log event to the binary log protocol, while follower nodes replace the traditional relay log. The salve database replays log content to data files through the SQL thread. In essence, Paxos consensus logs are similar to MySQL binary logs.
Paxos uses the heartbeat/election timeout mechanism for dynamic leader node election. Upon detecting that the leader node becomes unavailable, the follower nodes elect a new leader node. The new leader node does not provide services until the SQL thread relays existing logs to data files.
Benefits
The Paxos-based multi-node architecture has the following benefits:
High performance: The single-leader mode delivers performance comparable to that of the semi-sync replication mode of MySQL.
Zero RPO: Paxos protocol logs integrate the content of MySQL binary logs, and the majority-based synchronization mechanism ensures no data loss.
Automatic HA: Based on the heartbeat mechanism for the leader election, the follower nodes automatically detect whether the leader node is alive and perform HA switching if necessary. You can use automatic HA to replace the active/standby HA of MySQL.
Metadata
Query the information about the replicas of Paxos
Execute the following statement to query the information about the replicas of Paxos. Only the leader node returns data, and the non-leader nodes do not return any result.
SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBALResults
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
| SERVER_ID | IP_PORT | MATCH_INDEX | NEXT_INDEX | ROLE | HAS_VOTED | FORCE_SYNC | ELECTION_WEIGHT | LEARNER_SOURCE | APPLIED_INDEX | PIPELINING | SEND_APPLIED |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
| 1 | 10.0.3.244:14886 | 1 | 0 | Leader | Yes | No | 5 | 0 | 0 | No | No |
| 2 | 10.0.3.245:14886 | 1 | 2 | Follower | Yes | No | 5 | 0 | 1 | Yes | No |
| 3 | 10.0.3.246:14886 | 1 | 2 | Follower | No | No | 5 | 0 | 1 | Yes | No |
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
3 rows in set (0.00 sec)Parameters
IP_PORT: indicates the IP address and port number of the replica.
ROLE: indicates the role of a replicas of Paxos, such as the leader, follower, or learner.
ELECTION_WEIGHT: indicates the election weight. It is generally applicable to cross-data center disaster recovery scenarios. You can set higher weights for replicas in the same data center to enhance their chances of winning the election.
MATCH_INDEX/NEXT_INDEX/APPLIED_INDEX: indicates the index of a consensus log.
Query the Paxos status of the local system
Execute the following statement to query the Paxos status of the local system:
SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCALResults
MySQL [(none)]> SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL \G
*************************** 1. row ***************************
SERVER_ID: 1
CURRENT_TERM: 6
CURRENT_LEADER: 10.0.3.244:14886
COMMIT_INDEX: 1
LAST_LOG_TERM: 6
LAST_LOG_INDEX: 1
ROLE: Leader
VOTED_FOR: 1
LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: Yes
INSTANCE_TYPE: NormalParameters
CURRENT_LEADER: indicates the IP address and port number of the current leader node.
ROLE: indicates the role of a replica of Paxos, such as the leader, follower, or learner.
INSTANCE_TYPE:: indicates the type of the replica. Valid values: Normal and Log.
Query data synchronization between the replicas of Paxos
Execute the following statement to query data synchronization between the replicas of Paxos (only the leader node returns data, and the non-leader nodes do not return any result):
SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_HEALTHResults
+-----------+------------------+----------+-----------+---------------+-----------------+
| SERVER_ID | IP_PORT | ROLE | CONNECTED | LOG_DELAY_NUM | APPLY_DELAY_NUM |
+-----------+------------------+----------+-----------+---------------+-----------------+
| 1 | 10.0.3.244:14886 | Follower | YES | 0 | 22 |
| 2 | 10.0.3.245:14886 | Leader | YES | 0 | 0 |
| 3 | 10.0.3.246:14886 | Follower | YES | 0 | 11 |
+-----------+------------------+----------+-----------+---------------+-----------------+Parameters
CONNECTED: indicates whether the node is normal.
LOG_DELAY_NUM: indicates the latency of consensus log synchronization in Paxos, which is similar to the latency of relay log synchronization in MySQL.
APPLY_DELAY_NUM: indicates the replay delay of Paxos consensus logs on the follower node, which is similar to the replay delay of the SQL relay thread in MySQL.