mysql切换主从方法和如何使用 mysql主从切换步骤( 三 )

主库等待 ACK 返回的默认时间是60s，超过 60s 会降级成异步并提交事务。有时因为网络问题从库一直没有响应，为了确保主库可用性，我们会牺牲部分一致性要求，这是符合生产场景的。对一致性要求极高的环境，会将 ACK 返回时间设置为无穷大，这样虽然保证了一致性，但是会影响部分可用性。
（3）第三种情况，一主多从，日志丢失。有一种极端情况，即使是增强半同步，也会出现数据层和应用层的数据不一致，见图 4 。
image
图4 一主多从出现数据不一致的情况
在一主多从的情况下，将应答从库数量设置为 1，同城数据中心 A 的从库首先接收到日志并返回 ACK 给主库，主库就可以正常提交。如果数据中心 A 的主库和从库均发生宕机，而这此时日志尚未发送给数据库中心 B、异地数据中心的从库，并且发生了主从切换，那么这两个数据中心从库就会在数据层和应用层均出现和原主库数据不一致的现象。
解决方法：一是增加同城数据中心A 从库数量（尽量放置在不同机房单元或区域），并增加应答从库数量。这样会增加一些成本，而且不能解决数据中心整体故障导致的数据不一致问题。二是增加应答从库数量。比如一主三从的模式下，将应答从库数量设为 2，这样能确保同城 B中心的一个从库返回 ACK 后才提交，保证了同城 B 中心的数据一致性。但在同城数据中心间网络不稳定的情况下，对系统性能会有较大影响。对于要求 RPO 严格为零的关键系统，且两中心间网络安全可靠的前提下，可以采取这种方法，其他系统不必要采用。三是将同城双中心扩展为同城三中心或多中心，同时增加应答从库数量。这是最佳方式，但成本过高，具备此条件的数据中心可以采用。
总结
究竟该如何最大程度地避免数据不一致的发生呢？总结如下：一是采用较高版本的 MySQL 数据库产品，至少在 5.7及以上版本，启用增强半同步。二是回退掉 PendingBinlog，采用双 1 参数，ROW格式，开启 GTID 。三是使用第三方插件如 MHA、keepalived 设置主库切换策略，发生宕机后不马上切换，尝试 N 次重启后再切换，另外从库提升为主库后，尝试从原主库拉取日志补齐（系统正常，MySQL 数据库无法启动的情况）。四是建立自动切换工具，启用数据校验和补齐机制。五是条件允许的情况下，增加数据中心数量、从库数量，增加应答从库数量。
最后，附上我行某信息系统的一个实际案例（见图 5），供读者参考。数据库版本为MySQL 5.7，主要采用了以下措施：一是采用了一主三从模式，同城双数据中心，其中一个主库和一个从库在同城 A机房，另两个从库在同城 B 机房。二是采用了增强半同步，由于系统 RPO 接近但可不为零，故应答从库数量设置为 1 。三是完备的切换策略，主库尝试 N 次（N分钟）启动后再切换，基于自定义权重和最新 GTID 进行选主。四是数据校验和补齐机制功能，切换后，备选主库校验发现还有未同步的 Binlog，会尝试从原主库获取最新的 Binlog 日志并应用。
image

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：