某实例一个从库在clone重启 时出现core，日志显示Invalid File State: 10，导致实例启动失败，本文分析该问题产生的原因。

---

1. 问题表现

从库实例一直重启失败，没有产生core文件，日志显示

[ERROR] [MY-011976] [InnoDB] [FATAL] Clone File Roll Back: Invalid File State: 10
 [ERROR] [MY-013183] [InnoDB] Assertion failure: clone0api.cc:1159:ib::fatal triggered thread 22832570353408
InnoDB: We intentionally generate a memory trap.
...
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
..

日志打印最后显示  [FATAL] Clone File Roll Back: Invalid File State: 10 ， 然后assert 错误退出。

2. 原因分析

2.1  直接原因

从日志中可知，大概是在clone 恢复的逻辑遇到了问题。 由于没有准确的堆栈信息，需从源码中分析Invalid File State的具体情况。

其中的状态cur_state: 10 标识缺少了原始的数据文件。

查看线上data目录发现缺少了undo_002 文件。这个是导致出错的直接原因。

 

2.2  undo_2_trunc.log 

仔细查看data目录还发现存在一个undo_2_trunc.log,这个文件不常见，它是在undo file 执行truncate undo时生成的临时文件。它会是导致问题的原因吗？

 

通过分析trunc.log 的作用，对照源码的逻辑，发现在服务重启流程中，如果出现undo_x_trunc.log 后清理对应的undo 文件, 然后重建undo文件。

 

 

清理undo_002 后，正常在后续流程中会重建undo_002 文件. 但此时先进入了clone 的恢复流程中，而clone 恢复需要检查Undo 的数据文件是否完整，此时发现文件不存在，报错 Invalid File State: 10 后退出。

 

 

3. 原因总结

而undo_trunc.log 残留的原因,MYSQL官方有相关BUG报告：bugid: 112717