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

文章插图
MySQL 数据库内建的复制功能是构建基于 MySQL 的大规模、高性能应用的基础。复制就是让一个 MySQL主库 (Master) 将数据通过日志的方式经网络传送到另一台或多台 MySQL 从库(Slave)，然后在从库上重放该日志，以达到和主库数据同步的目的。
MySQL 的复制模式分为异步复制、全同步复制及半同步复制三种。下面将针对不同复制模式下的数据一致性问题进行详细分析。
异步复制（Asynchronous replication）
主库在执行完客户端提交的事务后会立即提交并返回，不关心从库是否已经接收到日志并处理。如果此时主库上已经提交的事务因为某些原因未传送到从库，同时主库发生宕机，且在此时从库提升为主库，就会导致新主库数据缺失，从而造成主从数据不一致的情况发生。该复制模式下必然存在此问题。
主库将事务写入到 Binlog 文件中，并通知 dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，所以此时无法保证这些 Binlog 已经成功传到任何一个从库节点上。
全同步复制（Fully synchronous replication）
主库执行完一个事务，且所有从库都执行了该事务才返回给客户端。因为需要等待所有从库才能返回，所以事务的时间会被拉长，从而性能必然会受到较大影响。
全同步是在 MySQL NDB Cluster 上采用的复制方式。NDB 是分布式存储引擎，无共享架构，严格来说 NDB 节点不是复制，而是 2PC，确保事务提交的强一致。该集群在国内使用极少，且存在较多问题，不建议采用。全复制会严重影响主库的事务提交性能，对网络要求非常严格，不适合同城、异地的架构场景。
半同步复制（Semisynchronous replication）
介于全同步复制与异步复制之间。主库需要等待至少一个从库节点收到日志事件，并刷新 Binlog 到 Relay Log 文件中的 ACK 确认消息后，才能提交并返回，主库一般不需要等待所有从库的 ACK 。注意：该 ACK 是确保日志传送到从库并写入到中继日志，而不是从库已经完成重放、将数据写入完成。详见图 1 。
image
图1 半同步复制模式
相对于异步复制，半同步复制提高了数据的安全性，同时也带来了一定程度的延迟，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。
一般在实际生产中，我们把同城或同机房，网络延迟小的（2ms 内）设置为半同步，对于异地延迟在 10ms 以上的，采用异步复制的方式。
一般将 rpl_semi_sync_master_wait_for_slave_count 设置为1，在数据一致性的情况下，可以最大程度保证主库事务处理的性能。
MySQL 官方称该复制模式为无损复制，从复制机制上看，的确会保证数据不丢失。但真实情况是这样吗？下面我们从半同步的两种复制形式进行分析。
1. 普通半同步 AFTER_COMMIT 。处理流程如下（见图 2）。首先要理解第三步引擎层提交的含义。第三步完成后，由于主库还未收到从库返回的确认信息，当前会话一直无法完成并返回给客户端，但主库的其他会话已经可以看到执行的结果了。如果按照事务隔离级别来理解，就相当于对主库的读取出现了脏读。
image
图2 普通半同步处理流程
例如：你给小王转账 100 元，在步骤三完成后，小王会查询到自己的余额多了 100 元。但如果此时发生异常：主库宕机，日志尚未发送到从库，且发生了主从切换，从库提升为主库。那么因为之前的转账 100 元日志未发送到从库，小王再次查询余额的时候，会发现之前已“到账”的 100 元又不见了！

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

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