一文详解MySQL Binlog日志与主从复制

1. Binlog日志的介绍

Binlog是Binary log的缩写，即二进制日志。Binlog主要有三个作用：持久化时将随机IO转化为顺序IO，主从复制以及数据恢复。本文重点主从复制相关的问题。

Binlog日志由一个索引文件与很多日志文件组成，每个日志文件由魔数以及事件组成，每个日志文件都会以一个Rotate类型的事件结束。

对于每个事件，都可以分为事件头与事件体两部分：

事件头的结构如下所示：

事件体的结构包括固定大小与可变大小两部分。

对于Binlog日志的格式，做简单的了解即可，感兴趣的同学可以深入学习。

2. 主从复制

2.1 主从复制的流程

MySQL主从复制的流程大致如下：

• 主库同步自己的Binlog日志给从库
• 从库的IO线程将Binlog日志内容写入Relay Log
• 从库的SQL线程取Relay Log并在数据库中进行回放

2.2 GTID

GTID是指全局事务标志，用来标记主从同步的情况。

master提交一个事务时会产生GTID，并且记录在Binlog日志中。从库的IO线程在读取Binlog日志时，会将其储存在自己的Relaylog中，并且将这个值设置到gtid_next中，即下一个要读取的GTID，从库读取这个gtid_next时，会对比自己的Binlog日志中是否有这个GTID：

• 如果有这个记录，说明这个GTID的事务已经执行过了，可以忽略掉（幂等）。
• 如果没有这个记录，slave就会执行该GTID事务，并记录到自己的Binlog日志中。

2.3 复制模型

• 异步复制：master 把Binlog日志推送给slave，master不需要等到slave是否成功更新数据到Relay log，主库直接提交事务即可。这种模式牺牲了数据一致性。
• 同步复制：每次用户操作时，必须要保证Master和Slave都执行成功才返回给用户。
• 半同步复制：不要求Slave执行成功，而是成功接收Master日志就可以通知Master返回。

2.4 MGR模式

分布式一致性算法Paxos。由至少3个或更多个节点共同组成一个数据库集群，事务的提交必须经过半数以上节点同意方可提交提供，支持多写模式。

MGR 是 share-nothing 的复制方案，基于分布式paxos协议实现，每个实例都有独立的完整数据副本，集群自动检查节点信息，做数据的同步。同时提供单主模式和多主模式，单主模式在主库宕机后能够自动选主，所有写入都在主节点进行，多主模式支持多节点写入。同时集群提供冗余的容错功能，保证集群大多数节点正常集群就可以正常提供服务。

2.5 并行回放

事务回放是从库的SQL线程执行Relay Log的过程，并行回放是为了提高这一过程的效率，将可以并行进行的事务同时进行。

• 基于逻辑时钟的并行回放

因为MySQL本身事务具有ACID的特点，所以从主库同步到从库的事务，只要其执行的逻辑时间上有重叠，那么这两个事务就能安全的进行并行回放。

• 基于writeSet的并行回放

使用一个HashMap保存一定时间内针对某一块数据区域的事务的集合。如果事务在同一组内或者是逻辑时钟有重叠，说明没有冲突，其他情况不能确定是否有冲突。

到此这篇关于一文详解MySQL Binlog日志与主从复制的文章就介绍到这了,更多相关MySQL Binlog日志内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论