PolarDB-X 开源 | 基于 Paxos 的 MySQL 三副本

阿里云云栖号

已于 2023-12-25 17:08:26 修改

阅读量1.7k

点赞数 24

文章标签：开源 mysql adb 数据库阿里云云计算数据库开发

于 2023-12-25 17:07:00 首次发布

本文链接：https://blog.csdn.net/yunqiinsight/article/details/135204262

版权

前言

PolarDB-X 作为PolarDB分布式版，是阿里巴巴自主设计研发的高性能云原生分布式数据库产品，采用 Shared-nothing 与存储分离计算架构，支持集中式和分布式一体化形态，具备金融级数据高可用、分布式水平扩展、混合负载、低成本存储和极致弹性等能力，坚定以兼容MySQL开源生态构建分布式能力，为用户提供高吞吐、大存储、低延时、易扩展和超高可用的云时代数据库服务。

PolarDB-X在架构上可以简单分为CN节点和DN节点。计算节点CN负责SQL的解析和执行，存储节点DN负责数据的分布式事务和高可用存储。

2023年10月份，PolarDB-X 开源正式发布V2.3.0版本，重点推出PolarDB-X标准版（集中式形态），将PolarDB-X分布式中的DN节点提供单独服务。支持Paxos协议的多副本模式、lizard分布式事务引擎，采用一主一备一日志的三节点架构，通过Paxos协议多副本同步复制，确保数据的强一致性（RPO=0），可以100%兼容MySQL。同时在性能场景上，采用生产级部署和参数(开启双1 + Paxos多副本强同步)，相比于开源MySQL 8.0.34，PolarDB-X在读写混合场景上有30~40%的性能提升，可以作为开源MySQL的最佳替代选择。

本篇文章的后续部分，主要介绍如何从0到1快速体验：PolarDB-X的集中式形态（“基于Paxos的MySQL三副本”）。

工作原理

PolarDB-X基于Paxos的MySQL三副本，大致的工作原理：

1、在同一时刻，整个集群中至多会有一个Leader节点来承担数据写入的任务，其余节点作为follower参与多数派投票和数据同步
2、Paxos的协议日志Consensus Log，全面融合了MySQL原有的binlog内容。在Leader主节点上会在binlog协议中新增Consensus相关的binlog event，同时在Follower备节点上替换传统的Relay Log，备库会通过SQL Thread进行Replay日志内容到数据文件，可以简单理解Paxos Consensus Log ≈ MySQL Binlog
3、基于Paxos多数派自动选主机制，通过heartbeat/election timeout机制会监听Leader节点的变化，在Leader节点不可用时Follower节点会自动完成切主，新的Leader节点提供服务之前需等待SQL Thread完成存量日志的Replay，确保新Leader有最新的数据。

PolarDB-X基于Paxos的MySQL三副本，技术特点：

1、高性能，采用单Leader的模式，可以提供类比MySQL semi-sync模式的性能
2、RPO=0，Paxos协议日志全面融合MySQL原有的binlog内容，基于多数派同步机制确保数据不丢
3、自动HA，基于Paxos的选举心跳机制，MySQL自动完成节点探活和HA切换，可以替换传统MySQL的HA机制。

更多技术原理，可以参考：PolarDB-X 存储引擎核心技术 | Paxos多副本

快速部署

PolarDB-X支持多种形态的快速部署能力，可以结合各自需求尽心选择

本文采用依赖最少的RPM包部署方式，通过 RPM 部署 PolarDB-X 标准版（集中式形态），需要首先获取相应的 RPM 包，您可以手动编译生成该 RPM 包，也可以自行下载（请根据实际情况下载 x86 或 arm 对应的 RPM）。

RPM下载地址：https://github.com/polardb/polardbx-engine/releases/
（国内RPM下载地址：https://openpolardb.com/download

1、选择源码编译RPM包，可以参考文档：从源码编译生成RPM

# 拉取代码
git clone https://github.com/polardb/polardbx-engine.git --depth 1

# 编译生成 rpm
cd polardbx-engine/rpm && rpmbuild -bb t-polardbx-engine.spec

最后，基于RPM包快速安装

yum install -y <您下载或编译的rpm>

安装后的二进制文件，会出现在 /opt/polardbx-engine/bin 中。

体验单机模式

准备一份 my.cnf（参考模板）和数据目录（如果改了 my.cnf，则下面的目录也要相应修改），就可以准备启动了。

# 创建并切换到 polarx 用户
useradd -ms /bin/bash polarx
echo "polarx:polarx" | chpasswd
echo "polarx    ALL=(ALL)    NOPASSWD: ALL" >> /etc/sudoers
su - polarx

# 创建必要目录
mkdir polardbx-engine
cd polardbx-engine && mkdir log mysql run data tmp

# 初始化my.cnf文件
vi my.cnf

# 初始化
/opt/polardbx_engine/bin/mysqld --defaults-file=my.cnf --initialize-insecure
# 启动
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf &

登录数据库，验证状态

# 登录数据库，my.cnf指定了端口
mysql -h127.0.0.1 -P4886 -uroot

# 查询本机的paxos角色
MySQL [(none)]> SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL \G
*************************** 1. row ***************************
          SERVER_ID: 1
       CURRENT_TERM: 2
     CURRENT_LEADER: 127.0.0.1:14886
       COMMIT_INDEX: 1
      LAST_LOG_TERM: 2
     LAST_LOG_INDEX: 1
               ROLE: Leader
          VOTED_FOR: 1
   LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: Yes
      INSTANCE_TYPE: Normal
1 row in set (0.00 sec)

# 查询集群所有机器的paxos角色（只有Leader节点会返回数据）
MySQL [(none)]> SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL \G
*************************** 1. row ***************************
      SERVER_ID: 1
        IP_PORT: 127.0.0.1:14886
    MATCH_INDEX: 1
     NEXT_INDEX: 0
           ROLE: Leader
      HAS_VOTED: Yes
     FORCE_SYNC: No
ELECTION_WEIGHT: 5
 LEARNER_SOURCE: 0
  APPLIED_INDEX: 0
     PIPELINING: No
   SEND_APPLIED: No
1 row in set (0.00 sec)

因为默认my.cnf只配置了单机模式启动，因此只会显示单副本的Leader状态

体验基于Paxos的高可用

我们在 3 台机器上，部署一个完整的集中式集群，并验证高可用切换的能力。假设我们的 3 台机器 IP 分别为：

10.0.3.244
10.0.3.245
10.0.3.246

我们在 3 台机器上，安装 RPM 后，准备好 my.cnf 和目录（如果有任何步骤失败，请完全清理这些目录，重新创建）。然后在 3 个机器上，分别按如下方式启动：

# 10.0.3.244 上执行
/opt/polardbx_engine/bin/mysqld --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@1' \
--initialize-insecure

/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@1' \
&

# 10.0.3.245 上执行
/opt/polardbx_engine/bin/mysqld --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@2' \
--initialize-insecure

/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@2' \
&

# 10.0.3.246 上执行
/opt/polardbx_engine/bin/mysqld --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@3' \
--initialize-insecure

/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@3' \
&

注意：我们在启动时修改了 cluster-info 的配置项，其中的格式为 [host1]:[port1];[host2]:[port2];[host3]:[port3]@[idx] ，不同的机器，只有 [idx] 不同，[idx] 也反映了该机器是第几个 [host][port]。请根据实际机器的 ip 修改该配置项。

另外，PolarDB-X的副本启动为Logger模式，需要设置cluster-log-type-node=ON

# 比如我们把第三个主机，配置为logger模式

/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
cluster-log-type-node=ON \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@3' \
&

体验一（三副本启动）

Paxos三副本在逐台启动时，刚启动第一台时，会因为不满足Paxos多数派，无法产生选主结果，此时数据库无法登录。

> tail -f /home/polarx/polardbx-engine/log/alert.log
......
[ERROR] Server 1 : Paxos state change from FOLL to CAND !!
[ERROR] Server 1 : Start new requestVote: new term(2)
[ERROR] Server 1 : Paxos state change from CAND to CAND !!
[ERROR] Server 1 : Start new requestVote: new term(3)
[ERROR] Server 1 : Paxos state change from CAND to CAND !!
[ERROR] Server 1 : Start new requestVote: new term(4)
[ERROR] Server 1 : Paxos state change from CAND to CAND !!
[ERROR] Server 1 : Start new requestVote: new term(5)
...... 
# 阻塞直到第二个节点加入，并成功选主
[ERROR] EasyNet::onConnected server 2
[ERROR] Server 1 : Paxos state change from CAND to CAND !!
[ERROR] Server 1 : Start new requestVote: new term(6)
[ERROR] Server 1 : server 2 (term:6) vote me to became leader.
[ERROR] Server 1 : Paxos state change from CAND to LEDR !!
[ERROR] Server 1 : become Leader (currentTerm 6, lli:1, llt:6)!!

数据库启动完成后，我们登录数据库，验证一下集群的状态

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: Normal

MySQL [(none)]> `
+-----------+------------------+-------------+------------+----------+-----------+------------+-----------------+----------------+---------------+------------+--------------+
| 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)

我们可以看到，三台机器中10.0.3.244为leader，10.0.3.245、10.0.3.246都为Follower角色

体验二（kill -9切换）

基于Paxos的三副本模式，只有 Leader 节点可以写入数据。我们在 Leader 上建一个库表，写入一些简单的数据：

CREATE DATABASE db1;
USE db1;
CREATE TABLE tb1 (id int);
INSERT INTO tb1 VALUES (0), (1), (2);

然后我们可以在 Leader和Follower 上把数据查出来。我们也可以在 Leader 上查询集群的状态：

MySQL [db1]> SELECT SERVER_ID,IP_PORT,MATCH_INDEX,ROLE,APPLIED_INDEX FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL ;
+-----------+------------------+-------------+----------+---------------+
| SERVER_ID | IP_PORT          | MATCH_INDEX | ROLE     | APPLIED_INDEX |
+-----------+------------------+-------------+----------+---------------+
|         1 | 10.0.3.244:14886 |           4 | Leader   |             4 |
|         2 | 10.0.3.245:14886 |           4 | Follower |             4 |
|         3 | 10.0.3.246:14886 |           4 | Follower |             4 |
+-----------+------------------+-------------+----------+---------------+
3 rows in set (0.00 sec)

其中 APPLIED_INDEX 都是 4 ，说明数据目前Paxos三节点上的Log Index是完全一致的。接下来，我们对 Leader 节点（10.0.3.244）进程 kill -9 ，让集群选出新 Leader。

kill -9 $(pgrep -x mysqld)

旧 Leader 被 kill 后，mysqld_safe 会立马重新拉起 mysqld 进程。随后，我们看到，Leader 变成了 10.0.3.245 节点了

# 10.0.3.245新Leader上，查询状态
MySQL [(none)]> SELECT SERVER_ID,IP_PORT,MATCH_INDEX,ROLE,APPLIED_INDEX FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL ;
+-----------+------------------+-------------+----------+---------------+
| SERVER_ID | IP_PORT          | MATCH_INDEX | ROLE     | APPLIED_INDEX |
+-----------+------------------+-------------+----------+---------------+
|         1 | 10.0.3.244:14886 |           5 | Follower |             5 |
|         2 | 10.0.3.245:14886 |           5 | Leader   |             4 |
|         3 | 10.0.3.246:14886 |           5 | Follower |             5 |
+-----------+------------------+-------------+----------+---------------+
3 rows in set (0.00 sec)

我们在10.0.3.244原leader上，查询状态已经变为follower

MySQL [(none)]> SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL \G
*************************** 1. row ***************************
          SERVER_ID: 1
       CURRENT_TERM: 7
     CURRENT_LEADER: 10.0.3.245:14886
       COMMIT_INDEX: 5
      LAST_LOG_TERM: 7
     LAST_LOG_INDEX: 5
               ROLE: Follower
          VOTED_FOR: 2
   LAST_APPLY_INDEX: 5
SERVER_READY_FOR_RW: No
      INSTANCE_TYPE: Normal

可以通过不断kill -9多副本，来验证Leader在三个节点中不断迁移和恢复的能力。通过以上步骤，我们简单验证了基于Paxos三副本自动选主和切换的能力。

体验三（预期切换命令）

PolarDB-X内置提供面向Paxos三副本运维管理的命令比如当前集群状态：

MySQL [(none)]> SELECT SERVER_ID,IP_PORT,MATCH_INDEX,ROLE,APPLIED_INDEX FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_GLOBAL ;
+-----------+------------------+-------------+----------+---------------+
| SERVER_ID | IP_PORT          | MATCH_INDEX | ROLE     | APPLIED_INDEX |
+-----------+------------------+-------------+----------+---------------+
|         1 | 10.0.3.244:14886 |           9 | Leader   |             8 |
|         2 | 10.0.3.245:14886 |           9 | Follower |             9 |
|         3 | 10.0.3.246:14886 |           9 | Follower |             9 |
+-----------+------------------+-------------+----------+---------------+

指令1：指定IP切换Leader

call dbms_consensus.change_leader("10.0.3.245:14886");

指令2：查询和清理consensus日志

# 查询consensus日志（PolarDB-X基于binlog文件实现paxos consensus日志）
MySQL [(none)]> show consensus logs;
+---------------------+-----------+-----------------+
| Log_name            | File_size | Start_log_index |
+---------------------+-----------+-----------------+
| mysql-binlog.000001 |      1700 |               1 |
+---------------------+-----------+-----------------+
1 row in set (0.00 sec)

# 清理consensus日志，指定logIndex（有保护机制，如果有副本还在消费则不会清理成功）
MySQL [(none)]> call dbms_consensus.purge_log(1);
Query OK, 0 rows affected (0.00 sec)

除此以外，额外支持：动态增删副本、节点角色变更（Learner/Follower）、选举权重设置

# 加learner
call dbms_consensus.add_learner("127.0.0.1:14886");
# 减learner
call dbms_consensus.drop_learner("127.0.0.1:14886");

# learner转follower,learner日志落后太多会返回失败
call dbms_consensus.upgrade_learner("127.0.0.1:14886");
# follower降级learner
call dbms_consensus.downgrade_follower("127.0.0.1:15700");

#   修改follower节点的选主权重[1-9]，默认为5
call dbms_consensus.configure_follower("127.0.0.1:15700", 9);

体验四（模拟离线启动）

PolarDB-X支持多副本的离线启动，比如因为断网或断电需要，期望数据库支持整体关机和离线启动的能力，可以基于本地文件重新离线组建新的三副本。做一个简单模拟，我们登录三台机器进行整体kil -9

kill -9 $(pgrep -x mysqld)

原位模拟离线启动，重新组建三副本集群：

# 10.0.3.244 上执行
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@1' \
&

# 10.0.3.245 上执行
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@2' \
&

# 10.0.3.246 上执行
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='10.0.3.244:14886;10.0.3.245:14886;10.0.3.246:14886@3' \
&

如果真实业务中，涉及了机器迁移，拷贝原有数据文件到新机器后，可以在三副本启动时设置--cluster-force-change-meta=ON，强制刷新下集群的元数据。例子：

# 强制刷新元数据（刷新成功后会退出mysqld和mysqld_safe）
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-force-change-meta=ON \
--cluster-info='192.168.6.183:14886;192.168.6.184:14886;192.168.6.185:14886@1' \
&

# 按照新配置，重新启动
/opt/polardbx_engine/bin/mysqld_safe --defaults-file=my.cnf \
--cluster-info='192.168.6.183:14886;192.168.6.184:14886;192.168.6.185:14886@1' \
&

体验基于Paxos的性能压测

我们通过3台机器部署Paxos多副本，快速验证下PolarDb-X的性能在默认参数基础上，进行PolarDB-X相关参数调优（可以参考绝大部分的MySQL参数调优方法）：

[mysqld]

# 调整最大连接数
max_connections=20000

# 强制刷盘
sync_binlog=1
innodb_flush_log_at_trx_commit=1

# 优化follower的复制效率
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=16

# binlog参数
binlog_order_commits=OFF
binlog_cache_size=1M
binlog_transaction_dependency_tracking=WRITESET

# 调整innodb BP大小
innodb_buffer_pool_size=20G
# innodb参数
innodb_log_buffer_size=200M
innodb_log_file_size=2G
innodb_io_capacity=20000
innodb_io_capacity_max=40000
innodb_max_dirty_pages_pct=75
innodb_lru_scan_depth=8192
innodb_open_files=20000

# consensus
consensus_log_cache_size=512M
consensus_io_thread_cnt=8
consensus_worker_thread_cnt=8
consensus_prefetch_cache_size=256M

# timezone
default_time_zone=+08:00

快速创建一个压测用户：

CREATE USER polarx IDENTIFIED BY 'polarx';  
grant all privileges on *.* to 'polarx'@'%' ;
FLUSH PRIVILEGES ;

参考压测文档，部署PolarDB-X开源的benchmark-boot压测工具

# 下载镜像
docker pull polardbx/benchmark-boot:latest

# 启动容器
docker run -itd --name 'benchmark-boot' --privileged --net=host \
    -v /etc/localtime:/etc/localtime polardbx/benchmark-boot:latest \
    /usr/sbin/init

# 验证
curl http://127.0.0.1:4121/

压测方法可以参考文档：Sysbench 测试报告、TPC-C 测试报告压测过程中，可以通过paxos的系统视图，关注数据复制状态

MySQL [(none)]> select * from  INFORMATION_SCHEMA.ALISQL_CLUSTER_health;
+-----------+------------------+----------+-----------+---------------+-----------------+
| 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 |
+-----------+------------------+----------+-----------+---------------+-----------------+

LOG_DELAY_NUM代表binlog复制到paxos多副本的延迟数量，如果接近0代表基本没有延迟 APPLY_DELAY_NUM代表在副本中binlog apply应用的延迟数量，如果接近0代表基本没有延迟
压测环境采用 3台ecs.i4.8xlarge(32c256GB + 7TB的磁盘) TPC-C 1000仓，跑200并发的性能24万 tpmC 资源情况：Leader节点CPU 95%、Follower节点CPU 30%（Logger节点<10%）

02:52:42,321 [main] INFO   jTPCC : Term-00, 
02:52:42,322 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
02:52:42,322 [main] INFO   jTPCC : Term-00,      BenchmarkSQL v5.0
02:52:42,323 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
02:52:42,323 [main] INFO   jTPCC : Term-00,  (c) 2003, Raul Barbosa
02:52:42,323 [main] INFO   jTPCC : Term-00,  (c) 2004-2016, Denis Lussier
02:52:42,324 [main] INFO   jTPCC : Term-00,  (c) 2016, Jan Wieck
02:52:42,324 [main] INFO   jTPCC : Term-00, +-------------------------------------------------------------+
02:52:42,324 [main] INFO   jTPCC : Term-00, 
02:52:42,324 [main] INFO   jTPCC : Term-00, db=mysql
02:52:42,324 [main] INFO   jTPCC : Term-00, driver=com.mysql.jdbc.Driver
02:52:42,324 [main] INFO   jTPCC : Term-00, conn=jdbc:mysql://10.0.3.245:4886/tpcc?readOnlyPropagatesToServer=false&rewriteBatchedStatements=true&failOverReadOnly=false&connectTimeout=3000&socketTimeout=0&allowMultiQueries=true&clobberStreamingResults=true&characterEncoding=utf8&netTimeoutForStreamingResults=0&autoReconnect=true&useSSL=false
02:52:42,324 [main] INFO   jTPCC : Term-00, user=polarx
02:52:42,324 [main] INFO   jTPCC : Term-00, 
02:52:42,324 [main] INFO   jTPCC : Term-00, warehouses=1000
02:52:42,325 [main] INFO   jTPCC : Term-00, terminals=200
02:52:42,326 [main] INFO   jTPCC : Term-00, runMins=5
02:52:42,326 [main] INFO   jTPCC : Term-00, limitTxnsPerMin=0
02:52:42,326 [main] INFO   jTPCC : Term-00, terminalWarehouseFixed=true
02:52:42,326 [main] INFO   jTPCC : Term-00, 
02:52:42,326 [main] INFO   jTPCC : Term-00, newOrderWeight=45
02:52:42,326 [main] INFO   jTPCC : Term-00, paymentWeight=43
02:52:42,326 [main] INFO   jTPCC : Term-00, orderStatusWeight=4
02:52:42,326 [main] INFO   jTPCC : Term-00, deliveryWeight=4
02:52:42,326 [main] INFO   jTPCC : Term-00, stockLevelWeight=4
02:52:42,326 [main] INFO   jTPCC : Term-00, newOrderRemotePercent=10
02:52:42,326 [main] INFO   jTPCC : Term-00, paymentRemotePercent=15
02:52:42,326 [main] INFO   jTPCC : Term-00, useStoredProcedure=false
02:52:42,326 [main] INFO   jTPCC : Term-00, 
02:52:42,327 [main] INFO   jTPCC : Term-00, resultDirectory=null
02:52:42,327 [main] INFO   jTPCC : Term-00, osCollectorScript=null
02:52:42,327 [main] INFO   jTPCC : Term-00, 
02:52:42,516 [main] INFO   jTPCC : Term-00, C value for C_LAST during load: 226
02:52:42,517 [main] INFO   jTPCC : Term-00, C value for C_LAST this run:    107
02:52:42,517 [main] INFO   jTPCC : Term-00, 
.......
02:57:43,133 [Thread-172] INFO   jTPCC : Term-00, 
02:57:43,133 [Thread-172] INFO   jTPCC : Term-00, 
02:57:43,134 [Thread-172] INFO   jTPCC : Term-00, Measured tpmC (NewOrders) = 237040.65
02:57:43,134 [Thread-172] INFO   jTPCC : Term-00, Measured tpmTOTAL = 526706.43
02:57:43,134 [Thread-172] INFO   jTPCC : Term-00, Session Start     = 2023-11-21 02:52:43
02:57:43,134 [Thread-172] INFO   jTPCC : Term-00, Session End       = 2023-11-21 02:57:43
02:57:43,134 [Thread-172] INFO   jTPCC : Term-00, Transaction Count = 2633935

总结

本文通过从源码编译、RPM安装，全流程验证PolarDB-X的单节点、三副本等启动方式，以及通过kill -9模拟故障，快速体验RPO=0的自动切换。另外，在面向可运维性上，支持多种运维指令、以及离线重搭启动的方式，很好满足了MySQL生态的运维习惯。最后，通过一个性能压测的实践，快速复现PolarDB-X性能白皮书的测试结果，后续也会逐步增加关于PolarDB-X Paxos与MySQL MGR的技术原理和性能对比的相关测试，欢迎大家继续关注。

附录（my.cnf 简单模板）

[mysqld]
basedir = /opt/polardbx-engine
log_error_verbosity = 2
default_authentication_plugin = mysql_native_password
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = mysql-binlog
binlog_format = row
binlog_row_image = FULL
master_info_repository = TABLE
relay_log_info_repository = TABLE

# change me if needed
datadir = /home/polarx/polardbx-engine/data
tmpdir = /home/polarx/polardbx-engine/tmp
socket = /home/polarx/polardbx-engine/tmp.mysql.sock
log_error = /home/polarx/polardbx-engine/log/alert.log
port = 4886
cluster_id = 1234
cluster_info = 127.0.0.1:14886@1

[mysqld_safe]
pid_file = /home/polarx/polardbx-engine/run/mysql.pid

作者：七锋

原文链接

本文为阿里云原创内容，未经允许不得转载。