mysql是怎么保证高可用的–如何解决主备延迟
mysql的主从同步会保证主库到从库的最终一致性，但是mysql的高可用，光有最终一致性是远远不够的。下面会讨论影响mysql主备高可用的因素以及解决方法。
主备延迟
- 我们在备库上可以执行命令：seconds_behind_master来查看备库的状态，会显示备库同步数据和主库的时间差（单位：秒），这个时间差计算方式是：同一事物，备库执行完binlog的时间-主库产生binlog的时间备库执行的binlog的时间，当然这个值越小越好。
- 在网络正常的情况下，主备同步binlog的时间往往很短，真正造成主备延迟的原因往往是relylog的消费赶不上binlog的生产。那么是什么造成主备延迟的呢
主备延迟的原因
- 主备库，备库的性能要不主库所在的的机器性能差；–目前很少见了，因为大多是双M配置，所以备库可能会变为主，所以在部署时候都会选择对称部署；
- 备库压力大，备库上很多的查询需求，比如备份数据，运营统计等会放在备库执行。在同步binlog时候往往也会占用查询的资源，导致备库的眼里很大，引起主备延迟
- 大事物，由于mysql是在主库上事物提交之后才开始传输binlog给备库，这样如果1个很大的事物在主库执行N长时间后，在同步给备库，备库在执行这个事物时候就会造成主从不一致。
- 一次删除很多的数据，如：数据库快满了删除数据；
- 大表的DDL
- 库的并行复制能力,具体放在mysql是如何降低主备延迟的
主备延迟的解决方案
- 首先对于双M架构，主备库建议对称部署，保证切换朱备库时候性能没有打的差别
- 建议根据需要一主多从，比如说：一个主备做为切换，一个从库作为数据备份，一个从库作为数据分析以及运营支持；
- 根本上杜绝大事物，对于删除可以考虑分批删除数据；DDL可以采用开源的工具进行入：gh-ost方案
主备切换的几种策略
可靠性优先
该策略可能会有一段时间服务不可用，流程如下：
- 判断备库的seconds_behind_master的值，当相于一个值的时候进行第二步，否则一直重试；
- 主库设置readonly=true，即只读；
- 备库等待seconds_behind_master=0为止；
- 备库设置readonly=fase，即可写；
- 切换业务到备库；
注：第一步的作用实际上是希望主库和从库的延时在小于一个阈值时候开始做切换，否则如果相差30分钟，直接切换，那么服务就会有30分钟不可用，业务方一般是不可忍受的。（当然。。。。某些时候我也作为业务方我也就忍了）
可用性优先
和上面相比，保证业务的可用，但是会牺牲掉数据的一致性
- 备库设置readonly=fase，即可写；
- 切换业务到备库；
- 主库设置eadonly=true
注：在下面的情况会导致数据不一致，原因如下：（老的主库是A,备库是B）
- A插入了数据c(4)，还没有同步到B时候进行切换
- 这时候B变为主，B库插入数据c(5)，这条数据是（4，5）
- 然后B从A通过relylog重放数据是c(4)那条数据，这时候B库中(5，4)
- A库通过重放relylog获取刚才c(5)的数据，这时候数据是（5，5）
总结，Mysql作为数据的存储，还是应该优先保证数据的一致性，所以建议采用可靠性优先方案保证数据的一致性。否则，对于一些依赖写入的业务，可能因为在切换主备时候数据不一致引起逻辑的错误，而且由于往往写入不是一个单一的操作，这一次的不一致会导致后续的引发更多的问题，最终导致数据无法修复。
其他的好的建议：如果业务不依赖mysql的写入可以针对写入进行降级，比如：让数据先写到临时文件中，然后切换后慢慢的同步到mysql中。