mysql读写分离延时_MySQL读写分离及主从同步延时解决方案

读写分离的实现是基于主从复制架构&＃xff1a;一主多从&＃xff0c;只写主库&＃xff0c;主库会自动将数据同步到从库。

1 为什么要读写分离&＃xff1f;

主库将变更写binlog日志&＃xff0c;然后从库连接到主库后&＃xff0c;从库有个I/O线程&＃xff0c;将主库的binlog日志拷贝到本地&＃xff0c;写入一个中继日志。

接着从库中有一个SQL线程会从中继日志读取binlog&＃xff0c;然后执行binlog日志中的内容。即在本地再次执行一遍SQL&＃xff0c;确保跟主库的数据相同。

2 MySQL主从复制原理

MySQL的每个增删改的会改变数据的操作&＃xff0c;除了更新数据外&＃xff0c;对这个增删改操作还会写入一个日志文件&＃xff0c;记录这个操作的日志&＃xff0c;即binlog。

mysql 5.7新版本的并行复制&＃xff0c;多个SQL线程&＃xff0c;每个线程从relay日志里读一个库的

日志&＃xff0c;重放。

从库同步主库数据的过程是串行化的&＃xff0c;即主库上并行的操作&＃xff0c;在从库上会串行执行。

由于从库从主库拷贝日志以及串行执行SQL的特点&＃xff0c;在高并发下就有延时&＃xff0c;从库数据一定比主库慢&＃xff0c;所以经常出现&＃xff0c;刚写入主库的数据读不到&＃xff0c;要过几十甚至几百ms才能读到。

从库串行化过程&＃xff1a;

读取binlog日志

写relay日志、应用日志变更到自己本地数据

从库的IO线程&＃xff0c;读取主库的binlog日志时&＃xff0c;老版本是单线程&＃xff1b;

5.6.x之后的新版本支持多线程读取

另外的问题&＃xff0c;若主库突然宕机&＃xff0c;恰好数据还没同步到从库&＃xff0c;那么有些数据可能在从库上是没有的&＃xff0c;可能就这么丢失了。

所以MySQL实际上在这有两个机制

3 半同步复制

semi-sync&＃xff0c;解决主库数据丢失问题。

主库写入binlog日志后&＃xff0c;会强制立即将数据同步到从库

从库将日志写入自己的relay log后&＃xff0c;会返回ack给主库

主库接收到至少一个从库的ack后才会认为写操作完成

4 并行复制

解决主从同步延时问题。

从库开启多线程&＃xff0c;并行读取relay log中不同库的日志&＃xff0c;然后并行重放不同库的日志&＃xff0c;这是库级别的并行。

5 MySQL主从同步适用场景

建议一般在读远远多于写&＃xff0c;且读的时候一般对数据时效性要求没那么高的时候采用。所以我们可以考虑的就是&＃xff0c;你可以用MySQL的并行复制&＃xff0c;但问题是那是库级别的并行&＃xff0c;所以有时候作用不是很大。

此时,通常来说&＃xff0c;我们会对于那种写后立马就要保证可以查到的场景&＃xff0c;采用强制读主库的方式&＃xff0c;确保你肯定可以读到数据。其实用一些数据库中间件也是没问题的。

一般若主从延迟较为严重&＃xff1a;

分库 : 将一个主库拆分&＃xff0c;每个主库的写并发就降低了&＃xff0c;主从延迟即可忽略不计

打开MySQL支持的并行复制&＃xff0c;多个库并行复制&＃xff0c;若某个库的写入并发特别高&＃xff0c;写并发达到了2000/s&＃xff0c;并行复制还是没意义。二八法则&＃xff0c;很多时候比如说&＃xff0c;就是少数的几个订单表&＃xff0c;写入了2000/s&＃xff0c;其他几十个表10/s

重构代码 : 重构代码&＃xff0c;插入数据后&＃xff0c;直接更新&＃xff0c;不查询

若确实存在必须先插入&＃xff0c;立马要求查询&＃xff0c;然后立马就反过来执行一些操作&＃xff0c;对这个查询设置直连主库(不推荐&＃xff0c;这么搞导致读写分离的意义丧失)

作者&＃xff1a; qq_33589510

链接&＃xff1a; https://blog.csdn.net/qq_33589510/article/details/95791086

著作权归作者所有。商业转载请联系作者获得授权&＃xff0c;非商业转载请注明出处。

到此这篇关于“MySQL读写分离及主从同步延时解决方案”的文章就介绍到这了,更多文章或继续浏览下面的相关文章&＃xff0c;希望大家以后多多支持Go语言编程网&＃xff01;

相关文章&＃xff1a;