全网最全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版吧。