背景

数据库的Crash Recovery时长关系到数据库的可用性SLA、故障止损时间、升级效率等多个方面。本文描述了针对X-Engine数据库存储引擎的一种Crash Recovery优化手段，在典型场景下可以显著缩短数据库实例的故障恢复时间，提升用户使用感受。

当前面临的问题

X-Engine是阿里自研的基于LSM-tree架构的数据库存储引擎，对X-Engine的数据更新是将变更数据并行插入无锁内存表（MemTable），同时为了防止MemTable过大影响数据查找和数据恢复的效率，系统会不定期将MemTable转换成不可修改的内存表（ImmutableMemTables），并将ImmutableMemTables整体Flush落盘；对无锁内存表的持久化通过WAL机制保证。关于LSM-tree结构和X-Engine的数据分层存储机制，可以阅读文章：X-Engine 一条数据的漫游

X-Engine存储引擎的故障恢复需要读取所有WAL文件并重新生成所有ImmutableMemTables 和MemTables。当前X-Engine的Crash Recovery流程分为以下两步：

1. X-Engine存储引擎元信息回放，恢复系统元信息数据到shutdown前状态

2. wal文件回放，逐条读取record，进行crc校验后，恢复所有的ImmutableMemTables和MemTables到shutdown前状态

当前MySQL(XEngine)线上实例有宕机重启缓慢的现象，通过对相关现场分析和线下试验，WAL的回放占据了X-Engine宕机重启的绝大部分时间。结合现有实现分析࿰