MySQL复制(一) - 异步复制

​MySQL依靠轻量级的复制功能立足于互联网行业的数据库市场，同时依靠binlog可二次开发的能力，也为大数据场景发挥其特有的作用。你对MySQL主从复制了解多少？在当今云市场的猛烈轰击下，作为开发的你是否还需要关心这些底层组件呢？下面我们来了解下MySQL复制的基础架构和原理吧。

一. MySQL复制架构

1.1 binlog文件

事务提交时会生成对应的binlog事件，记录内容依赖于日志格式设置，statement格式会记录原始的SQL语句，row格式会记录所变更行的内容；每个会话拥有独立的binlog cache，单个事务的binlog事件不能拆分保存到不同的binlog文件(如有大事务，像大数据推数，load data等)会产生超过max_binlog_size的文件，同时也会引起从库延迟，需要规避。

binlog写到日志文件后，在主从环境下，主库的dump 线程会将日志发送给从库。

binlog 日志格式支持：

• row，行格式，记录变更行的内容，日志最大，但对数据恢复以及对接大数据生态系统非常有用，建议格式；
• statement，语句格式，记录完整的SQL语句，对随机函数会有主从数据一致性问题；
• mixed，混合格式，结合了row和statement的特点

1.2 复制架构

主库为每个从库分配一个dump thread，从库有IO thread和SQL thread，IO线程从主库拉取和接收事件，写入到从库的relay log文件，SQL从relay log读取事件进行应用。

架构如图：

主库上binlog是否在事务提交时写入到磁盘，由参考sync_binlog参数控制：

• 0，事务提交时不同步(sync)写到磁盘，由操作系统控制
• 1，事务提交时同步写到磁盘，推荐设置，保证数据一致性，异常的重启不会丢失binlog
• N，多少个事务后再进行一次同步写磁盘操作

从库上IO线程拉取binlog的位置点由参数master_info_repository=TABLE控制，SQL线程应用relay log的位置点由参数relay_log_info_repository=TABLE控制，都建议设置为TABLE，提高性能的同时，也能避免写入文件造成的记录位置点跟应用事件位置不一致的问题。

二. MySQL复制的缺陷

基于上述的复制架构来看，如果主库事务量大，或者有大事务操作，从库单线程的SQL线程应用事件会造成从库延迟，同时如果主库在这时出现挂掉问题，将会造成主从数据不一致等问题。

如果因异常操作删除了数据或库表等，怎么做到快速进行数据恢复？同时如何将分库分表等多实例场景的数据聚合到一个实例，实现统计等需求呢？

基于以上的一些问题，从5.5开始进行大量的优化和改造：

• 5.5 引入半同步机制，一定程度上确保主从数据的一致性，5.7 引入lossless(无损)复制，进一步保障主从数据一致性；
• 5.6 引入延迟数据，对非常核心的业务可以设置延迟从库来做到数据的快速恢复；
• 5.6 引入基于database的并行复制，5.7引入基于组提交的并行复制，5.7.22引入基于writeset的并行复制，完美解决主从延迟的问题；
• 5.7 开始支持多源复制，实现数据聚合。