【解决从库复制延迟的问题】

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

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

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

10.解决从库复制延迟的问题

• 架构方面

  1. 业务的持久化层的实现采用分库架构，mysql 服务可平行扩展，分散压力。

  2. 单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。

  3. 服务的基础架构在业务和 mysql 之间加入 memcache 或者 redis 的 cache 层。降低 mysql 的读压力。

  4. 不同业务的 mysql 物理上放在不同机器，分散压力。

  5. 使用比主库更好的硬件设备作为 slave，mysql 压力小，延迟自然会变小。

• 硬件方面

  1. 采用好服务器，比如 4u 比 2u 性能明显好，2u 比 1u 性能明显好。

  2. 存储用 ssd 或者盘阵或者 san，提升随机写的性能。

  3. 主从间保证处在同一个交换机下面，并且是万兆环境。

  4. 总结，硬件强劲，延迟自然会变小。一句话，缩小延迟的解决方案就是花钱和花时间。

• mysql 主从同步加速

  1. sync_binlog在 slave 端设置为 0

  2. –logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。

  3. 直接禁用slave端的 binlog

  4. slave端，如果使用的存储引擎是 innodb，innodb_flush_log_at_trx_commit =2

• 从文件系统本身属性角度优化
  master 端修改 linux、Unix 文件系统中文件的 etime 属性， 由于每当读文件时 OS 都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响 I/O 性能。可以通过设置文件系统的 mount 属性，组织操作系统写 atime 信息，在 linux 上的操作为：打开/etc/fstab，加上 noatime 参数/dev/sdb1 /data reiserfs noatime 1 2 然后重新 mount 文件系统#mount -oremount /data

• 同步参数调整主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置是需要的而 slave 则不需要这么高的数据安全，完全可以讲sync_binlog设置为 0 或者关闭 binlog，innodb_flushlog也可以设置为 0 来提高 sql 的执行效率

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

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

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