MYSQL5.7多线程复制原理

MYSQL5.7多线程复制原理

在使用mysql的过程中，复制延迟一直是一个DBA头疼的问题。

延迟优化方法：

• 增大从库参数innodb_buffer_pool_size的值，可以缓存更多数据，减少由于转换导致的IO压力。
• 增大参数innodb_log_file_size,innodb_log_file_in_group的值，减少buffer pool的磁盘IO，提升写入性能。
• 修改参数innodb_flush_method为 O_DIRECT，提升写入性能（在ssd下，或者磁盘IO能力强的时候推荐使用）.
• 如果可以的话，把从库binlog关掉，或者关掉参数log_slave_updates.
• 修改参数innodb_flush_log_at_trx_commit为0 或者2.
• 如果binlog没有关掉，修改sync_binlog参数为0或一个很大的数，减少磁盘压力。
• 如果binlog_format为ROW模式，并且被修改表没有主键，则需要加上主键。
• 如果binlog_format为ROW模式，则可以在从库中删掉一些不必要的索引，同步之后在加上。
• 了解清楚写库上的操作内容，适当地在从库中预热以下数据，可以减少在复制时等待的时间。
• 如果binlog_format为STATEMENT模式，或者存在DDL复制，则可以将tmpdir参数改到内存中，比如/dev/shm
• 修改参数master_info_info_repository,relay_log_info_repository为table，减少直接IO导致的磁盘压力。
• 升级硬件。
• 将mysql升级到5.7版本，使用多线程并行复制。

 

mysql5.6的多线程复制。

使用5.6的多线程复制是有条件的：

1. 当前实例中涉及的数据库比较多。
2. 每个数据库写入的数据比较均匀。

在一般的mysql使用中，一库多表比较常见，而多库少表比较少见。单单是这一点，就把很多人希望通过升级5.6的多线程复制来解决主从延迟的想法给抹杀了。

mysql5.7版本的多线程复制

5.6表面已经支持并行复制了，但实际上属于雷大雨小。这种并行复制的功能出来之后，很多人都觉得不太合适，使用的人很少。
之后5.7的beta版本柴胡来了，它的并行复制以一种全新的姿态出现在了DBA面前，每个人都叫好，把解决复制延迟的希望，放在了mysql5.7版本上。5.7也被认为是原汁原味的并行复制，并行复制本来就应该做成这个样子。

5.7的并行复制是如何实现的呢？

首先5.7的并行复制基于一个前提，所有已经处于prepare阶段的事务，都是可以进行并行提交的，这些当然也可以在从库中并行提交，因为处于这个阶段的事务，都是没有冲突的，该获取的资源都已经获取了，反过来说，如果有冲突，则后来的会等已经获取资源的事务完成之后才能继续，故而不会进入prepare阶段，这时一种新的并行复制思路，完全摆脱了原来一直致力于未来防止冲突而做的分发算法，等待策略等复杂而又效率低的下的工作。