MySQL的redolog、binlog日志与两阶段提交（2PC）

一、redolog、binlog日志简介

1.1内容

bin log（binary log）

二进制日志文件，也叫作变更日志（update log），它记录了所有更新数据库的语句（如DDL和 DML语句）并以二进制的形式保存在磁盘中，但是不包含没有修改任何数据的语句（不含查询操作。数据查询语句select、show等）。
bin log是逻辑日志，记录的是执行语句的逻辑，和redis的AOP日志类似，会按顺序记录所有涉及更新数据的逻辑操作。

redo log(重做日志)

redo log重做日志，是Innodb存储引擎生成的日志，记录的是物理级别上的页修改操作，为MySQL提供了崩溃恢复的能力，实现了事务的持久性。

InnoDB的事务采用了WAL技术（Write-Ahead Logging）既先写日志，再写磁盘。MySQL每执行一条DML语句，先将记录写入内存分配的redo log buffer中，后续再一次性将redo log buffer中的内容写到redo log文件中，而被修改的数据页由checkpoint机制保证最终落盘。
redo log是物理日志

差异与共同点

1. redo log是物理日志，记录内容是“在某个数据页上做了什么修改”，属于InnoDB存储引擎层，在事务过程中是不断写入的。
2. bin log 是逻辑日志，记录内容是语句的原始逻辑，属于Server层，只在事务提交时才写入。
3. redo log 和bin log都是以事务为单位

1.3事务提交commit与redolog、binlog日志

1. 在事务执行过程中，redo log 是持续写入的
Innodb是以页为单位来进行磁盘IO，页大小默认为16KB。在访问页时，要先将页从磁盘上 缓存到 内存中的Buffer Pool 缓冲池中。所有数据的变更都要在这个缓冲池中进行处理。变更之后的页就形成了脏页，缓冲池会以一定的频率（checkPoint机制）将脏页刷新到磁盘。缓冲池的目的是减轻CPU和磁盘之间的速度差带来的性能影响。但是由于脏页刷入磁盘不是每次变更后立即触发的，这就可能在事务提交之后刚写完缓冲区，此时MySQL宕机了，就会丢失这部分数据，这不符合事务的持久性要求。
于是使用redolog解决这个问题。先将变更的内容记录到磁盘中（存储表空间ID、页号、偏移量和需要更新的值），这样日志占据空间小以及刷盘频率可控。

2. 只有事务提交commit之后，才写入binlog
A. 事务提交commit
B.MySQL将更新内容写入binlog
C.主库dump线程将binlog更新数据发送到备库
D.备库IO线程接受数据，落地到relaylog
E.备库落地到relaylog,返回ack
F.主库接收到足够ack(默认半同步备库数量-1),完成engine commit,交易成功结束。

这样也可能出现问题。
执行过程中一直在写redo log，但是当事务提交时，才开始写bin log，如果此时MySQL系统崩溃，bin log还未来得及写入。MySQL系统重启后发现redo log有记录，主库通过redo log恢复了更新的记录，而从库通过bin log同步数据造成了主从数据同步的不一致，这是不允许的。

为了解决两份日志之间的逻辑一致问题，InnoDB存储引擎使用两阶段提交方案。

1.4 binlog日志特点

1.串行化。即使交易、事务是多线程的，binlog日志写入仍然是串行的，写入传输binlog的时间与数据量成正比，大事务写入binlog时，会影响其他交易。建议避免一次事务写入过多binlog，
2.可持久化。如设置sync_binlog=1,每次事务提交，必须落盘到binlog，保证数据一致性不丢失。但由于落盘性能低于内存操作，因此事务commit越频繁，效率越低。建议写入大量数据，批量场景时，考虑多笔合并一次commit，降低commit频率。
3. 受网络和备库影响。binlog需同步到备库，如果网络断开或都懂或所有备库都断开，交易会hang住。建议：关注数据库、服务器、网络监控与应急
4. 数据量大。binlog记录更新的所有数据内容，默认保留7天数据，应用数据量更新越大，binlog数据量越大，占据磁盘空间就越大。大量更新数据可能导binlog日志剧增引发磁盘空间不足，导致数据库无法正常服务。建议：设置日志保留天数、控制日志大小
5. 锁机制。清理binlog会对binlog上锁，影响更新类交易。建议：不要一次清理过多binLog.

二、两阶段提交-2PC

2.1 过程

两阶段提交：将redo log的写入操作拆成了两个步骤prepare和commit进行，在事务执行期间，写入的redo log标记为prepare阶段，待事务提交且bin log写入成功时，才将redo log标记为commit阶段。

2.2作用

2.2.1写入bin log时发生异常

使用两阶段提交后，写入bin log时发生异常也不会有影响，因为MySQL在使用redo log恢复时，发下redo log还处于prepare阶段，而且此时没有bin log，认为该事务操作尚未完成提交，会回滚此操作。

2.2.2redo log在commit阶段发生异常

虽然MySQL重启后发现redo log是处于prepare阶段，但是能通过事务id找到了对应的bin log记录，所以MySQL认为此事务执行是完整的，就会提交事务恢复数据。

2PC

什么是 2PC

2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议
对比分布式数据库的3PC提交，后续叙述。

两个阶段过程：

准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。