MySQL如何保证数据不丢失

实现技术基础

MySQL 的两阶段提交 + WAL技术（Write-Ahead Logging，先写日志再写盘），这两个结合在一起保证了数据不会丢失。

先来看看 MySQL 两阶段提交和WAL流程

binlog

binlog 在一个事务内，先将 binlog 写到 binlog buffer，然后在write binlog files，然后再 fsync 到磁盘，这里根据参数 sync_binlog 进行控制：

• 设置0：表示事务提交只 write，不 fsync
• 设置1：表示事务提交 write 后，立马 fsync
• 设置N：表示事务提交 write 积累到N条后，才 fsync

设置N的风险是如果主机掉电，N条记录会丢失的风险

redo log

redo log 事务从 redo log buffer （redo logo buffer 是在 MySQL 进程中的） write 到 linux 文件系统的 page cache ，然后在 fsync 到磁盘，
这里根据参数 innodb_flush_log_at_trx_commit 参数控制 write 和 fsync 时机：

• 设置0：表示每次事务提交只留在 redo log buffer
• 设置1：表示每次事务提交都 fsync 到磁盘
• 设置2：表示每次事务提交都只写到 page cache

innodb后台有一个线程，每秒 redo log 从 redo log buffer write 到 page cache，然后 fsync 到磁盘，除了线程轮询，MySQL 还有两种将 redo log fsync 到磁盘的时机

• redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候，innodb 会将 redo log buffer 里的 redo log write 到 page cache，（也就是说，一个还没有提交事务的 redo log，也可能已经被持久化到磁盘了）
• 并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁盘。前提是 innodb_flush_log_at_trx_commit 设置的是1

组提交

MySQL这样设计的好处是，可以组提交，交叉 fsync。 一组 fsync 收集的 write 越多， 对应的磁盘的IO越少，提高 MySQL 性能。
因此，WAL的优势在于：

• redo log & binlog 都是按顺序写入磁盘的，比随机写磁盘速度快。
• 组提交机制，合并fsync。大幅度降低磁盘的 IOPS 消耗，提高IO性能。

全景图

参考文献

• [1]MySQL 基础技术（三）—— MySQL 如何保证数据不丢失？
• [2]极客时间 —— MySQL 如何保证数据不丢失？