Hasura迁移记录在数据库中的存储位置有哪些？

Hasura的迁移相关记录主要存储在3个位置：

• 服务端对应数据库的hdb_catalog.schema_migrations表：存储所有通过标准迁移流程执行的迁移时间戳，是服务端判断迁移是否执行的核心依据。
• Hasura项目本地的migrations/目录：存储所有迁移的SQL、元数据变更文件，CLI执行hasura migrate status命令时，会将该目录下的迁移时间戳与服务端schema_migrations的记录做比对，输出最终状态结果。
• 服务端hdb_catalog下的元数据表：包括hdb_metadata、hdb_source等，针对v2.0及以上版本的多数据源项目，不同数据源的迁移关联配置、元数据变更记录都会存储在这些表中，不会写入schema_migrations。

这类状态不一致问题，通常由以下几种原因导致：

1. 本地migrations/目录与prod环境执行迁移时使用的目录不一致。如果prod环境做过迁移合并（squash）操作，旧的迁移时间戳会被合并为新的时间戳，不会再出现在schema_migrations表中，如果本地还保留了被合并的旧迁移文件，就会显示这些迁移未执行。
2. 导出prod数据库时未完整导出hdb_catalog schema的全部内容，仅导出了schema_migrations表，导致本地恢复后Hasura缺失部分迁移关联配置。
3. 多数据源项目执行hasura migrate status时未指定--database-name参数，默认仅查询默认数据源的迁移状态，无法匹配其他数据源的迁移记录。

对应的修复方案：

• 先对齐本地和prod的migrations/目录，删除本地多余的、已被squash的旧迁移文件
• 重新导出prod的完整hdb_catalog schema后恢复到本地
• 多数据源项目核对每个数据源的迁移状态时，执行hasura migrate status --database-name <对应数据源名>
• 若确认迁移已经在prod实际执行完成，可在本地执行hasura migrate apply --skip-execution --version <对应迁移时间戳>手动标记迁移为已执行，修复状态偏差。

内容的提问来源于stack exchange，提问作者Joan-Diego Rodriguez