MySql主从复制机制全面解析-巨人网络通讯

MySql主从复制机制全面解析

作为一个关系型数据库，MySQL内建地提供数据复制机制，这使得在使用时，可以基于其复制机制实现高可用架构等高级特性，从而使得MySQL无需借助额外的插件或其他工具就具备适用于生产环境。这是MySQL得到大面积实际应用的条件之一。

基于MySQL的复制机制，不仅可以实现数据库的高可用，还能实现如：性能扩展、异地灾备以及冷热分离等高级特性。

高可用：通过配置一定的复制机制，MySQL实现了跨主机的数据复制，从而获得一定的高可用能力，如果需要获得更高的可用性，只需要配置多个副本，或者进行级联复制就可以达到目的。
性能扩展：由于复制机制提供了多个数据备份，在读写一致性要求不高的场景下，可以通过配置一个或多个副本，将读请求分发至副本节点，从而获得整体上读写性能的提升。
异地灾备：只需要将副本节点部署到异地机房，就可以轻松获得一定的异地灾备能力。实际当中，需要考虑网络延迟等可能影响整体表现的因素。
交易分离：通过配置复制机制，并将低频、大运算量的交易发送至副本节点执行，就可以避免这些交易与高频交易竞争运算资源，从而避免整体的性能问题。

为了获得上述能力，需要了解基本的MySQL复制机制，并结合实际应用场景选择恰当的配置。

主从复制机制

MySQL基于binlog实现主从复制，从节点跟踪并获取主节点binlog中最新更新并在自身进行重放，从而实现复制主节点数据。

下图是MySQL主从复制过程的示意图。在整个过程中涉及三个线程，他们的职责分别是：

主节点binlog dump线程：该线程在从节点连接上主节点后创建，负责向从节点发送binlog中新写入的数据。在读取binlog时，dump线程会首先获取binlog的锁，并在读取完毕后立刻释放，然后将读取到的数据发送至从节点。
从节点I/O线程：从节点I/O线程职责为向主节点发送数据同步的请求，接收主节点发送的数据并将其写入relay-log。
从节点SQL线程：该线程从relay-log中读取数据更新并进行重放。

异步复制

默认情况下，MySQL的主从复制是异步复制，在这种机制下，主节点会在完成本地日志写入后立刻响应客户端的请求，从节点的数据复制过程异步执行。

很明显，在这种机制下面，由于复制过程并不会影响主节点对客户端请求的响应，因此，相比于单节点，并不会造成整体性能上的明显损失。

但是，在这种机制下面，如果数据在主节点完成提交而未同步至从节点时主节点宕机，此时如果发生主从切换并写入新的数据，可能导致数据丢失或不一致。

半同步复制（semisynchronous replication）

从5.6版本开始，MySQL支持半同步复制，这种机制与异步复制相比主要有如下区别：

主节点在收到客户端的请求后，必须在完成本节点日志写入的同时，还需要等待至少一个从节点完成数据同步的响应之后（或超时），才会响应请求。

从节点只有在写入relay-log并完成刷盘之后，才会向主节点响应。

当从节点响应超时时，主节点会将同步机制退化为异步复制。在至少一个从节点恢复，并完成数据追赶后，主节点会将同步机制恢复为半同步复制。

可以看出，相比于异步复制，半同步复制在一定程度上提高了数据的可用性，在未退化至异步复制时，如果主节点宕机，此时数据已复制至至少一台从节点。

同时，由于向客户端响应时需要从节点完成响应，相比于异步复制，此时多出了主从节点上网络交互的耗时以及从节点写文件并刷盘的耗时，因此整体上集群对于客户端的响应性能表现必然有所降低。