跨云迁移过程中的数据同步及一致性校验实践（一）

正文

请到「今天看啥」查看全文

MySQL同步

一般来说，我们认为对于MySQL的同步，只要存量数据和增量数据都能做到一致，那么整个数据库的同步就是一致的。 而常见的MySQL数据迁移方式有两种： 一种是基于MySQL主从的方式，通过mysqldump记录下binlog位置，然后把这个binlog位置前的数据完整导出，恢复出一个备库，然后再从记录的binlog位置开始向主库追平增量数据。

另一种就是UDTS工具，总体上也是分为存量阶段和增量阶段，增量阶段的追及是将从存量同步发起的一瞬间开始往后的数据变化通过binlog的形式同步到目标库。增量同步依靠binlog完成，这是MySQL主从同步的基础，是我们需要默认信任的数据一致性机制，当然我们最终需要以数据校验结果来确认数据是否一致。简而言之， 跨云迁移过程中MySQL的数据一致性主要就集中在存量数据的迁移如何保证一致。

【案例】

以近期的xx公司迁移到UCloud为例，其涉及数据库实例有数十个，并且由于应用依赖的原因需要进行整体迁移。 在这案例中，如果采用mysqldump的方法，那么这数十个数据库都需要经过导出、传输、导入和配置主从这样的操作，给整个迁移任务增加了不少工作量。

同时也正如很多商业智能应用需要将数据汇总用作分析，这家公司的业务系统也有类似的汇总数据库，这种级联关系会让数据同步操作进一步复杂化。最终该公司使用了UDTS作为跨云数据同步的解决方案，在保障数据一致的同时，DBA只需要提供两边数据库的连接和账号信息即可将数据同步任务托管，释放了运维人员的精力，专注去处理业务上的数据库工作需求。

数据同步

前面提到MySQL事务，在理解存量数据迁移过程中的数据一致性时，需要先了解InnoDB为代表的事务引擎和MyISAM代表的非事务引擎。使用MyISAM引擎的数据表确实没有很好的数据一致性确保手段，存量数据只能对数据表加读锁并迁移，在完成存量数据同步后，通过binlog追平，这样因为读锁会阻塞数据的写入，会导致业务的写入功能不可用，而且这一不可用的时间视表中数据体量而定。

然而因为MyISAM的不灵活，实际互联网公司中已经很少使用MyISAM引擎了。而InnoDB引擎因为它支持事务和行级锁的特性，在数据同步过程中对业务的影响小很多，但也因此对数据一致性的保护方法也相对复杂，而这一套一致性保护方法，核心就在于基于连接session的事务隔离和基于MVCC的数据版本管理，而UDTS也正是基于此而实现数据一致。

数据校验

数据一致性的关键，除了数据同步过程中的一致性保障，更加简单直接的手段是数据校验，只有对比过数据是一致的，那才是真正的一致。MySQL数据校验的手段有很多，其中最经典的是pt-table-checksum。

pt-table-checksum会新建一个临时的checksum表，并且获取与主库有主从关系的所有从库信息。在校验工作时，工具会将该session的binlog格式设置为statement，这样是为了利用mysql的binlog机制，将主库上执行的sql语句同步到从库去。接着工具会以chunk为单位从主库中读取数据和计算校验，将校验结果写入checksum表，这个过程会在一个语句中完成，随后这个语句由于对checksum表进行修改，会被同步到从库并且被从库执行。这样从库也会在自己的checksum表写入校验值。这个时候工具再从库中把checksum值读出，就可以与主库的计算值进行对比。

pt-table-checksum的优势在于使用方便，在经历了多年迭代也有非常好的可靠性保证。但是它的技术限制也是明显，那就是要求被校验的两个库需要是主从关系，同时也要求数据表有索引，因为chunk大小的计算是通过索引完成的。

请到「今天看啥」查看全文