全网最全MySQL多线程复制原理，深入浅出的进军数据库开发

前言

MySQL通过Binlog进行主从复制，一直是用户爱恨交加的一个实现方式。所谓爱，在于它维护容易、分析简单且架构设计可以变化多端，这在使用MySQL的过程中，可以发挥DBA的想象来解决各种各样的问题，所以受到了业界朋友的青睐。说到恨，有一个问题很是令DBA头疼，即主从复制延迟的问题。一般在问题出现时，DBA只能看着，一脸茫然，无法下手，只能静静地等着它追上来(当然也有一些方法，可以适当地提升其速度，但一般都是补救，不能将速度一下子提升几倍之多)，这时DBA可能就会对它“恨铁不成钢”了吧。

 

行之有效的延迟优化方法

那么在延迟的时候，如何适当地提升速度呢?一般有如下这些方式。

• 增大从库参数innodb_buffer_pool_size 的值，可以缓存更多数据，减少由于转换导致的IO压力。
• 增大参数innodb_log_file_size_innodb_log_files_in_group 的值，减少BUFFER POOL的刷盘IO，提升写入性能。
• 修改参数innodb_fush_method 为O_DIRECT，提升写入性能(在ssd下，或者磁盘IO能力强的时候推荐使用)。
• 如果可以的话，把从库Binlog 关掉，或者关掉参数log_slave_updates。
• 修改参数innodb_flush_log at_trx_commit 为0或2。
• 如果Binlog没有关掉，修改sync_binlog 参数为0或一个很大的数，减少磁盘I0压力。
• 如果binlog_format 为ROW模式，并且被修改表没有主键，则需要加上主键。
• 如果binlog_format为ROW模式，则可以在从库中删掉一些不必要的索引(同步完毕之后再加上)。
• 了解清楚写库上的操作内容，适当地在从库中预热一下数据，可以减少在复制时等待的时间。
• 如果binlog format为STATEMENT模式，或者存在DDL复制，则可以将tmpdir参数改到内存中，比如/dev/shm。
• 修改参数master_info_repository_relay_log_info_ repository 为TABLE,，少直接IO导致的磁盘压力。
• 将从库的服务迁走，当然这是指简单的处理，比如使VIP飘到其他节点上等。
• 升级硬件，这种方法比较暴力，但一般情况下不太实际。
• 如果当前版本是MySQL 5.6版，并且实例中数据库比较多，写人比较均匀，则可以打开多线程复制。
• 升级成MySQL 5.7版吧。

MySQL 5.7的多线程复制

首先，MySQL 5.7的并行复制基于一个前提，即所有已经处于prepare阶段的事务，都是可以并行提交的。这些当然也可以在从库中并行提交，因为处理这个阶段的事务，都是没有冲突的，该获取的资源都已经获取了。反过来说，如果有冲突，则后来的会等已经获取资源的事务完成之后才能继续，故而