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均可以支撑。

mysql binlog无内容 mysql binlog undolog redolog_数据

 

 

2. 什么是事务日志

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

  2.1 Undo Log

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

                       

mysql binlog无内容 mysql binlog undolog redolog_数据_02

 

 

 2.2 RedoLog 

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

                      

mysql binlog无内容 mysql binlog undolog redolog_数据_03

  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 的一致性问题；

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

将事务的提交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发送给订阅者以尽可能的降低主从延迟