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

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL 5.7下主从复制延迟解决方案相关的知识,希望对你有一定的参考价值。

   在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中配置:

mysql> show global variables like ‘slave_parallel_workers‘;#默认是0,即单线程
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+
1 row in set (0.01 sec)
mysql> set global slave_parallel_workers = 4;#根据实际情况决定开启多少个线程用于主从复制
1 row in set (0.01 sec)
mysql> show global variables like ‘%slave_parallel_type%‘;#默认是多线程机制是一个线程处理一个库
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slave_parallel_type | DATABASE |
+---------------------+----------+
1 row in set (0.01 sec)
mysql> stop slave;#修改多线程机制工作类型需要停止slave
Query OK, 0 rows affected (0.21 sec)
mysql> set global slave_parallel_type=‘logical_clock‘;
1 row in set (0.01 sec)
mysql> start slave;    
Query OK, 0 rows affected (0.08 sec)

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

mysql> show full processlist;
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
| Id | User        | Host      | db   | Command | Time | State                                                  | Info                  |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
| 16 | root        | localhost | NULL | Query   |    0 | starting                                               | show full processlist |
| 29 | system user |           | NULL | Connect |    3 | Waiting for master to send event                       | NULL                  |
| 30 | system user |           | NULL | Connect |    3 | Slave has read all relay log; waiting for more updates | NULL                  |
| 31 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 32 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 33 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
| 34 | system user |           | NULL | Connect |    3 | Waiting for an event from Coordinator                  | NULL                  |
+----+-------------+-----------+------+---------+------+--------------------------------------------------------+-----------------------+
7 rows in set (0.00 sec)

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

技术分享

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

slave_parallel_workers = 4
slave_parallel_type= logical_clock

本文出自 “Jim的技术随笔” 博客,谢绝转载!

以上是关于MySQL 5.7下主从复制延迟解决方案的主要内容,如果未能解决你的问题,请参考以下文章

MySQL 5.7 并行复制

mysql 5.7多源复制如何去掉一个复制源

MySQL 5.7 延迟复制环境搭建和测试

MySQL主从复制延迟解决方案

MySQL 5.7复制延迟之sync_relay_log

Linux下MySQL 5.7 主从复制(主从同步)