MySQL 主从同步机制 undo log redo log和bin log的区别

秒速五厘米 2022-12-17 01:18 31阅读 0赞

## 1. 二进制日志 bin log ##

###      1.1  bin log的功能 ###

MySQL为了兼容其它**非事务引擎**的复制，在server层面引入了 binlog, 它可以记录所有引擎中的**修改操作**。

*  binlog是记录所有**数据库表结构变更**（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。
 *  binlog不会记录SELECT和SHOW这类操作，因为这类操作对**数据本身并没有修改**，但可以通过查询**通用日志**来查看MySQL执行过的所有语句。

###     ** 1.2  二进制日志包括两类文件：** ###

*  二进制**日志索引文件**（文件名后缀为.index）用于记录所有的二进制文件;
 *  二进制**日志文件**（文件名后缀为.00000\*）记录数据库所有的**DDL**和**DML**(除了数据查询语句)语句事件。
 *  mysql的binlog是多文件存储，定位一个LogEvent需要通过 **binlog filename +  binlog position，进行定位。**

###     1.3 如何开启mysql的binlog ###

vi /etc/my.cnf
    
    log-bin=mysql-bin #添加这一行就ok
    binlog-format=ROW #选择row模式
    server_id=1 #配置mysql replaction需要定义，不能和canal的slaveId重复

###   1.4  bin log 常用格式 ###

通常选用 row格式，一方面可准确的记录每行数据的变更，在现有的网络环境基础上，这些网络IO和磁盘IO均可以支撑。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70][]

## 2. 什么是事务日志 ##

Innodb事务日志包括redo log和undo log, 事务日志的目的：实例或者介质失败，事务日志文件就能派上用场。

###   2.1 Undo Log ###

1.   Undo Log 是为了实现事务的**原子性**而出现的产物, 在Mysql innodb存储引擎中用来实现多版本并发控制 MVCC;
2.   Undo Log 是用来**保存事务未提交之前的版本数据**。Undo中的数据可作为数据旧版本快照，供其他并发事务进行快照读 , 用来回滚行记录到某个版本。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70 1][]

##  2.2 RedoLog  ##

1.  RedoLog 是为了实现事务的**持久性**而出现的产物;
2.  RedoLog 是**在事务的执行过程中**，便开始写入redo 中。具体的落盘策略可以进行配置 。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的未入磁盘数据进行持久化这一特性。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70 2][]

###   2.3 快照读和当前读 ###

*  快照读：SQL读取的数据是**快照版本（历史版本）**，普通的SELECT就是快照读 innodb快照读，数据的读取，将由 cache(原本数据) + undo(事务修改过的数据) 两部分组成
 *  当前读：SQL读取的数据是**最新版本**。通过锁机制来保证读取的数据无法通过其他事务进行修改 UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE都是 当前读

## 3. 如何解决事务日志与 binlog的一致性问题 ##

MySQL为了兼容其它非事务引擎的复制，在server层面引入了 binlog, 它可以记录所有引擎中的修改操作，因而可以对所有的引擎使用复制功能； 然而这种情况会导致 redo log 与 binlog 的一致性问题；

MySQL通过**内部XA机制**解决这种一致性的问题。XA(分布式事务)规范主要定义了**(全局)事务管理器(TM: Transaction Manager)**和**(局部)资源管理器(RM: Resource Manager)**之间的接口。

XA为了实现分布式事务，将事务的提交commit分成了两个阶段，2PC (Tow Phase Commit)，XA协议就是通过将事务的提交分为两个阶段来实现分布式事务。

*  第一阶段：InnoDB prepare， write/sync **redo log**；**binlog不作任何操作**；
 *  第二阶段：包含两步：

1.   write/sync Binlog；

当 write/sync Binlog执行完成之后，binlog已经写入，MySQL会认为**事务已经提交并持久化**了(在这一步binlog就已经ready并且可以发送给订阅者)。在这个时刻，**即使算数据库发生了崩溃，那么重启MySQL之后依然能正确恢复该事务**。在这一步之前包含这一步任何操作的失败都会引起**事务的rollback**。

2. InnoDB commit (commit in memory)；

第二阶段的第2步，大部分都是**内存操作**(注意是 InnoDB commit 不是事务的commit)，比如释放锁，释放mvcc相关的read view等等。MySQL认为这一步不会发生任何错误，**一旦发生了错误那就是数据库的崩溃，MySQL自身无法处**理。这个阶段没有任何导致事务rollback的逻辑。在程序运行层面，只有这一步完成之后，事务导致变更才能通过API或者客户端查询体现出来。

3. MySQL会在**binlog落盘之后**会立即将新增的binlog发送给订阅者以尽可能的**降低主从延迟**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70]: /images/20221123/f6b1978e3d964ce891101c8f38363dce.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70 1]: /images/20221123/1c4478a1f27045efbf04e14c35ec8f87.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA4OTk5ODU_size_16_color_FFFFFF_t_70 2]: /images/20221123/6d3713b026944037940063f75df0c58b.png