Mysql在切换主从的时候，保业务还是保数据？

目的

备库作为主，主库作为备

问题

数据库不是静态的，切换的时候从库还有没应用完的中继日志，这里是保业务还是保数据？
切换的时候，主库还在不断的写入数据，从库还没有追上主库。

策略
策略一：可靠性优先策略
假设两个库都是正常运行，没有出现掉线，A主B备，B复制A，B库肯定有seconds_behind_master，这里是表示B落后A多少，小的时候是几秒钟，大的时候是几分钟甚至几十分钟上小时，所以在切换之前检查B检查A是否太多，假如太多那么不能切换！为什么不能？比如B落后A5秒内，这个时候切换比较合适，比如B落后A三秒，也就是B还有3秒的中继日志没重放，这个时候A开启只读 readonly=true，那么A库只读，B库也一般只读，AB都是只读，整个系统是只可读不可写，那么只能查询影响业务，那么A就不再产生Binlog了，B那么就不再接收新的中继日志了，那么B落后A越来越少，B直接网上追，那么几秒钟之后就追上A了，那么AB一致，这时候检查一下B库是否追上，B的seconds_behind_master=0，这个时候B库关闭只读readonly=false，B停止复制A库，A开始复制B。
优势：保障中间数据不会丢失，比如从写A开始，A又不让写，代表客户端写不进A来，客户端就会等着，数据不会丢。问题是有几秒两个库都不可写，只能读，所以影响业务。也就是数据可靠，业务不可控。
如果B落后A一分钟，一分钟不可写，那么很大程度影响业务。假如B一直落后A十分钟，那么这种可以考虑开启并行复制策略，让B抓紧追，等B追上来再切换。

策略二：可用性优先策略
取消等待数据一致的过程，取消B等待A。直接A开只读，B关只读，强行A复制B，B库停止复制A。
优点：系统没有不可写的时间。
缺点：有数据不可靠性，因为B落后A，B还有没有应用的中继日志，造成数据不一致的错误。比如客户端刚在A插入一条数据，这时候切换了主从，B还没来得及应用A的日志，这时候B就要改这条数据，但B没有这条数据，因为B还没来得及跑中继日志，还没追上，这时候改一个不存在的数据会造成数据不一致。
但是这种策略适合一直往里写数据，不会改，而且没有复杂业务处理造成数据不一致。

如果事务比较多的业务场景，尽量使用第一种可靠性优先策略