01
TPC-C是由国际数据库事务性能委员会TPC组织发布、专门针对OLTP系统的测试模型，涵盖了数据库的增删改查等典型处理路径，以此来测试数据库的OLTP性能，最终性能以tpmC（每分钟订单创建数目）来衡量，TPC-C测试模型能够直观地评估出一个数据库的性能表现。
TPC-C基准测试中一个重要测试项为高可用测试。其通过模拟节点故障、网络中断等场景，验证数据库系统在故障切换中的事务处理能力、数据一致性和快速恢复能力。测试方法包括部署多节点集群，注入故障并监控关键指标（如吞吐量、延迟），确保服务连续性。其意义在于评估系统容灾能力，保障业务连续性，优化架构可靠性，提升用户信任。测试结果可量化RTO（恢复时间目标）和RPO（数据丢失量），为系统容错设计和运维提供依据。
本次TPC-C基准测试，我们所使用的是PolarDB for MySQL 8.0.2版。PolarDB for MySQL的高可用体系如图1所示。在同一个可用区内，通过VotingDisk实现计算节点秒级RTO、RPO=0的高可用探测和切换。同城跨可用区间，可选择使用内核集成优化的X-Paxos进行物理日志强同步容灾。跨城数据同步则可以使用全球数据库网络（GDN）高效同步数据。
02
同可用区无感秒切
传统MySQL主备架构下，主备节点间通过Binlog复制回放生成一份容灾数据，用冗余的数据来实现高可用特性。得益于PolarDB for MySQL云原生共享存储的架构，在同可用区内，RW主节点和RO备节点间共享一份数据，高可用特性的存储成本为零。针对计算节点主机、网络故障场景，PolarDB通过云原生各组件的深度协调优化，实现了无感秒切能力。主要技术特点有：
通过共享存储原子读写语义，实现分布式计算节点VotingDisk快速探测机制；
热备只读节点通过全局预热，实现极速切换；
通过Proxy和计算节点全链路协调，内核事务续传创新技术，实现客户端连接零中断。
2.1 分布式租约锁：Voting Disk
基于PolarDB的云原生共享存储架构设计，计算节点通过共享存储PolarStore提供的原子读写接口，实现了一套分布式租约锁机制。原子读写数据块中记录了锁持有者和租约时间等元信息。PolarDB的主节点（VD Leader）通过续租接口不断更新元信息，证明锁持有者的健康状态。RO节点可以分为两种类型：热备RO和普通RO。热备RO（VD follower）通过trylock语义周期性尝试拿锁，完成故障探测和集群选主功能。普通RO（VD Observer）周期性获取集群拓扑信息，如果主节点发生变动，则自动连接新RW。同时，基于分布式共享存储的I/O FENCE接口，计算层节点根据锁的保护范围精确控制各种类型计算节点的写权限，保护数据安全性。整个方案我们称为Voting Disk。
PolarDB直接利用云原生架构中心化的共享存储实现一个计算层的分布式锁服务，而不需要依赖一个第三方的组件如ZooKeeper、Redis。也无需像Share Nothing的分布式系统依赖Paxos等一致性协议执行复杂的多数派判定。VotingDisk有以下几点优势：
故障检测准确：无需像传统主备数据库通过链接探测RW状态，避免由于假死、误判导致的错误切换。对IO hang或IO链路网络故障的场景可以有效覆盖。
秒级RTO：RO节点可以一次原子I/O快速获取所有分布式锁信息，1~5秒即可获取集群健康状态。文件锁属于中心化的节点，决策不存在双主的风险。
RPO = 0：集群所有节点共享存储，RO切换为任一节点都可保证数据零丢失。
2.2 无感秒切
💻 点击 文末阅读原文 免费体验PolarDB热备无感秒切技术。
PolarDB通过多技术协同实现高可用与无缝切换。热备RO节点除提供读服务外，预留部分资源作为全局预热系统，通过Buffer Pool、Undo、Redo、Binlog四个模块实时同步主节点元数据至内存。当主备切换发生时，备节点可以直接从内存获取到相关信息而不用通过发起IO从存储获取信息。
PolarDB热备RO与普通RO主动运维的表现对比
2.3 连接保持和事务续传
传统主备切换常导致连接中断和事务回滚，针对空闲连接，PolarDB连接保持功能通过数据库代理（PolarProxy）在应用与数据库间桥接连接，切换时保留会话状态（如变量、字符集），保证连接不中断。
针对有活跃事务的会话，由于Proxy无法存储事务执行上下文，连接保持将失效。PolarDB创新性推出事务续传功能，实现事务上下文在RW节点和RO节点间同步。主备切换时，Proxy在新RW节点上查询对应链接的事务上下文信息，并将该信息恢复到新链接上后即可继续执行事务。最终，应用仅感知到操作延迟，无连接或事务错误。相比传统逻辑复制，PolarDB基于物理复制确保备节点与主节点数据完全一致，显著提升切换效率与可靠性。详情可见：无感秒切[1]
图5：PolarDB for MySQL事务续传
[1] 无感秒切：https://help.aliyun.com/zh/polardb/polardb-for-mysql/user-guide/failover-with-hot-standby-in-seconds/
2.4 多主集群高可用
PolarDB MySQL版支持多主集群（Limitless），客户通过加读写节点（RW）的方式即可从PolarDB MySQL一主多读变配为PolarDB MySQL版多主集群（Limitless)。多主集群的每个RW节点都可以分配一个Voting Disk分布式租约锁。每个RW也可以配置一个私有RO，作为其备节点。集群RO数量可以自定义。RO除了作为备库，在系统运行过程中也可以提供全局一致的读服务。最低可以配置零RO节点，让RW探测其余RW节点的状态而作为其余RW的备份节点。发现RW不可用以后，将故障RW的分库移到正常的RW即可。不过值得提醒的是，由于资源减少，在高压力负载下可能会影响集群整体性能。
2.5 高可用测试
通过sysbench read_write 32并发测试，验证主备切换的效果。如图6所示，可以看到在切换瞬间，只有1秒多慢查询影响，无断连报错。
03
同城跨可用区容灾技术
当需要在同城不同可用区之间进行数据容灾时，PolarDB提供多层次的容灾体系以供选择。
图7：同城多可用区容灾方案
在同城多可用区下，PolarDB MySQL提供了四种容灾方案：
1、双可用区异步同步-存储对等：
数据分布在两个可用区内，主可用区和备可用区各保存一份完整数据，备可用区异步复制主可用区数据。
无计算节点，主备可用区切换时，需要在备可用区重新部署计算集群。
2、双可用区异步同步-计算、存储对等：
数据分布在两个可用区内，主可用区和备可用区各保存一份完整数据，备可用区异步复制主可用区数据。
主可用区、备可用区部署对等计算集群，主备可用区切换时，无需等待计算集群重新部署。
3、双可用区半同步：
数据分布在两个可用区内，主可用区和备可用区各保存一份完整数据，备可用区同步复制主可用区数据。
无计算节点，主备可用区切换时，需要在备可用区重新部署计算集群。
4、多可用区强同步：
多可用区数据强一致性。与半同步和异步方式相比，采用一主一备一日志的三节点架构，通过物理复制与X-Paxos协议相结合，同可用区之间强同步物理日志，在进行可用区切换时可保证零数据丢失。
当主可用区集群发生故障时，X-Paxos自动选主并切换至备可用区，可确保恢复时间目标（RTO）小于15秒，提供金融级别的高可靠性。
PolarDB热备RO与普通RO故障容灾的表现对比
04
跨城容灾
低延迟：PolarDB全球数据库网络是基于Redo Log来做的同步，相对于Binlog同步，Redo Log的产生不依赖事务提交，并且针对数据页修改的特征更方便做并发，同时PolarDB GDN通过流水线、多通道等复制优化极大的降低地域之间的复制延迟。 低成本：目前全球数据库网络（GDN）跨地域传输流量可以免费使用，您只需要支付每个PolarDB集群自身的费用 产品一体化：内核级别双向复制、读写控制、双活切换联动，消除第三方工具复杂链路带来的风险及复杂运维。
全局域名：全局域名功能给GDN提供一个统一的连接地址。通过全局域名，不但可以实现就近访问，还可以实现主集群切换后，域名保持不变。 GDN 2.0就近写：GDN 2.0提供库表/分区级别的多写能力；通过库表/分区的写权限控制来彻底规避危险的写冲突问题；提供Unit Sequence来支持不同地域自增键的交叉推进；并实现实例级、AZ级、地域级三级容灾一键切换能力。
点击阅读原文免费体验PolarDB热备无感秒切
