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

此时就会出现两种不一致：（1）数据层不一致。主库宕机重启后，依然有之前转账 100 元的记录，由于从库未接收到日志，且提升为主库后无法再同步这部分数据，而原主库重启后数据库会跳过 ACK验证，引擎层会将事务再次提交，就会比新主库多一条记录。（2）应用层不一致。前后看到的结果不一致。
最致命的是应用层不一致，数据层不一致我们可以通过数据补偿或应用重做的方法解决，但应用层不一致就是逻辑错误，是不能容忍的！
2. 增强半同步 AFTER_SYNC 。MySQL 从 5.7 版本开始支持增强半同步并设为默认值，处理流程如下（见图 3）。
image
图3 增强半同步处理流程
增强半同步是接收从库返回 ACK 信息后再做引擎层提交，解决了普通半同步的脏读、应用层不一致的问题。
例如：你给小王转账 100 元，在步骤五完成后，小王会查询到自己的余额多了 100 元。但如果此时发生异常：主库宕机，并且发生了主从切换，从库提升为主库。由于之前的转账 100 元信息已经发送到从库，那么小王依然可以查看到之前转账的 100 元！
如果在步骤五之前发生异常，由于主库引擎层未提交，那么其他会话也是无法查看到最新的记录。
综上，就不会出现之前的应用层数据不一致问题，前后看到的结果是一样的。由此可见，增强半同步才是真正的无损复制，更有效地保证了数据的一致性，确切地说是避免了应用层的不一致。
那么，增强半同步是不是一定就可以保证数据层和应用层的数据一致性呢？答案是否定的，下面将具体分析。
（1）第一种情况，日志丢失，主从切换。如果出现主库日志未同步到从库或从库接收后未写入 Relay Log，且此时发生主从切换就会导致从库应用日志丢失，出现数据不一致的情况。所以出现主从数据不一致要具备 2 个条件：主库日志未同步到从库；同时发生主从切换。
例如：应用客户端向主库发起一条插入请求，然后开始提交，如果此时网络中断，日志未发送到从库，也就无法接受从库的 ACK 信息，于是提交无法进行，处于 hang 状态。这时如果主库宕机，且同时发生主从切换，那么应用客户端会出现报错，记录未插入成功，新主库同样也没有这条记录。当应用客户端连接新主库后重新发起请求，可再次插入这条记录，应用逻辑没有被破坏，数据是一致的。
但此时会出现数据层的不一致。当原主库再次启动后，会跳过 ACK 验证，对PendingBinlog 进行引擎层面的提交，所以启动后原主库就会存在这条记录，而新主库并没有，从而造成数据层的不一致。
当应用连接新主库再次执行这条记录时，新主库会把这条记录发送给原主库，就会报错（如果是主键）或出现重复数据。
解决方法：一是重新初始化原主库数据，然后再建立和新主库的复制关系。二是手工处理，反向解析原主库日志，删除多余的数据；新主库跳过不需要同步的原主库 GTID 事务号；新主库追平原主库GTID 。三是自动处理，现在有些成熟的管理平台已经具备了自动处理多余数据并追平 GTID 的功能，操作方法和手工处理的思路是一样的。
（2）第二种情况，日志未丢失，主从未切换。主库因为无法接收到从库的ACK 信息而无法提交并返回，此时主库宕机，如果主库重启动后未切换，主库可以正常启动，那么这条记录同样会被提交。而应用层的反应是异常，该条记录并未成功，那么会出现应用层的不一致。
解决方法：一是让应用确认该记录已经正常插入，无需重复执行；二是数据库删除该记录，应用重新执行。

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

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