MySQL 5.7下主从复制延迟解决方案

共计 3259 个字符，预计需要花费 9 分钟才能阅读完成。

  在 MySQL 下主从复制的延迟问题一直是在业界内比较大的困扰，主从的延迟会因为受到网络磁盘等等相关的因素影响，但其中最主要的影响是就是在 master 太过繁忙的写入导致 slave 无法有效的从 relay_log 中读取到最新的相关记录，这样对于数据实时性很高的业务来说 slave 的数据并不是最新的有一定的延时，此时使用主从的读写分离就有点显的鸡肋了，不能做到 slave 上能查到最新的实时数据，大多在 slave 上都是做一些对实时数据要求并不是很高的一些数据查询。

  而到了 MySQL 的 5.6 版本开始引入多线程的主从复制的机制，众所周知 MySQL 的工作方式是单进程多线程的方式，那么线程的多寡则会极大的影响到 MySQL 的效率，而在早期 MySQL 的主从都是由单线程进行的，使得主从复制除了相关的客观因素外还受到自身的影响。但是在 MySQL 5.6 下多线程主从复制并不是做的相当完善的，因为在 MySQL 5.6 中主从复制的多线程是一个线程处理一个主从复制，而在绝大多数的生产环境中大多都是在一个数据库中做大量的操作的，那么这样 MySQL 的多线程主从复制就又和以前的版本一样都是单线程的主从复制，没有太大的实际意义。为此在 MySQL 的 5.7 版本中对多线程主从复制来进一步的改善，在 MySQL 5.7 中是按照逻辑时钟（类似 CPU 的处理机制）来处理多线程，甚至在半同步复制 semisync 中还是使用 Performance Schema 表来监控复制线程，所以在 MySQL 5.7 中主从复制直接因为 MySQL 自身导致的延时被极大的降低了, 配置也很简单，如下在 salve 中配置：

此时再根据实际情况决定开启多少个线程用于主从复制，此时在看下 slave 上的线程列表：

这样就成功的开启 MySQL 的 5.7 版本多线程主从复制，在配置好后在 slave 的 datadir 目录下会有根据 slave_parallel_workers 设置的线程数个数相同的线程文件：

最后再把配置好的变量参数写入 my.cnf，使得下一次重启生效：

Ubuntu 16.04 下实现 MySQL 主从复制  http://www.linuxidc.com/Linux/2017-08/146624.htm

MySQL 5.6.26 主从复制报错 1050  http://www.linuxidc.com/Linux/2017-08/146203.htm

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-09/146663.htm