从MySQL日志系统设计中学习高可用方案

MySQL的InnoDB中的更新语句大致流程是这样的：

1. 首先开启一个事务；
2. 先查询到需要更新的记录，加锁；
3. 更新记录；
4. 写RedoLog，将事务标记为prepare状态；
5. 写BinLog；
6. 事务提交，将事务标记为commit状态；
7. 返回影响行数至客户端。

其中写redolog和binlog是历史原因造成的，因为MySQL的原生引擎是MyISAM，BinLog也是原生的。而InnoDB是以插件形式添加到MySQL中的，为了实现CrashSafe才有RedoLog。

双日志写入是使用经典的两阶段提交保证事务完整性的。

RedoLog是InnoDB引擎层面实现的，记录了“在某数据页上做了什么修改”，注意这里RedoLog写成功即可认为事务已经成功。即使这里发生Crash的话，重启系统能够根据RedoLog恢复。
BinLog是MySql的Server层面实现的，所有的引擎通用，是逻辑日志。记录的是这个语句的原始逻辑。

这就是所谓的Write-Ahead Logging(WAL)技术。

这里有个点需要提一下，设计上为什么要先写RedoLog，而不是直接写磁盘呢？之所以这样设计是因为日志追加写减少了磁盘寻址的时间，速度更快。

我认为所有带状态的系统都可以学习MySQL的设计思想来实现自己的高可用方案，拥有CrashSafe能力。