如何解决主库插入记录后，无法从从库中及时读取的问题,如何从架构上避免这种问题
在网上见过新建一个版本库的表，然后利用mysql proxy判断数据是否是最新的，然后路由到主库或者是从库，请问这个方案是可行的吗？具体如何操作？
作者：姜健
链接：https://www.zhihu.com/question/20025096/answer/82440882
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
题主说的方案感觉非常不靠谱。
不过mysql-proxy本人也几乎没怎么接触，它能否实现上诉功能有些不大确定，即使它有，也不建议为了这个就用它，官网自己都不推荐用到生产环境。
针对主从延迟，本人的经验如下：
业务量不大的
主库能处理业务就全放在主库吧，从库只做灾备，备份，对实时性要求不高的统计报表类工作；
已经出现延迟的
一般来说，就慢慢等吧，试图通过重启db之类的操作是无法解决的，还会因为大事务回滚再重做导致花的时间更长。
延迟N天无法解决的
那就重做slave。
为什么会延迟N天，难道仅仅是因为从库单线程吗？
我感觉大部分都是主库上采用mixed的binlog_format，由于某种限制，无法基于statement，只好row模式复制。
那么如果当前sql是全表扫描，传到slave上执行时就是茫茫多次的全表扫描了。
一般来说在slave上show proceslist看查看当前的system user正在执行什么，那就是问题SQL。如果pos点一直不动，也可以去主库对应的binlog上查看下执行的是什么玩意。
出现延迟时，查看下当前slave的cpu和磁盘状况
一般来说如果从库没有其他业务，单线程的原因，cpu跑满一个核已经是极限了。磁盘io满的话，确认下是否有其他进程或mysql线程影响了它(比如从库正在dump或者超大的sql在执行)，也可以尝试调整下slave上关于io的几个参数
从库raid卡，务必设置成write back的写策略
这点本人深受其害，查了几个月才发现为什么我的SSD io性能这么烂。
批量的dml操作
批量的dml操作如果不做处理，一般必然会出现延迟，建议业务低峰期执行，并将批量操作做下调整，一次dml 10000行，sleep一会，再dml 10000行。
具体的行数和sleep需要自己根据业务确定，能保证从库不延迟就好。
一点别的tips：
如果还是经常性的短时间延迟，那就尝试加大从库的硬件配置，比如上sata SSD，pcie等
延迟的监控到位，可通过pt-heart-beat来准确监控延迟值，及时发现查看。
5.5以后版本的，可以考虑采用半同步复制，能解决少量延迟引起的问题，不过对tps性能损耗较大
升级到mysql 5.7吧，多线程复制，几乎完美解决单线程复制引起的从库延迟。
作者：姜健
链接：https://www.zhihu.com/question/20025096/answer/82440882
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
题主说的方案感觉非常不靠谱。
不过mysql-proxy本人也几乎没怎么接触，它能否实现上诉功能有些不大确定，即使它有，也不建议为了这个就用它，官网自己都不推荐用到生产环境。
针对主从延迟，本人的经验如下：
业务量不大的
主库能处理业务就全放在主库吧，从库只做灾备，备份，对实时性要求不高的统计报表类工作；
已经出现延迟的
一般来说，就慢慢等吧，试图通过重启db之类的操作是无法解决的，还会因为大事务回滚再重做导致花的时间更长。
延迟N天无法解决的
那就重做slave。
为什么会延迟N天，难道仅仅是因为从库单线程吗？
我感觉大部分都是主库上采用mixed的binlog_format，由于某种限制，无法基于statement，只好row模式复制。
那么如果当前sql是全表扫描，传到slave上执行时就是茫茫多次的全表扫描了。
一般来说在slave上show proceslist看查看当前的system user正在执行什么，那就是问题SQL。如果pos点一直不动，也可以去主库对应的binlog上查看下执行的是什么玩意。
出现延迟时，查看下当前slave的cpu和磁盘状况
一般来说如果从库没有其他业务，单线程的原因，cpu跑满一个核已经是极限了。磁盘io满的话，确认下是否有其他进程或mysql线程影响了它(比如从库正在dump或者超大的sql在执行)，也可以尝试调整下slave上关于io的几个参数
从库raid卡，务必设置成write back的写策略
这点本人深受其害，查了几个月才发现为什么我的SSD io性能这么烂。
批量的dml操作
批量的dml操作如果不做处理，一般必然会出现延迟，建议业务低峰期执行，并将批量操作做下调整，一次dml 10000行，sleep一会，再dml 10000行。
具体的行数和sleep需要自己根据业务确定，能保证从库不延迟就好。
一点别的tips：
如果还是经常性的短时间延迟，那就尝试加大从库的硬件配置，比如上sata SSD，pcie等
延迟的监控到位，可通过pt-heart-beat来准确监控延迟值，及时发现查看。
5.5以后版本的，可以考虑采用半同步复制，能解决少量延迟引起的问题，不过对tps性能损耗较大
升级到mysql 5.7吧，多线程复制，几乎完美解决单线程复制引起的从库延迟。
