mysql主从复制原理详解_详解Mysql主从复制三种复制方式的联系与区别

概述

今天主要介绍一下Mysql主从复制的三种复制方式，后面再进一步说一下MGR。。

参考：

https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html

https://dev.mysql.com/doc/refman/5.7/en/group-replication-summary.html

https://dev.mysql.com/doc/refman/5.7/en/group-replication-examples-of-use-case-scenarios.html

---

1、传统的数据主从复制

1.1、主从复制(异步复制)

MySQL主从异步复制是最常见的复制场景。数据的完整性依赖于主库BINLOG的不丢失，只要主库的BINLOG不丢失，那么就算主库宕机了，我们还可以通过BINLOG把丢失的部分数据通过手工同步到从库上去。

传统的MySQL复制采用主从的方式进行，可以一主一从也可以一主多从，主库执行一个事务，提交后稍后异步的传送到从库中，如果是基于语句的复制则会重新执行，如果是基于行的负责则会应用日志，同时是shared-nothing的架构，即所有服务器拥有同样的数据复制

传统的数据主从复制均属于异步复制，从库起IO线程连接主库，获取主库二进制日志写到本地中继日志，并更新master-info文件(存放主库相关信息)，从库再利用SQL线程执行中继日志。

补充：为了保证Binlog的安全，MySQL引入sync_binlog参数来控制BINLOG刷新到磁盘的频率。

• 在默认情况下，sync_binlog=1，表示事务提交之前，MySQL都需要先把BINLOG刷新到磁盘，这样的话，即使出现数据库主机操作系统崩溃或者主机突然掉电的情况，系统最多损失prepared状态的事务；设置sync_binlog=1，尽可能保证数据安全。
• sync_binlog=0,表示MySQL不控制binlog的刷新，由文件系统自己控制文件缓存的刷新。
• sync_binlog=N,如果N不等于0或者1，刷新方式同sync_binlog=1类似，只不过此时会延长刷新频率至N次binlog提交组之后。

1.2、半同步复制

MySQL也提供了一个半同步复制，即同步复制，其要求主库在commit时等待从库接受完事务并返回确认信息后才能提交。半同步复制是建立在基本的主从复制基础上，利用插件完成半同步复制，传统的主从复制，不管从库是否正确获取到二进制日志，主库不断更新，半同步复制则当确认了从库把二进制日志写入中继日志才会允许提交，如果从库迟迟不返回ack,主库会自动将半同步复制状态取消，进入最基本的主从复制模式。

半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的BINLOG日志上，另一份在至少一个从库的中继日志Relay Log上，从而更进一步保证了数据的完整性。

半同步复制模式下，假如在传送BINLOG日志到从库时，从库宕机或者网络延迟，导致BINLOG并没有即使地传送到从库上，此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定)，如果BINLOG在这段时间内都无法成功发送到从库上，则MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端。

半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT越小决定了从库的实时性越好。通俗地说，主从库之间的网络越快，从库约实时。

---

2、组复制

组复制是一种可以用来部署容错系统的技术，复制组中的服务器通过massage passing来进行交互，通信层通过atomic message 和 total order message delivery来保证组内成员数据的一致性，所有的读-写(RW)操作需要组内所有成员都通过才可提交，只读(RO)事务不需要这个过程

组复制中的复制组是一个通过消息传递相互交互的server集群。复制组由多个server成员组成，如上图的master1，master2，master3，所有成员独立完成各自的事务。当客户端先发起一个更新事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去，复制到其他成员。如果冲突检测成功，组内决定该事务可以提交，其他成员可以应用，否则就回滚。最终，这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改，保证组内数据强一致性。

2.1、组复制的过程

当事务在原始服务器上要求提交后，服务器会自动广播写值(row changed)以及相应的写集( unique identifiers of the rows)，然后一个全局的总的顺序(global total order )为该事务建立了,这意味着所有的服务器按照顺序接受到了该事务，然后所有服务器按照相同的顺序应用该事务。

MGR提供一种叫做certification的步骤来解决冲突的问题，当不同服务器同时更新一行，此时则会发生冲突，这时MGR会承认第一个提交的事务，剩下的会被回滚，这也叫做distributed first commit wins 规则

2.2、新成员加入组的简单流程

1)当有新的成员加入组中，组内原有的成员会在二进制日志中插入一个视图切换的事件。

2)在组成员内找到一个donor捐赠之前缺失的数据，如果这个donor突然下线了，新成员会从新的donor获取缺失的数据，这时候组还在不断更新，新成员会将新的事件写到内存的一个临时空间

3)当获取到视图切换事件的时候，新成员将开始执行保存到内存临时空间的事件

2.3、组复制模式

组复制可以在两种模式下运行。

1)在单主模式下，组复制具有自动选主功能，每次只有一个 server成员接受更新。

2)在多主模式下,所有的 server 成员都可以同时接受更新.

2.4、组复制使用场景

MGR可以让你在组内不是全部或者大多数服务器失效时都可以保证数据库服务的可用，MGR利用一个依赖分布式失败检测器(distributed failure detector)的组成员关系服务(group membership service)来跟踪组内成员的离开(资源的离开或者是意外的离开)

MGR有个分布式恢复程序(distributed recovery procedure)来确保每当有服务器加入组后数据库保持最新，从而使得我们不需要做fail-over，多主架构还可以保证主库宕机时不会阻塞更新，MGR保证数据库服务持续可用。

最后需要理解的是虽然MGR可以保证数据库服务器的可用性，但是客户端的连接还是需要重新定向到另外的服务器的。想要达到这个目的，可以考虑MySQL Router。

如下为一些可能需要MGR的场景

• Elastic Replication - 一个非常流式复制的架构，服务器需要尽可能没有影响的动态的增长和减少，典型的如云上数据库服务
• Highly Available Shards - 分片是一个写扩展的功能实现，使用MGR来讲每个分片映射到不同的复制组中
• Alternative to Master-Slave replication -MGR可以作为传统主从切换的一个升级以获得更好的可用性
• Autonomic Systems - 最后你可以全新部署MGR来实现复制自动管理

---

后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下~