行业案例：携程异地多活-MySQL实时双向（多向）复制实践.pdfVIP

携程异地多活-MySQL实时双向（多向）复制

实践

一、前言

携程内部MySQL部署采用多机房部署，机房A部署一主一从，机房B部署一从，作为DR（Disaster

Recovery）切换使用。当前部署下，机房B部署的应用需要跨机房进行写操作；当机房A出现故障时，

DBA需要手动对数据库进行DR切换。

为了做到真正的数据异地多活，实现MySQL同机房就近读写，机房故障时无需进行数据库DR操作，只

进行流量切换，就需要引入数据实时双向（多向）复制组件。

二、DRC介绍

DRC（DataReplicateCenter）是携程框架架构研发部推出的用于数据双向或多向复制的数据库中间

件，在公司G2（高品质GreatService、全球化Globalization）战略的背景下，服务于异地多活项目，

赋予了业务全球化的部署能力。

三、DRC架构设计

DRC采用服务端集中化设计，配合另一数据库访问中间件DAL（DataAccessLayer）的本地读写功能，

实现数据就近访问。

模块介绍

ReplicatorContainer

ReplicatorContainer实现对Replicator实例的管理，一个Replicator实例表示对一个MySQL集群的

复制单元，Instance将自己伪装为MySQL的Slave，实现Binlog的拉取和本地存储。

ApplierContainer

ApplierContainer实现对Applier实例的管理，一个Applier实例连接到一个Replicator实例，实现对

Replicator实例本地存储Binlog的拉取，进而解析出SQL语句并应用到目标MySQL，从而实现数据的复

制。

ClusterManager

ClusterManager负责集群高可用切换，包括由于MySQL主从切换导致的Replicator实例和Applier实

例重启，以及Replicator实例与Applier实例自身主从切换引起的新实例启动通知。

Console

Console提供UI操作、外部系统交互API以及监控告警。

四、DRC详细设计

4.1接入DB规范

DRC的核心指标包括复制延迟和数据一致性。

为了实现数据复制的低延迟，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（GlobalTransactionID），这里先简单介绍一下GTID的概念。MySQL5.6.5版本

新增了一种基于GTID的复制方式，强化了数据库的主备一致性，故障恢复以及容错能力，取代传统的基

于file和position主从复制，使得在MySQL主备切换时，仍能准确定位到Binlog位点。

GTID的格式形如：source_id:transaction_id，其中source_id表示MySQL服务器的uuid，

transac