跟我学：PolarDB-X Replica原理和使用
摘要：本文整理自阿里云数据库高级工程师佘志伟，在PolarDB-X动手实践系列的分享。
本篇内容主要分为六个部分：
- 动手实践系列介绍
- 环境准备
- 演示
- 原理
- 扩展
- 用户问答
一、动手实践系列介绍
PolarDB-X采用Shared-nothing与存储分离计算架构进行设计，系统由4个核心组件组成。PolarDB-X社区版围绕开源PolarDB-X，对应商业2.0版本。PolarDB-X社区版主要面向应用开发者、架构师、DBA等。
PolarDB-X是一款基于云架构理念，同时支持在线事务处理与在线分析处理，融合型分布式数据库产品。专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算效率等数据库瓶颈难题，助力企业加速完成业务数字化转型。
二、环境准备
在搭建环境之前，用户需要确定系统是CentOS 7或8；macOS；Ubuntu在18以上；Windows 10以上。相关配置需要大于等于8C64G。搭建环境需要的软件有：Docker&K8S；PolarDB-X 2.1.0。
PolarDB-X 支持与 MySQL 体验一致的 Replication 能力，称为 Replica。Replica可以在不停机的情况下，一个MySQL里的数据迁移到另一个MySQL。
三、演示
如上图所示，是一些基本的操作命令，通过在原端执行DDL和DML，验证整条链路的有效性。CHANGE MASTER TO是建立一条链路。
CHANGE REPLICATION FILTER是配置链路的过滤。START SLAVE，STOP SLAVE，RESET SLAVE分别是：开始链路，暂停链路，以及删除链路。
一共有三台机器。第一台部署MySQL，第二、三两台部署PolarDB-X。第一台作为主机，PolarDB-X Replica作为备用机，然后从主机拉数据，建立链路。
TPCC是一个用来验证OLTP性能的一个场景，在远端建立一个PolarDB-X到PolarDB-X的一个同步链路，然后并且在远端跑TPCC测试用来验证的性能。
接下来，建立一个转账一致性测试的链路。通过PolarDB-X建立转账测试，然后验证其一致性。最后，确定余额有没有改变。
在远端库最新的位点是018和18850385，建立链路。然后，储备延迟开始下降，变成22。在没有数据时，PolarDB-X Replica的log心跳是30秒一次。然后，在远端进行转账测试。
在目标端，验证转账测试，事务一致性以及余额总是否改变。开启转让测试脚本，建立bjbank库，用一条sql，计算所有的账户的余额之和，验证事务一致性。可以看到余额之和是1000万。
转账测试一共运行两分钟。转账测试是模拟金融级的场景。1000仓的数据，总量大概接近1亿行。经过转账测试的检验，实际TBC测试可以跑到每秒1.7万行。
接下来，建立双向同步的场景。选择两个都是活跃状态的节点，它们分别为一部分用户提供服务。多活容灾的解决方案，是两边都提供一部分服务，把变更的数据，通过资料复制，以Replica的方式，同步到另一侧。但这种方式，会形成环形的复制结构，数据可能不断复制，一直循环。
为了解决这个问题，PolarDB-X兼容了Mysql的解决方案。每一个DML变更、DBL变更，都要带上server ID，然后配置一个同步链路。在建立链路时，只要过滤server ID，就能保证业务端的写入，不会在复制链路中，被自己接收。成功解决环状复制的问题。
四、原理
接下来，讲一讲Replica运行时的架构。左边，利用数据中心做分布式协调，Replica的任务发现等。右边是Replica进程内部的运行架构，分为一个抽取器和写入应用器。抽取器通过不同的写入源，解析写入，ring buffer用来解耦。写入器基于性能和业务场景，用不同的策略写入目标端的数据库。
Extractor按照远端类型划分，用来屏蔽远端的不同细节。未来，也可能会接入一些异构数据的导入；前置一套kb缓存，用来支撑业务的高并发查询；后置PolarDB-X支持写入，数据持久化。
为了解决用户对复制性能和一致性的不同需求。Replica Applier支持事务级，行级复制。Transaction Applier可以保持原数据库事务的完整性，但串行，性能较差。
Split Applier不能保持原数据库事务完整性，但可以保持原binlog变更类型，
并行的性能中等。
Merge Applier不能保持原数据库事务完整性，但可以对UPDATE事件进行改写，并行的性能优秀。
接下来，简单讲一下Merge Applier算法。事件有三种，insert，delete和update。先初始化两个map，即delete map和insert map。然后，通过流式处理insert、delete、update的事件。
执行的每张表，将会得到一条delete sql和一条insert sql，并行执行完所有的delete sql，再并行执行insert sql。Merge Applier算法对应模块已经开源，大家可以看源码里以及源码对应的文档。
目前，很多用户有事物完整性的要求。但是性能太差，TPS有时候比较高。所以需要在保持事务完整性的基础上，做更快的加速。
MySQL有基于Gtid并行事物的复制，兼顾性能和一致性。接下来，阿里也会进行碰撞检测。比如两个事物，没有对同一个key对应的值，进行操作。所以，可以把它认为是两个并行事物，然后在下游执行，从而加快事务完整性的的速度。
因为MySQL binlog是单条流，所以很多时候会受到单条流解析，以及下游应用的这限制，无法做到太高的tps。目前，阿里开始做多个可并行的流，从而突破单流的性能极限，通过横向水平扩展，支撑更高的tps。
为了降低用户使用的心理负担、心智负担，阿里会替用户处理复杂的分布式协调的技术细节，降低工具的使用门槛。
五、扩展
过去，同学在做迁移时，需要关注每一步结果，手动操作下一步。目前，用户可以利用任务发现，流式处理框架。把迁移流程做成单命令，然后直接给一致数据和备库。
借助binlog流式的应用叫Replica+。该功能已经在公有云上线，未来会进行开源，该功能叫做一键导入，提升用户的体验感。
六、用户问答
问：mysql单表通过replica迁移到polardbx是单表还是公布式表？
答：目前都是单表，如果有简便的方法，能够绕过这个限制，可以先在目标端把表建好，然后在目标端建一个分布式表。保证库名，表名能够对得上，且下游能够正常写入，就能从单表同步到分布式表。
问：主要支持的场景是tp还是ap？
答：PolarDB-X Replica主要还是以tp为主。Replica是一个比较单纯的数据复制，更多需要关注tp的一致性。如果备库用来做tp需求，一致性要求就会更高。如果备库需要做一些ap需求，那会对性能的要求更高。在链路类型选择，建表方式等需要做一些调整。
问：TSO和Binlog有什么关系？
答：TSO也是全局Binlog得以实现的基础，它是全局Binlog对事务进行排序的依据，所以，在事务提交阶段，需要将TSO记录到各个DN的物理Binlog，供全局Binlog对事务进行归并排序。
