转载： 数据库月报 https://juejin.cn/post/7220579581919903781

MySQL Replication（主从复制）是指数据变化可以从一个MySQL Server被复制到另一个或多个MySQL Server上

MySQL的Server之间通过二进制日志来实现实时数据变化的传输复制，这里的二进制日志是属于MySQL服务器的日志，记录了所有对MySQL所做的更改。这种复制模式也可以根据具体数据的特性分为三种：

• Statement：基于语句格式

• Statement模式下，复制过程中向获取数据的从库发送的就是在主库上执行的SQL原句，主库会将执行的SQL原有发送到从库中。

• Row：基于行格式

• Row模式下，主库会将每次DML操作引发的数据具体行变化记录在Binlog中并复制到从库上，从库根据行的变更记录来对应地修改数据，但DDL类型的操作依然是以Statement的格式记录。

• Mixed：基于混合语句和行格式

• MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。

Event

对于Binlog的定义而言，可以认为是一个个单一的Event组成的序列，这些单独的Event可以主要分为以下几类

Event规则

• XID_EVENT标志一个事务的结尾

• 当发生了DDL类型的QUERY_EVENT，那么也是一次事务的结束提交点，且不会出现XID_EVENT

• GTID_EVENT只有开启了GTID_MODE（MySQL版本大于5.6）

• TABLE_MAP_EVENT必定出现在某个表的变更数据前，存在一对多个ROW_EVENT的情况

Binlog和Innodb Log（redolog）的存在方式是不同的，它并不会轮转重复覆写文件，Server会根据配置的单个Binlog文件大小配置不断地切分并产生新的Binlog，在一个.index文件记录当前硬盘上所有的binlog文件名，同时根据Binlog过期时间回收删除掉过期的Binlog文件，这两个在目前自建数据库的配置为单个大小1G，保留7天。

GTID

Binlog在产生时是严格有序的，但它本身只具备秒级的物理时间戳，所以依赖时间进行定位或排序是不可靠的，同一秒可能有成百上千的事件，同时对于复制节点而言，也需要有效可靠的记录值来定位Binlog中的水位，MySQL Binlog支持两种形式的复制基准值，分别是传统的Binlog File:Binlog Position模式，以及5.6版本后可用的全局事务序号GTID

Log_bin

当前处在File对应编号的Binlog文件中，同时已经产生了合计Position bytes的数据

复制流程

当主库已经开启了binlog( log_bin = ON )，并正常地记录binlog，如何开启复制？

这里以MySQL默认的异步复制模式进行介绍：

1. 首先从库启动I/O线程，跟主库建立客户端连接。

2. 主库启动binlog dump线程，读取主库上的binlog event发送给从库的I/O线程，I/O线程获取到binlog event之后将其写入到自己的Relay Log中。

3. 从库启动SQL线程，将等待Relay中的数据进行重放，完成从库的数据更新。

• Master将数据更改记录在Binlog中，BinlogDump Thread接到写入请求后，读取对应的Binlog

• Binlog信息推送给Slave的I/O Thread。

• Slave的I/O 线程将读取到的Binlog信息写入到本地Relay Log中。

• Slave的SQL 线程读取Relay Log中内容在从库上执行。