主从延迟

一、传输延迟

　　一般情况况下不会有传输延迟，传输延迟主要取决于下面的几个因素

　　　　1、网络性能，很多主从可能会跨机房，跨机房的网络速度一般<=100Mb/s，因此这个可能会成为瓶颈，这个需要通过监控来确定,sar命令可以看一下当前带宽是否饱和

　　　　2、从库写性能，对于从库relay log的位置需要支持写缓存，一般通过外置raid卡来实现

　　　　3、主库进行批量数据导入、ddl操作，产生海量binlog，也容易导致传输延迟

　　　　4、主库dml负载很重，因为主库会有很多会话同时工作，因此可能产生很多binlog

　　　　5、binlog启用了row模式或者mixed模式

　　　　6、两个非常重要的日志文件，如果这两个文件出现损坏，主从数据库就会被废掉

　　　　　　master info、relay info

　　　　　　　　记录着传输延迟和应用延迟，对于io线程和sql线程来说，如果延迟计算错误，就会带来主从数据不一致；因此我们建议将这两个文件进行表化，因为这两个表属于innodb表，受到redo的保护，即使系统掉电，也会被保护。

　　　　7、要求能够读懂master info和relay info

　　　　　　这两个文件的作用

　　　　　　1、确定是否新的binlog生成，dump线程会读取对应的新增binlog(master记录binlog最新位置、slave记录传输最新位置)

　　　　　　2、确定sql应用起点，这个主要读取slave中的relay log位置

　　　　　　3、我们可以计算从库的传输延迟和应用延迟，这些都相对主库的binlog位置

二、应用延迟

　　1、最主要的问题就是主库有很多工作线程，但是从库的sql应用线程的数量很少，在5.7以前都是单线程应用，因此存在严重的应用延迟

　　2、5.7开始，支持并行复制，这是5.7最大的贡献，因此需要启用并行复制，并行复制的线程的数量=cpu core的数量

　　3、对于row或者mixed模式的情况下，如果主库dml sql没有走索引(无对应索引)，在从库端，每一个row sql都会进行全表扫描，导致严重的性能问题，这是一个特例，因此强烈建议主库所有dml sql都要走索引

　　4、建议将从库启动到read only模式，防止从库被dml修改，将来发生主从切换以后，出现数据不一致

　　5、对于ddl以及批量dml，建议在会话端关闭binlog，然后在从库手工执行ddl或者批量dml，来降低延迟，特别是对于ddl

　　6、从库对于一些常见错误的自动skip，例如ddl对应的对象已经存在， --skip-slave-error=ddl_exist_errors

　　7、半同步复制对生产没有很大的意义，因此不建议使用

　　　　对于网络的性能抖动，会影响主库的事务提交，导致业务失败

　　　　主从核心的问题是应用延迟，半同步复制关注的是传输延迟,因此意义不是很大,但是带来的故障影响大

 

转载于:https://www.cnblogs.com/5945yang/p/11301165.html