元信息的自检和修复

为了解决业务项目中频繁发生的问题：由于 MS & DS & RDB（MySQL）三方模型元信息和业务表结构不一致导致系统运行和使用异常问题和排查困难的窘境，主要基于事后补偿的思路，在交互控制台提供一个人工检测和修复模型元信息不一致现象的功能入口。该功能支持版本为：

trantor-parent：0.18.6-SNAPSHOT 或者之后的版本（可不升级）
metastore image：
    研发态：registry.cn-hangzhou.aliyuncs.com/terminus/trantor-metastore-management:211018.210945
    运行态：registry.cn-hangzhou.aliyuncs.com/terminus/trantor-metastore-runtime:211018.210945
    datastore-server：registry.cn-hangzhou.aliyuncs.com/terminus/datastore:5.2.0.18.18.20210929
    datastore-search：registry.cn-hangzhou.aliyuncs.com/terminus/datastore-search:5.2.0.18.18.20210929
    console：registry.cn-hangzhou.aliyuncs.com/terminus/trantor-console:1.18.0-support-console-18.28

主要操作步骤：

部署上面给出的所有服务的镜像
业务模块需要将 trantor-parent 依赖更新为对应版本
重新上报发布业务模块元信息
请求分析接口即可返回分析结果

创建自检修复计划

在 发布管理 -> 检测和修复 -> 新增，创建新的自检修复计划，如下图所示：

进行检测和修复

点击查看 -> 开始检测，进行自检修复操作：

检测 DS 元信息与 RDB 业务表差异

以下操作涉及 安全生产 相关，可以点击安全生产了解，安全生产默认为未开启状态。

在当前页面【DS与业务表差异】内容下会以 Tab 页签的方式展示差异类型，并且只展示被检测到差异的类型

未开启安全生产：

开启安全生产：

修复 DS 元信息与 RDB 业务表差异

未开启安全生产：
后台自动执行修复的ddl语句。

开启安全生产：
当前步骤页面会展示出用于修复差异问题而需要执行的 DDL 脚本，如下图中的【修复SQL脚本（每个页签代表一个数据源）】信息，每个 Tab 页签代表一个数据源，在运行环境开启了分库的场景下，就会存在多个数据源页签，未开启分库则只会有一个 trantor_default 的数据源。
用户需要复制每个数据源中的脚本，手动在对应数据源环境内执行 DDL 脚本，当全部脚本执行完成之后，则代表当前修复操作完成，可以点击右上角的【开始下一步检测】进行下一个环节。

检测 MS 与 DS 元信息差异

在当前步骤页面也会以 Tab 页签的形式展示 MS & DS 元信息存在的差异类型，只展示被检测到差异的类型查看完检测结果后，点击右上角的【开始修复】按钮进入下一步的修复环节。

修复 MS 与 DS 元信息差异

未开启安全生产：
后台自动执行修复的ddl语句，点击右上角的【执行修复】按钮才能真正完成本次修复。

开启安全生产：
当前修复步骤页面中会展示需要用户手动执行的修复 DDL 和与之对应的回滚 DDL，两者是一一对应，当我们在执行左侧 DDL 脚本过程中出现执行失败的情况，我们需要将发生执行失败的那条 DDL 之前的已经成功执行的所有 DDL 记录下来，并且按照序号找到与之对应的回滚 DDL，重新执行一次回滚 DDL 脚本，用于还原现场.
注意：回滚 DDL 的执行顺序应该是与左侧执行 DDL 相反。
在开启分库场景下，依然是以 Tab 页签形式展示每个数据源下需要执行的修复脚本。
未开启分库场景下，则只有一个数据源页签 trantor_default，如上图中所示。
用户需要复制每个数据源中的脚本进入对应数据源环境中执行 DDL 脚本，当执行完所有数据源脚本后，我们还需要点击右上角的【执行修复】按钮才能真正完成本次修复。