多向异地多活-MySQL实时双向复制 _MySQL实时双向

一、前言携程内部MySQL部署采用多机房部署，机房A部署一主一从，机房B部署一从，作为DR（Disaster Recovery）切换使用。当前部署下，机房B部署的应用需要跨机房进行写操作；当机房A出现故障时，DBA需要手动对数据库进行DR切换。
为了做到真正的数据异地多活，实现MySQL同机房就近读写，机房故障时无需进行数据库DR操作，只进行流量切换，就需要引入数据实时双向（多向）复制组件。

文章插图

二、DRC 介绍DRC（Data Replicate Center）是携程框架架构研发部推出的用于数据双向或多向复制的数据库中间件，在公司G2（高品质Great Service、全球化Globalization）战略的背景下，服务于异地多活项目，赋予了业务全球化的部署能力。
三、DRC 架构设计DRC采用服务端集中化设计，配合另一数据库访问中间件DAL（Data Access Layer）的本地读写功能，实现数据就近访问。

文章插图

模块介绍

Replicator Container

Replicator Container 实现对 Replicator 实例的管理，一个 Replicator 实例表示对一个MySQL集群的复制单元，Instance将自己伪装为MySQL的Slave，实现Binlog的拉取和本地存储。

Applier Container

Applier Container实现对Applier 实例的管理，一个Applier 实例连接到一个Replicator 实例，实现对Replicator 实例本地存储Binlog的拉取，进而解析出SQL语句并应用到目标MySQL，从而实现数据的复制。

Cluster Manager

Cluster Manager负责集群高可用切换，包括由于MySQL主从切换导致的Replicator 实例和Applier 实例重启，以及Replicator 实例与Applier 实例自身主从切换引起的新实例启动通知。

Console

Console提供UI操作、外部系统交互API以及监控告警。
四、DRC 详细设计4.1 接入DB规范DRC的核心指标包括复制延迟和数据一致性。
【多向异地多活-MySQL实时双向复制】为了实现数据复制的低延迟，Applier能够快速应用SQL，就需要每个表至少包含主键或者唯一键，加速执行效率；同时在保证数据准确的前提下，SQL应该尽量并行复制，需要MySQL开启从5.7.22版本引入的Writeset功能。
为了保证数据复制的准确性，在主备切换时Replicator仍能准确定位Binlog位点，需要MySQL开启GTID；当数据复制发生冲突时，为了具备自动解决冲突的能力，需要表包含时间戳列，并精确到毫秒。
这就需要接入DRC的MySQL数据库满足：
1）5.7.22及以上版本；
2）Master上开启Writeset并行复制；
3）MySQL开启GTID；
4）每个表包含时间戳列，精确到毫秒；
5）每个表至少包含主键或者唯一键。
DRC的复制依赖GTID（Global Transaction ID），这里先简单介绍一下GTID的概念。MySQL 5.6.5版本新增了一种基于GTID的复制方式，强化了数据库的主备一致性，故障恢复以及容错能力，取代传统的基于file和position主从复制，使得在MySQL主备切换时，仍能准确定位到Binlog位点。
GTID的格式形如：source_id:transaction_id，其中source_id表示MySQL服务器的uuid，transaction_id是在事务提交的时候系统顺序分配的一个序列号。
4.2 Binlog 复制单向复制链路包含拉取Binlog并持久化到本地磁盘的Replicator，和请求Binlog且并行应用到目标MySQL的Applier 。整个链路涉及的I/O操作包括网络传输和磁盘读写。

文章插图

4.2.1 低复制延迟为了降低复制延迟，就要求复制链路中每一环都尽可能高效。网络层通信模型使用异步I/O；系统层尽可能使用操作系统提供的Zero Copy和Page Cache；应用层提高数据处理并行度以及降低系统不可用时间。
监控显示生产环境业务双向复制延迟999线 < 1s 。下面就介绍一下DRC在降低复制延迟方面所做的性能优化工作。

文章插图

1）网络层Replicator采用GTID复制方式，实现了MySQL复制协议，伪装成源MySQL的Slave拉取Binlog 。网络层通信组件采用携程开源组件XPipe(
http://github.com/ctripcorp/x-pipe)，实现网络交互异步化。
2）系统层接收Binlog时，从数据流中解析出不同类型的Event，直接保存在堆外内存。每个Event需要经过一组过滤器，进而决定是否需要落盘持久化。对于Heartbeat类型的Event需要过滤丢弃；针对某些不需要进行数据同步的库和表，需要丢弃相应Event，减少存储量和传输量；对于需要持久化的Event，直接将堆外内存中的数据写入文件Page Cache并定时刷入磁盘，减少数据复制和IO操作，降低处理耗时，提升Replicator拉取效率。