一张图让你牢记MySQL主从复制原理｜原创 (qq.com)
为什么需要主从复制？
1、读写分离，增强MySQL数据库的可用性。
2、做数据的热备。
3、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
说说Binlog
MySQL的Server之间通过二进制日志来实现实时数据变化的传输复制，这里的二进制日志是属于MySQL服务器的日志，记录了所有对MySQL所做的更改。这种复制模式也可以根据具体数据的特性分为三种：
-
Statement：基于语句格式
Statement模式下，复制过程中向获取数据的从库发送的就是在主库上执行的SQL原句，主库会将执行的SQL原有发送到从库中。
-
Row：基于行格式
Row模式下，主库会将每次DML操作引发的数据具体行变化记录在Binlog中并复制到从库上，从库根据行的变更记录来对应地修改数据，但DDL类型的操作依然是以Statement的格式记录。
-
Mixed：基于混合语句和行格式
MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。
什么是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.生成被修改数据行对应的 undo 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。