背景
数据库的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流程分为以下两步:
-
X-Engine存储引擎元信息回放,恢复系统元信息数据到shutdown前状态
-
wal文件回放,逐条读取record,进行crc校验后,恢复所有的ImmutableMemTables和MemTables到shutdown前状态
当前MySQL(XEngine)线上实例有宕机重启缓慢的现象,通过对相关现场分析和线下试验,WAL的回放占据了X-Engine宕机重启的绝大部分时间。结合现有实现分析