【主从延时排查方法】

💝💝💝欢迎来到我的博客，很高兴能够在这里和您见面！希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。

• 持续学习,不断总结,共同进步,活到老学到老
• 人生的本质是追寻自我的提升，包括思想、能力、意志等等。
• 直面变化，找到背后更基础的东西，更基础的东西是用户的需求。
• 我们的成功是我们的现在和将来决定的。今天和明天已经由昨天决定，你还可以决定后天。

非常期待和您一起在这个小小的网络世界里共同探索、学习和成长。💝💝💝 ✨✨ 欢迎订阅本专栏 ✨✨

7.主从同步延迟原因

MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。
Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。
另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的 DML 数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。

常见原因：

• Master 负载过高
• Slave 负载过高
• 网络延迟
• 机器性能太低
• MySQL 配置不合理

8.主从延时排查方法

通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断：

• NULL，表示 io_thread 或是 sql_thread 有任何一个发生故障；
• 0，该值为零，表示主从复制良好；
• 正值，表示主从已经出现延时，数字越大表示从库延迟越严重

9.解决数据丢失问题

解决数据丢失的问题：

• 半同步复制:从 MySQL5.5 开始，MySQL 已经支持半同步复制了，半同步复制介于异步复制和同步复制之间，主库在执行完事务后不立刻返回结果给客户端，需要等待至少一个从库接收到并写到 relay log 中才返回结果给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一个TCP/IP往返耗时的延迟。
• 主库配置sync_binlog=1，innodb_flush_log_at_trx_commit=1 sync_binlog的默认值是 0，MySQL 不会将binlog同步到磁盘，其值表示每写多少binlog同步一次磁盘。innodb_flush_log_at_trx_commit为 1 表示每一次事务提交或事务外的指令都需要把日志 flush 到磁盘。

注意:将以上两个值同时设置为 1 时，写入性能会受到一定限制，只有对数据安全性要求很高的场景才建议使用，比如涉及到钱的订单支付业务，而且系统 I/O 能力必须可以支撑！

觉得有用的话点个赞 👍🏻 呗。
❤️❤️❤️本人水平有限，如有纰漏，欢迎各位大佬评论批评指正！😄😄😄

💘💘💘如果觉得这篇文对你有帮助的话，也请给个点赞、收藏下吧，非常感谢!👍 👍 👍

🔥🔥🔥Stay Hungry Stay Foolish 道阻且长,行则将至,让我们一起加油吧！🌙🌙🌙