今天就跟大家聊聊有关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并完成刷盘之后，才会向主节点响应。

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

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

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

主从复制格式

由于MySQL的复制机制是基于binlog的，因此binlog的格式就决定了主从复制的格式。binlog有基于行的和基于语句两种，从而复制也有两种对应的格式。

Statement-Based Replication(SBR)

对于基于语句的复制机制，binlog仅记录所执行的语句。这种方式，有如下优点：

• 自从3.23版本就存在，经过长期验证的成熟技术

• 写入日志文件的数据更少，这意味着更少的文件写入和网络传输消耗，从而整体上可以更快的完成主从复制，提升性能表现。

• 日志文件记录了所有数据库上执行的语句，可以用来进行审计等用途
  

有如下缺点：

• 用户自定义函数(UDF)以及执行结果不确定的函数无法进行复制

• 进行数据更新时，需要比基于行的复制更多的行锁

• 对于如先插入后更新式的复杂语句，从节点需要进行完全的对应重放，而基于行格式的复制只需要执行最终结果即可
  

Row-Based Replication(RBR)

基于行的复制机制下，对应binlog也是基于行的，这时每次数据更新当写入binlog时，都被转化所有受影响行的变化。

这种复制方式，有如下优点：

• 所有数据变化都可以被安全的复制，不会受到UDF以及特殊函数的影响。

• 大部分DBMS都采用这种复制方式，知识迁移成本低。

• 进行数据更新时，所需要的行锁更少，从而可以获取更高的性能表现。
  

有如下缺点：

• 在涉及大数据量的DML时，基于行的日志将会产生大量的日志数据，大数据量在日志文件写入、网络传输方面都意味着更长的时间，从而可能导致整体性能表现显著变差，同时也可能导致并发问题。

• 无法通过日志查看所执行的语句，同时也无法获知从节点上执行的语句。
  

看完上述内容，你们对MySql中主从复制机制的原理是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注天达云行业资讯频道，感谢大家的支持。