交付控制台检测与修复使用指南

一：背景

目前在DS服务端部署模式下，trantor稳定运行需要依赖三种数据的一致性，即MS元信息，DS元信息，DS管理的DB表结构，其中，DS元信息和表结构不一致， MS元信息和DS元信息不一致，都会引起各种问题，比如最常见的发布时报表已经存在或者字段已经存在问题，执行某些模型的CURD操作时报相关模型不存在等异常。这些问题产生的原因有以下几种原因：

(1) 有人手动更改业务表结构，包括添加删除字段，更改字段类型等。

(2) 环境迁移，将某个环境的业务表结构和数据直接迁移到另外一个环境，导致DS元信息和表结构产生大量不一致问题

(3) MS bug导致，MS自己生效了某个模型元信息，但是并没有将该模型元信息发布给DS

(4) DS bug导致，DS发布流程存在bug，没有成功发布MS传过来的模型元信息，但是返回给MS了发布成功

以上问题主要(1)，(2)比较常见；(3)在比较老的MS版本曾经出现过几次；(4)出现的概率非常低。为了能够快速解决以上问题的DS元信息和表结果不一致问题，一开始DS提供了根据DS元信息快速修复表结构的接口，但随着支撑的项目越来越多，问题场景也变得越多样，MS和DS元信息不一直时也一直没有快速修复方案，所以可以让业务同学快速自行排查与修复MS，DS元信息不一致，DS元信息和表结构不一致的检测与修复功能诞生了。

二：使用步骤及每一步能解决的常见问题

1. 检测与修复的流程概括：

(1) 检测DS元信息和表结构是否一致：首先检测DS元信息和表结构是否一致，不一致的话，比如表里面缺少字段，或者缺少表，会返回相关结果到交付控制台。

(2) 根据DS元信息修复表结构：如果DS元信息和表结构不一致，下一步操作根据当前项目是否开启安全生产决定是自动修复还是返回SQL脚本让用户手动修复相关问题，具体细节参考下一小节。

(3) 检测MS和DS元信息是否一致：DS元信息和表结构不一致问题修复完成后，开始检测MS和DS元信息是否一致。

(4) 根据MS元信息修复DS元信息：MS重新发布全量元信息到DS，抹平MS DS元信息差异点。

(5) 修复完成

2.检测与修复操作流程及解决的问题类型

2.1 创建检测与修复计划

说明：

计划名称：任意文本
目标环境：选择需要操作的目标运行环境，可选项与交互控制台的【运行环境管理】列表一致
业务域范围：需要先选择目标环境后，再选择业务域范围，范围分为两类：
- 全部：检测和修复目标运行环境下所有业务域的元信息
- 可选：可以指定多个目标业务域

这里选择【可选】的业务范围，只针对整个检测修复流程中最后两个环节的【MS检测】和【MS修复】有效，而前两个环节的【DS检测】和【DS修复】我们认为最好是能够一次性全面修复掉 DS 元信息和 RDB 业务表的差异，当时考虑到的原因主要有两点：

考虑到业务域之间普遍存在模型关联场景，对应到 RDB 上就是多表关联，如果只检测和修复部分业务域，而遗漏了关联业务域，很可能会衍生出新的差异问题。

提供业务域范围【可选】选项是考虑到如果直接处理所有业务域，在【MS检测】和【MS修复】环节可能会因需要处理的数据量太大导致执行缓慢或超时，因此提供一种业务域可选的方式。

2.2 开启检测和修复流程

点击计划的【查看】按钮进入计划详情页

点击右上角的【检测】按钮开始执行检测DS元信息和表结构是否一致检测结果

2.3 查看DS元信息和表结构是否一致检测结果

开启检测修复流程后，进入的第一个环节就是检测 DS 元信息和DB中业务表结构的差异

当前结果展示的是以DS元信息为准，业务表结构和DS元信息的差异点，比如某个模型对应的表中缺少的字段，某个模型缺少对应的表等。

检测结果根据不同的差异类型分成不同的Tab页展示，包含的Tab页以及每种问题对业务对影响如下：

表里缺少的字段：查询存在问题的模型时会报字段不存在异常
表里多余的字段：存在问题的模型添加新字段时可能会报字段已经存在异常
表里缺少的索引：缺少普通索引容易导致慢查询，缺少唯一索引可能会导致慢查询和业务数据异常
表里多余的索引：存在问题的模型添加新索引时可能会报索引已经存在异常
默认值不匹配的字段，DS 元信息数据中标记的字段默认值，与数据库表 column default 值不一致：可能会导致业务数据异常
nullable不匹配的字段，DS 元信息数据中标记的字段是否允许为空，与数据库表 column nullable 值不一致：可能会导致业务数据异常
表里缺失的关联关系：会导致存在问题模型操作relation异常
缺失的Link：会导致存在问题模型操作Link异常
缺少的表：查询存在问题的模型时会报表不存在异常
多余的表（垂直分库时汇总全部数据源下多余的表）：发布新模型时可能会报表已经存在异常
每个数据源下多余的表（垂直分库时按数据源进行展示）：发布新模型时可能会报表已经存在异常
异常信息：检测异常信息

2.4 修复业务表和DS元信息之间的差异

查看完检测结果后，可以点击右上角的【开始修复】按钮，进入【DS修复】步骤

在当前步骤中，根据运行环境是否开启了安全生产模式，会有不同的处理方式。

2.4.1 非安全生产模式

非安全生产模式下，点击开始修复后，会调用DS的修复接口，一些差异点DS会自动修复掉，一些差异点DS会返回SQL脚本到交付控制台。需要用户手动处理。 DS会自动修复的问题如下：

缺少的表
表里缺失的关联关系
缺失的Link
表里缺少的字段
默认值不匹配的字段
nullable不匹配的字段

需要用户手动执行修复SQL脚本的问题如下：

多余的表
表里多余的字段
表里缺少的索引
表里多余的索引需要手动修复的问题用户根据实际情况决定要不要执行某些SQL脚本，比如有些表业务在使用，但是不归DS管理，这种表就不能直接执行DS生成的drop语句删掉。

为什么有的可以自动修复，有的问题需要用户手动执行SQL脚本修复？

多余的表不自动删除原因：有些表可能业务在某些场景使用，但不归DS管理，DS无法判断哪些多余的表应该删除，哪些不应该删除

表里多余的字段不自动删除原因：有些字段可能业务在某些场景使用，但不归DS管理，DS无法判断哪些多余的字段应该删除，哪些不应该删除

表里缺少的索引不自动添加原因：缺少唯一索引时，表里已经存在的数据可能不符合唯一索引约束，自动修复失败概率较大。

表里多余的索引不自动删除原因：某些索引可能是业务同学手动添加，为了优先保证业务数据的正确性，DS不自动删除多余的索引

2.4.1 安全生产模式

安全生产模式和非安全生产模式的区别是非安全生产模式下有的问题DS自动修复了，有的需要用户执行SQL手动修复，安全生产模式下则全部问题都需要用户手动执行交付控制台返回的SQL脚本修复

在运行环境开启了分库的场景下，就会存在多个数据源页签，未开启分库则只会有一个 trantor_default 的数据源。

2.5 以MS元信息为准，检查MS和DS之间的元信息差异

当DS元信息和表结构差异修复完成后，点击”开始下一步检测”开始检测MS和DS元信息差异

获取MS和DS元信息差异信息

在当前步骤页面也会以 Tab 页签的形式展示 MS & DS 元信息存在的差异类型，只展示被检测到差异的类型，可能的差异类型如下：

DS相对MS多余的模型
DS相对MS模型缺少的模型
DS与MS不匹配的模型
DS相对MS模型缺少的字段
DS相对MS模型多余的字段
DS与MS不匹配的字段
DS相对MS多余的索引
DS相对MS模型缺少的索引

查看完检测结果后，点击右上角的【开始修复】按钮进入下一步的修复环节。

2.6 以MS元信息为准，修复MS和DS之间的元信息差异

在当前步骤中，也会根据运行环境是否开启了安全生产模式，会有不同的处理方式。和正常模型发布是否开启安全生产处理流程一致

2.6.1 非安全生产

在未开启安全生产的场景下，修复环节不会返回 DDL 脚本，因此用户不需要手动执行修复脚本，DS 服务会自动执行，用户直接看到修复结果。

2.6.2 安全生产

如【修复SQL脚本（每个页签代表一个数据源）】下展示的内容。

在开启了安全生产模式的情况下，当前修复步骤页面中会展示需要用户手动执行的修复 DDL 和与之对应的回滚 DDL，两者是一一对应，当我们在执行左侧 DDL 脚本过程中出现执行失败的情况，我们需要将发生执行失败的那条 DDL 之前的已经成功执行的所有 DDL 记录下来，并且按照序号找到与之对应的回滚 DDL，重新执行一次回滚 DDL 脚本，用于还原现场。注意：回滚 DDL 的执行顺序应该是与左侧执行 DDL 相反。

在开启分库场景下，依然是以 Tab 页签形式展示每个数据源下需要执行的修复脚本。未开启分库场景下，则只有一个数据源页签 trantor_default，如上图中所示。

用户需要复制每个数据源中的脚本进入对应数据源环境中执行 DDL 脚本，当执行完所有数据源脚本后，我们还需要点击右上角的【执行修复】按钮才能真正完成本次修复。

2.7 修复完成

正常完成整个流程后，则完成了DS元信息和表结构，MS和DS元信息三者的一致性修复。