MySQL报错ER_NDB_CANT_FIND_TABLE咋整，远程帮忙修复故障经验分享

这个错误信息，说白了，就是MySQL集群（他们叫NDB Cluster）里的一个数据节点，在需要打开一张表的时候，突然说“我找不着这张表了！”，你明明在SQL节点（就是咱们平时连上去执行命令的那个MySQL）上用SHOW TABLES能看到表名，但一查询就报这个错，这种情况在我过去处理的一次线上故障中非常典型,那次真是折腾了大半天。

那次的情况是这样的：一个做实时数据处理的业务，底层用的是MySQL NDB Cluster，某天下午，应用突然开始大量报错，全是这个ER_NDB_CANT_FIND_TABLE，业务基本卡死，我按照常规思路，先登录到管理节点（ndb_mgmd）上，用ndb_mgm -e "SHOW"命令看了一下集群状态，奇怪的是，所有节点（管理节点、数据节点、SQL节点）都显示是连接状态，没有明显的节点宕机，这就排除了最简单的那种“某个数据节点挂了导致数据不同步”的可能性。

既然集群状态看起来是好的，那问题可能出在表本身的元数据（就是描述这张表结构的信息）上，在NDB集群里，表的元数据是在所有数据节点和管理节点之间同步的，我怀疑是某个数据节点上的表元数据莫名其妙丢失或损坏了，我尝试了第一个操作：在SQL节点上对报错的表执行ALTER TABLE语句，想通过一个无伤大雅的表结构修改（比如给某个字段加个注释），来触发一下元数据的重新同步，结果，这个ALTER TABLE命令也失败了，报的是同样的错误,这条路走不通。

这时候，有点棘手了，因为直接操作表已经不行了，我必须得用更底层的方法，我想起了NDB集群有一个从备份恢复元数据的机制，幸运的是，这个系统有定期的元数据备份，我的思路是：尝试用备份的元数据来恢复出问题的数据节点，具体命令是连接到管理客户端后，使用RESTORE METADATA命令，这个操作有点风险，因为它会用备份的元数据覆盖当前数据节点上的元数据，在执行之前，我反复确认了备份的时间点,确保它是在问题发生之前生成的。

怀着忐忑的心情执行了RESTORE METADATA，命令跑完后，我立刻在SQL节点上再次尝试查询那张表，令人失望的是，错误依旧，这说明，要么元数据恢复没成功，要么问题的根源不在这里，时间一分一秒过去,业务方的电话越来越急。

我冷静下来重新思考，元数据恢复无效，那是不是数据本身出了问题？但SHOW TABLES能看到表，说明SQL节点认为表是存在的，这形成了一个矛盾，我突然想到一个可能性：是不是SQL节点本地的“.frm”文件（它存储表结构）和数据节点上的NDB存储引擎的元信息不一致？在NDB集群中，SQL节点上的.frm文件必须和数据节点上的元数据严格匹配。

我决定检查一下这个，我找到了报错表对应的.frm文件，它确实存在，强制让SQL节点重新认识一下这张表或许有用，我采取了比较大胆的一步：我先在SQL节点上DROP TABLE了那张报错的表，注意，这一步极其危险，因为在正常情况下，这会把表和数据都删掉，但我之前确认过，我们的数据有另外的实时备份，并且我坚信数据在NDB集群的数据节点上是完好无损的，只是“访问路径”出了问题。DROP命令成功了，这反而让我松了口气,因为它说明SQL节点的操作还能和数据节点通信。

关键的一步来了：重新创建表，我手头有这张表的完整建表语句（DDL），我在SQL节点上原封不动地执行了这份建表语句，奇迹发生了，创建命令成功执行！创建完成后，我立刻执行了一个SELECT COUNT(*)进行测试，查询成功返回了结果，数据量也和之前对得上，应用重新连接后，报错消失,业务恢复正常。

事后复盘，问题的根本原因被认为是：由于未知原因（可能是临时的网络抖动或软件bug），某个数据节点上关于这张表的“内部标识符”变得无效了，导致SQL节点在请求数据时，数据节点无法正确映射和定位，而DROP后再CREATE的过程，相当于在SQL节点和数据节点之间重新建立了一次关于这张表的“契约”，分配了新的、一致的内部标识符,从而解决了问题。

这次经历给我的教训是：第一，处理NDB集群问题，一定要有清晰的架构概念，明白元数据在哪里存储、如何同步，第二，当常规方法无效时，要敢于考虑元数据不一致这种更深层次的原因，第三，也是最重要的，在进行任何有风险的操作（尤其是DROP TABLE）之前，必须百分百确认数据有可用的备份，并且团队对风险有充分的认知，这个方法算是“置之死地而后生”，不能作为首选方案,但在特定情况下可能是唯一有效的救命稻草。

就是我处理ER_NDB_CANT_FIND_TABLE错误的一次真实经历分享。