mysql主从复制原理,异步怎么回事?半同步怎么回事

发布网友 发布时间：2022-04-23 16:59

我来回答

共3个回答

懂视网 时间：2022-04-29 19:57

相关免费学习推荐：mysql视频教程

mysql主从复制原理：

为什么要做主从复制

MySQL主从复制的流程

主库db的更新事件(update、insert、delete)被写到binlog

主库创建一个binlog dump thread，把binlog的内容发送到从库

从库启动并发起连接，连接到主库

从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log

从库启动之后，创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

注：上述流程为相对流程，并非绝对流程

MySQL主从复制的原理

MySQL主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。

binlog：binary log，主库中保存所有更新事件日志的二进制文件。binlog是数据库服务启动的一刻起，保存数据库所有变更记录（数据库结构和内容）的文件。在主库中，只要有更新事件出现，就会被依次地写入到binlog中，之后会推送到从库中作为从库进行复制的数据源。

binlog输出线程：每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。 对于每一个即将发送给从库的sql事件，binlog输出线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。

在从库中，当复制开始时，从库就会创建从库I/O线程和从库的SQL线程进行复制处理。

从库I/O线程：当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。 从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。

从库的SQL线程：从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。

综上所述，可知：

对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。

从库通过创建两个的线程，使得在进行复制时，从库的读和写进行了分离。因此，即使负责执行的线程运行较慢，负责读取更新语句的线程并不会因此变得缓慢。比如说，如果从库有一段时间没运行了，当它在此启动的时候，尽管它的SQL线程执行比较慢，它的I/O线程可以快速地从主库里读取所有的binlog内容。这样一来，即使从库在SQL线程执行完所有读取到的语句前停止运行了，I/O线程也至少完全读取了所有的内容，并将其安全地备份在从库本地的relay log，随时准备在从库下一次启动的时候执行语句。

热心网友 时间：2022-04-29 17:05

研发的同事反馈，mysql的半同步怎么变异步了？开始觉得不足为奇，超时之后，自然变成异步了。但同步binlog的速度变得正常之后，就会自动变成同步了。但抱着严谨负责的态度，马上去检查了一

下数据库的日志跟半同步的状态。

       看了一下从库的错误日志，被图片中所示的sem-sync slave net_flush() reply failed 刷屏。。。。。。，汗了，这又是哪一出？  主库却没有任何日志。

虽然此时的主从同步的延迟时间是正常的，维持在0s的延迟，但此时同步状态却是异步的。

      好奇怪呢？

     查看一下代码，该Semi-sync slave net_flush() reply failed 信息来自函数

ReplSemiSyncSlave::slaveReply，函数如下

        该错误发生的条件就是执行net_flush(net)函数，没有收到正常的返回，报错了，所以有上面的错误发生，该函数的作用是将从库收到的binlog file 跟binlog pos的信息发送给主库。

       网络有问题？ 即使网路抖动性的问题，网路恢复之后应该正常才是。

       为什么这个错误持续刷屏？ 而主从同步目前是正常的，只是由半同步变成了异步。

       当我将slave重启之后，错误信息也很快就出现。

       因为该函数是向主库发送同步binlog的确认信息的，也就是ack信息，难道是主库的ack的接收线程出了问题？ 而主库没有任何的报错信息 。

       关键时刻，自己搞不定的时候，尝试找帮手。我将错误信息，发给oracle公司的mysql开发者宋老师，宋老师是负责replication模块的开发者，对replication相当熟悉，说我可能遇上一个mysql的Bug，让我查看一下Bug 79865 .   在此，非常感谢宋老师的热情的无偿援助。

     bug 详情链接： http://bugs.mysql.com/bug.php?id=79865

     我们来看看采用了select()多路复用io模型的ack_reciver 线程的代码：

  bug的关键点是因为 ret= select(max_fd+1, &fds, NULL, NULL, &tv);  select()函数的入参max_fd+1有1024的*，且这个*无法通过修改nproc来突破？

（ulimit -n 命令可以修改nproc参数）。

  貌似所有的疑问都揭开，但请继续。

   作者采用的环境是5.7.15,同时，作者采用的操作系统是centOS 7,  根据上面http://bugs.mysql.com/bug.php?id=79865 后半部分，Meiji Kimura 的描述信息，该bug在centos 6上复现了, 而在centOS7上没有复现。而作者正是采用了centos 7.

热心网友 时间：2022-04-29 18:23

mysql主从复制原理是基于mysql的binlog日志管理模式。针对数据库的操作都会写入binlog日志文件，所以备数据库可以一直监控主数据库的binlog日志，并将该日志中的内容同步在备数据库执行。通过这样的方式就保证了主备数据库的一致性。