一张图让你牢记MySQL主从复制原理｜原创

为什么需要主从复制？

1、读写分离，增强MySQL数据库的可用性。

2、做数据的热备。

3、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

什么是mysql的主从复制？

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

主从复制搭建

主从复制的搭建我已经写过了，详细可以看这篇文章：

快速入门Mycat及主从搭建指南

MySQL 主从复制原理

在多个源的复制中，每一个复制源都会打开一个复制通道，这是一个长链接。并且每个复制源都有自己的 IO线程、一个或者多个点 SQL 线程以及 realy log。复制源接收到事务时会将其添加到relay log 中，然后通过SQL thread执行。相关官方文档如下：

In MySQL multi-source replication, a replica opens multiple replication channels, one for each replication source server. The replication channels represent the path of transactions flowing from a source to the replica. Each replication channel has its own receiver (I/O) thread, one or more applier (SQL) threads, and relay log. When transactions from a source are received by a channel's receiver thread, they are added to the channel's relay log file and passed through to the channel's applier threads. This enables each channel to function independently.

主从复制应该是分为第一次建立连接和增量数据同步过程。

第一次建立连接

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个io_thread线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

1.在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。

CHANGE MASTER TO MASTER_HOST='192.168.56.104',MASTER_USER='root',MASTER_PASSWORD='qwer_123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;

2.在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。

3.主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给备库 B。

4.备库 B 拿到 binlog 后，写到relay log（中继日志）中。

5.备库的 sql_thread 读取 relay log，解析出日志里的命令，并且回放执行。

增量同步详细流程

详细过程如下：

1.客户端发起 update 请求，MySQL server 端收到请求。

2.生成被修改数据行对应的 unodo log。

3.执行update成功写入内存。

4.InnboDB 生成 redo log ，此时处于 prepare阶段。

5.server 层生成binlog，事务提交时binlog做持久化，此时binlog便可以开始被同步到从库了。

6.redo log 做磁盘持久化，同时向客户端返回update的执行新结果（默认异步复制，以后会讲）。

7.主库发送生成的 binlog 数据。

8.从库的io_thread处理Maste传输过来的数据，保存为relay log。从库服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件

9.SQL thread 读取relay log，解析并且在从库中重放执行，数据同步完成。最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。

MySQL 如何知道 binlog 是完整的?

从库在解析的时候如何知道一个事务是完整的？因为一个事务的 binlog 是有完整格式的：statement 格式的 binlog，最后会有 COMMIT 标记；row 格式的 binlog，最后会有一个 XID event。