详解如何避免MYSQL主从延迟带来的读写问题，
目录
- 主从复制的原理
- 如何避免延迟期间的主从数据不一致
- 判断位点是否同步
- 判断GTID 是否同步
- 什么是GTID值？
- GTID 模式下判断同步的步骤
在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，就成了我们需要思考
本站文章为和通数据库网友分享或者投稿，欢迎任何形式的转载，但请务必注明出处.
同时文章内容如有侵犯了您的权益，请联系QQ：970679559，我们会在尽快处理。