在MYSQL 部署架构选型上,许多公司都会用到主从读写分离的架构,如下是一个一主一从的架构,主库master负责写入,从库slave进行读取。
但是既然是读写分离,必然会面临这样一个问题,当在主库上进行更新后,有可能数据还没来得及同步到从库,但是这个时候又有读数据的需求,为了能正确读取出数据,这个时候就只有读主库了。但是这样做增加了主库的压力,违反了我们做读写分离的初衷。所以这一节我们就来针对这种情况探讨下,如何尽量的避免对主库的压力,尽量的从从库读取数据。
主从复制的原理
在探讨解决方案前,我们先要对主从复制的原理有所了解,数据库的操作都会记录到binlog,如下图所示,
1,从数据库(slave
)会启动两个线程io_thread
和sql_thread
,通过io_thread将自身与主数据库(master
)建立连接。
2,slave向master发出要同步的位置信息(包含同步的文件名和偏移量),表示需要从该位置发起同步。
3,主数据库master 将位置点后的binlog发送给slave, slave获取到本地形成relay log
(中转日志)。
4, 接着通过sql_thread解析relay log,执行sql。
从主从复制的过程可以看出,主从延迟时间是 在主库master执行sql的时间点到从库通过解析relay log 执行sql后的时间点之间的差值。如果应用程序能够在master写入数据后等待这么一段时间,再去slave读取,就能正确的读取出来数据了。
但是这个时间差值是不确定的,究竟应用程序需要等待多久才去读取slave,就成了我们需要思考
标签:binlog,slave,读写,master,MYSQL,从库,位点,主从,GTID From: https://www.cnblogs.com/hobbybear/p/18061516