MySQL复制中使用的线程

MySQL的主从复制是一项重要功能，可以利用其实现读写分离、高可用，及备份等目的。众所周知，MySQL是一个单进程、多线程的数据库，在各项工作中调用了不同的线程，本篇将介绍在主从复制中所使用的线程。

主从复制的工作原理

1. 主库的更新事件（update、insert、delete）被写入二进制日志（binlog）。
2. 从库发起连接，连接到主库。
3. 主库创建一个“binlog dump” 线程，将二进制日志的内容发送到从库。
4. 从库启动后，创建一个I/O线程，读取主库传过来的二进制日志内容，并写入到中继日志（relay log）。
5. 从库还会创建一个SQL线程，从中继日志读取内容，从“Exec_Master_Log_Pos”位置开始执行读取到的更新事件，将更新内容写入到从库。

注意：SQL线程写入从库时，采取单线程模式，或多线程模式。多线程模式下，需要将中继日志分发到多个工作线程。

Binlog Dump线程

“binlog dump” 是一个主服务器线程，用于将主库的二进制日志传输到从库。在 MySQL 主从复制过程中，主服务器会为每一个连接成功的从服务器创建一个“binlog dump”线程。从服务器也会为每一个连接成功的主服务器创建自己的I/O线程和SQL线程，以实现主从之间的数据同步。下面是其详细工作过程：

1. 二进制日志文件加锁。
2. 读取更新的操作。
3. 读取完毕后将锁释放。
4. 将读取的记录发送给从服务器。

单线程从服务器

从服务器默认使用单线程处理中继日志，其优点是在一个数据库内的数据可以通过单线程保证其一致性。由于使用单线程，从服务器上可能会产生延迟，数据同步落后于主服务器。产生的原因是由于当多个客户端连接主服务器进行数据更新时，主服务器并行处理这些更新，但会将其在二进制日志中进行序列化，从服务器采用单线程处理这些更新时按序处理，极容易造成瓶颈。

多线程从服务器

使用多线程的从服务器可以减少从库延迟。开启多线程的方法为将变量“replica_parallel_workers”设置为0以外的值，该值即为并行的工作线程数量。当开启多线程从服务器时，从服务器的SQL线程不再直接应用中继日志中的更新事件，而是由工作线程替代其进行应用。

通过配置变量“replica_parallel_type”的值，指定并行处理的策略。

• DATABASE：不同数据库执行的事务可以并行更新。
• LOGICAL_CLOCK：事务是基于主服务器写入二进制日志的时间戳在从服务器上并行应用。事务之间的依赖关系基于对它们的时间戳进行跟踪，在可能的情况下提供并行化。

控制从服务器的线程

启动或停止I/O和SQL线程

START REPLICA；
STOP REPLICA；

单独控制线程

START REPLICA IO_THREAD;
STOP REPLICA SQL_THREAD;

满足条件启动线程

START REPLICA UNTIL SQL_AFTER_MET_GAPS；
START REPLICA SQL_THREAD UNTIL SQL_BEFORE_GTIDS = '3E11FA47-71CA-11E1-9E33-C80AA9429562:23';

断开主从连接

RESET REPLICA;

重置从服务器

用户可以通过“RESET REPLICA”命令重置从服务器的连接，该命令可以清除复制元数据存储库，删除所有中继日志文件，并启动一个新的中继日志文件。对于正在使用GTID的服务器，该命令对GTID执行历史没有影响，不会改变“gtid_executed”或“gtid_purged”的值，也不会改变mysql. gtid_executed表。

以上内容是关于主从复制中线程的介绍，感谢关注“MySQL解决方案工程师”！