2020-08-28

l 主节点 binary log dump 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。

在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，在发动给从节点之前，锁会被释放。

l 从节点I/O线程
当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。

I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。

l 从节点SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

 

对于每一个主从连接，都需要三个进程来完成。

当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。

主从复制过程

1. 主库记录二进制日志binary log dump ，每次准备提交事物完成数据库更新前，先记录二进制日志，记录二进制日志后，主库会告诉存储引擎可以提交事物了
2. 备库将主库的bin log 二进制日志复制到本地的relay log 中继日志中。（

   首先，备库启动一个工作进程，称为IO工作线程，负责和主库建立一个普通的客户端连接。

   从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容

   主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position。

   如果该进程追赶上了主库，他将进入睡眠状态，直到主库有新的事件产生通知它，将接收到的事件记录到relay log中。

   ）

3. 备库的SQL线程执行最后一步。该线程从relay log 中读取事件并且在备库中执行，当SQL线程赶上IO线程的时候，relay log 通常记录在系统缓存中，所以中继日志开销很低。从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”。SQL线程也可以根据配置选项来决定是否写入自己的二进制日志中。

GTID

• 日志：传统的方式，默认的方式。依赖二进制日志，根据日志的偏移量。事务不断提交，二进制日志的偏移量也会不断的变化。需要从库告诉主库，自己明确复制到了偏移量的什么位置。
• GTID: 全局事务ID，在一个集群内的一个GTID是唯一的， GTID= source_id:transcation_id，source_id为那一台机器上的，slave增量复制还未同步的GTID即可。

 

 

主从复制延迟

产生延迟原因？

• 主节点如果执行一个很大的事务(更新千万行语句，总之执行很长时间的事务)，那么就会对主从延迟产生较大的影响
• 网络延迟，日志较大，slave数量过多。
• 主上多线程写入，从节点只有单线程恢复

处理办法：

• 大事务：将大事务分为小事务，分批更新数据。
• 减少Slave的数量，不要超过5个，减少单次事务的大小。
• MySQL 5.7之后，可以使用多线程复制，使用MGR复制架构