mysql主从切换自动切换(mysql两主一从的设置方法),本文通过数据整理汇集了mysql主从切换自动切换(mysql两主一从的设置方法)相关信息，下面一起看看。

MySQL数据库内置的复制功能是构建基于MySQL的大规模高性能应用的基础。复制就是让一个MySQL主库以日志的形式通过网络将数据传输给另一个或多个MySQL从库，然后在从库上重放日志，达到与主库数据同步的目的。

MySQL & # 039的复制模式分为异步复制、全同步复制和半同步复制。下面将详细分析不同复制模式下的数据一致性。

异步复制(异步复制)

主库在执行完客户端提交的事务后，会立即提交并返回，而不管从库是否收到了日志并进行处理。此时，如果主存储库上提交的事务由于某种原因没有传输到从存储库，并且主存储库宕机，此时从存储库被提升为主存储库，那么新的主存储库的数据将会丢失，导致主从数据不一致。这种复制模式一定存在这个问题。

主库将事务写入二进制日志文件，并通知转储线程发送这些新的二进制日志，然后主库将继续处理提交操作，因此不能保证这些二进制日志此时已成功传输到任何从库节点。

完全同步复制(完全同步复制)

主库执行一个事务，所有从库在返回客户端之前执行该事务。因为你要等所有的奴隶都回来，所以交易时间会拉长，性能必然会受到很大的影响。

同步是MySQL NDB集群上采用的所有复制方法。NDB是一个没有共享体系结构的分布式存储引擎。严格来说，NDB节点不是复制，而是2PC，保证了事务提交的强一致性。这个集群在国内用的很少，问题比较多，不推荐。复制会严重影响主库的事务提交性能，对网络要求非常严格，不适合同城或异地的架构场景。

半同步复制(半同步复制)

完全同步复制和异步复制之间的差异。主库需要等待至少一个从库节点接收日志事件，并刷新来自Binlog的ACK确认消息以中继日志文件，然后才能提交和返回。通常，主库不需要等待来自所有从库的ACK。注意：此ACK是为了确保日志被传输到从库并写入中继日志，而不是从库已经完成回放和数据写入。详情见图1。

图像

图1半同步复制模式

与异步复制相比，半同步复制提高了数据的安全性，但也带来了一定程度的延迟，至少是一个TCP/IP的往返时间。因此，半同步复制最适合用于低延迟网络。

一般在实际生产中，我们将同城或机房(2ms以内)的网络延迟设置为半同步，对于10ms以上的异地延迟采用异步复制。

一般情况下，将rpl _ semi _ sync _ master _ wait _ for _ slave _ count设置为1，可以在数据一致的情况下，最大程度地保证主库的事务性能。

MySQL官方称这种复制模式为无损复制，从复制机制来看，确实保证了数据不会丢失。但这是真的吗？让& # 039；让我们从半同步的两种复制形式来分析它。

1.普通半同步AFTER_COMMIT。处理流程如下所示(参见图2)。首先，理解第三步引擎层提交的意义。第三步完成后，因为主库还没有& # 039；t收到从库返回的确认信息，当前会话可以& # 039；t完成并返回给客户机，但是主库中的其他会话已经可以看到执行结果。按照事务隔离级别，相当于主库的脏读。

图像

图2一般半同步处理流程

比如你转账100元给小王，第三步完成后，小王会发现他的余额多了100元。但是，如果此时出现异常：主库关闭，日志没有发送到从库，则会出现

此时会出现两种不一致：(1)数据层不一致。主数据库宕机重启后，仍有之前转账100元的记录。因为从数据库没有收到日志，这部分数据提升到主数据库后就不能再同步了，所以原主数据库重启后数据库会跳过ACK验证，引擎层重新提交事务，会比新的主数据库多一条记录。(2)应用层不一致。前后看到的结果不一致。

最致命的是应用层不一致，数据层不一致。我们可以通过数据补偿或者应用重做来解决，但是应用层不一致是逻辑错误，这是不能容忍的！

2.增强半同步AFTER_SYNC。从MySQL版本5.7开始，支持增强的半同步，并将其设置为默认值。处理流程如下所示(参见图3)。

图像

图3增强的半同步处理流程

增强型半同步是接收库返回的ACK信息，然后提交给引擎层，解决了普通半同步的脏读和应用层不一致的问题。

比如你转账100元给小王，第五步完成后，小王会发现他的余额多了100元。但如果此时出现异常：主库宕机，发生主从切换，从库提升为主库。由于前次转账100元的信息已经发送到了从行，小仍然核对着前次转账的100元！

如果在步骤5之前发生异常，则其他会话无法查看最新记录，因为主库引擎层尚未提交该记录。

综上所述，不会出现之前应用层数据不一致的问题，前后结果是一样的。可见，增强半同步才是真正的无损复制，更有效地保证了数据的一致性，具体来说就是避免了应用层的不一致。

那么，增强半同步能否保证数据层和应用层的数据一致性呢？答案是否定的，下面会详细分析。

(1)在第一种情况下，日志丢失，主从切换。如果主库日志没有同步到从库或者从从库接收后没有写入中继日志，此时发生主从切换，从库应用日志会丢失，导致数据不一致。所以主从数据不一致有两种情况：主数据库日志不同步到从数据库；主从切换同时发生。

例如，应用程序客户机向主库发起插入请求，然后开始提交。如果此时网络中断，日志没有发送到从库，则无法接受从库的ACK信息，因此无法进行提交，处于挂起状态。此时如果主库宕机，同时发生主从切换，应用客户端会报错，记录没有插入成功，新的主库也没有这个记录。当应用客户端连接到新的主库后重新发起请求时，可以再次插入这条记录，应用逻辑没有被破坏，数据是一致的。

但是，数据层中会有不一致的地方。当最初的主库再次启动时，ACK验证将被跳过，PendingBinlog将在引擎级别提交。所以启动后这个记录会存在于原来的主库中，而不存在于新的主库中，造成数据层的不一致。

当应用程序连接新的主库以再次执行该记录时，新的主库会将该记录发送到原始主库，这会给出错误(如果是主键)或重复数据。

解决方法：首先，重新初始化原始master数据库数据，然后与新的master数据库建立复制关系。第二，手工处理，逆向解析原主数据库日志，删除冗余数据；新的主库跳过不需要同步的原始主库的GTID事务号；新的主库等于原来的主库GTID。第三，自动处理。现在，一些成熟的管理平台已经具备了自动处理冗余数据的功能

解决方法：首先让应用程序确认记录已经正常插入，无需重复执行；其次，数据库删除记录，应用程序重新执行。

主库等待ACK返回的默认时间是60s，之后会降级为异步并提交事务。有时，从属库没有对网络问题做出响应。为了保证主库的可用性，我们会牺牲一些一致性需求，这是符合生产场景的。在一致性要求高的环境中，ACK返回时间会设置为无穷大，这样可以保证一致性，但会影响一些可用性。

(3)第三种情况，一个主有很多从，日志丢失。在极端情况下，即使使用增强的半同步，数据层和应用层之间也会出现数据不一致的情况，如图4所示。

图像

图4一主多从的数据不一致

在一主多从的情况下，响应从的数量设置为1，同城数据中心A的从首先接收日志，并向主返回ACK，主才能正常提交。如果数据中心A的主库和从库都宕机，此时日志还没有发送到数据中心B和其他数据中心的从库，发生主从切换，那么这两个数据中心的从库的数据在数据层和应用层都会和原来的主库不一致。

解决方案：一、增加同一城市数据中心的A从机数量(尽量放在不同的机房单元或区域)，增加响应从机数量。这样会增加一些成本，也不能解决数据中心整体故障导致的数据不一致问题。二是增加响应从机数量。比如在一主三从的模式下，响应从的数量设置为2，可以保证同城B中心的一个从在提交前返回ACK，从而保证同城B中心的数据一致性。但是，当同一城市的数据中心之间的网络不稳定时，系统性能会受到很大影响。对于要求RPO严格为零，两个中心之间的网络安全可靠的关键系统，可以采用这种方法，而对于其他系统则没有必要。三是将同城双中心扩大为同城三中心或多中心，增加响应奴隶数量。这是最好的办法，但是成本太高，有这个条件的数据中心可以采用。

总结

如何最大程度避免数据不一致？总结如下：第一，采用更高版本的MySQL数据库产品，至少5.7版本及以上，并启用增强半同步。二是回滚PendingBinlog，采用双1参数，以行格式打开GTID。第三，使用第三方插件如MHA和keepalived来设置主库切换策略。当有停机时间时，你不会& # 039；t立即切换，N次后再尝试重启。另外，从库升级到主库后，你尝试从原来的主库获取日志来弥补(系统正常，MySQL数据库可以& # 039；不要启动)。四是建立自动切换工具，启用数据检查和补全机制。第五，有条件的话，增加数据中心和从库的数量，增加响应从库的数量。

最后，附上一个我行信息系统的实际案例(见图5)，以飨读者& # 039；参考。数据库版本为MySQL 5.7，主要采取以下措施：一是采用一主三从的模式，两个数据中心在同一个城市，其中一个主库和一个从库位于同一个城市的机房A，另外两个从库位于同一个城市的机房B。第二，采用增强型半同步。因为系统的RPO接近但不为零，所以响应从设备的数量被设置为1。第三是完整的切换策略。主库在切换前尝试启动n次(n分钟)，根据用户自定义权重和最新GTID选择主库。第四，数据检查和补充机制的功能。切换后，备用主库将尝试从原始主库获取最新的Binlog日志并应用它。

图像

更多mysql主从切换自动切换(mysql两主一从的设置方法)相关信息请关注本站。