一、主备延迟
数据同步的关键时间节点:
- 主库A执行完一个事务、写入binlog、记为 T1;
- 传给备库B、将备库B接收完binlog的时刻记为 T2;
- 备库B执行完事务的时刻记为 T3;
主备延迟: 同一个事务在备库执行完的时间和主库执行完的时间之间的差值: T3 - T1
show slave status; - seconds_behind_master表示当前备库延迟时间
注: 主备机的系统时间不一致时、会不会导致主备延迟值不准 ?
不会. 备库连接主库时、会通过执行 select unix_timestamp 获得当前主库的系统时间、与本机不一致时、会在执行 seconds_behind_master 时扣除差值
二、主备延迟的来源
- 有些部署条件下、备库所在机器的性能较差
此时一般将备库设为非双1模式. 现在一般会使用对称部署(主备规格相同). - 使用对称部署、为何仍然存在主备延迟 ?
备库可能压力较大、存在一些慢查询、导致备库查询消耗大量CPU资源、影响数据同步、造成主备延迟.
解决:
1) 使用一主多从、分担读压力
2) 通过binlog输出到外部系统、如: hadoop, 提供统计类查询 - 采用了一主多从、备库的压力不超过主库的情况下、还有什么情况会导致主备延迟呢 ?
1) 可能存在大的事务, 因为主库上必须等事务执行完成才会写入binlog、再传给备库、若一个SQL执行10min、这个事务就很可能会导致从库延迟10min.(所以最好不要一次delete太多数据)
2) 大表DDL也是一个大事务的场景 - 如果备库上也不做大事务了、还有什么原因会导致主备延迟吗 ?
备库的并行复制能力.
三、主备切换策略:
可靠性优先.
1) 先判断备库B的 seconds_behind_master 是否小于指定值, 若否、持续观察
2) 把主库A改成只读状态, readonly设为true.
3) 判断备库B的 seconds_behind_master 值、直到变为0
4) 把备库B改为可写入, readonly设为false.
5) 将业务请求切到B
2~5 的过程、系统处于不可用状态.可用性优先
将1中、4)、5) 调整到最开始执行、直接让备库可读写、系统就无不可用时间、但会产生数据不一致. 暂时称为可用性优先策略
此时若 binlog_format 为: statement、则会发生数据不一致的线下
若 binlog_format 为: row、会提示错误
所以、MySQL高可用系统的可用性是依赖于主备延迟的、延迟的时间越小、在主库故障时、服务恢复需要的时间就越短, 可用性就越高.