当数据库 crash 后，如何恢复未刷盘的数据到内存中？

当数据库发生 crash 后，恢复未刷盘的数据主要依赖于 **redo log** 和 **binlog** 的两阶段提交机制，数据恢复过程根据不同的情况进行： ### 数据恢复的几种情况 1. **Change Buffer 写入，redo log fsync 但未 commit，binlog 未 fsync 到磁盘**： - 在这种情况下，**redo log** 已经做了 fsync（持久化到磁盘），但事务未提交，同时 **binlog** 也未写入磁盘。 - 由于 **binlog** 没有持久化，这部分数据没有完整的记录，因此这部分数据将丢失，无法恢复。 2. **Change Buffer 写入，redo log fsync 未 commit，binlog 已经 fsync 到磁盘**： - **redo log** 已经 fsync，但未 commit，**binlog** 已经 fsync 到磁盘，意味着 binlog 记录了该事务的操作，但 **redo log** 仍然不完整。 - 在这种情况下，MySQL 会首先通过 **binlog** 恢复未完成的 **redo log**，恢复其未 commit 的部分。 - 接着，使用恢复后的 **redo log** 来恢复 **change buffer** 中的数据，确保数据一致性。 3. **Change Buffer 写入，redo log 和 binlog 都已经 fsync**： - 当 **redo log** 和 **binlog** 都已经 fsync 到磁盘时，数据已经安全地记录在了这两种日志中。 - 这时，只需要直接从 **redo log** 中恢复数据即可，无需依赖 **binlog**。 ### 恢复机制的工作原理 - **Redo log** 主要用于物理层面的恢复，记录了具体的数据页修改。因此，MySQL 重启时，InnoDB 引擎会首先检查 **redo log**，将日志中的修改应用到相应的数据页上，从而恢复未刷盘的数据。 - 如果 **redo log** 不完整，则会检查 **binlog**，通过 binlog 的逻辑操作恢复 **redo log**，再继续进行物理恢复。 通过这种机制，数据库在 crash 后能够有效恢复数据，确保系统的可靠性和一致性。