上一章：DTS数据迁移 | 《DTS控制台入门一本通》第三章（上篇）
下一篇：DTS数据订阅 | 《DTS控制台入门一本通》第四章
也可以PC端点击https://developer.aliyun.com/topic/download?id=803 下载
3.4任务列表
图 3-1 标记③的处为所选择地域的任务列表。包括了预检查中、失败、迁移中、 暂停、完成等各个状态的任务，具体功能如下。
3.4.1 ID/ 名称
显示 DTS 任务的 ID 以及名称，点击这个超链接后，进入任务详情页面，如下 图 3-23。
3.4.1.1 任务配置
该页面展示了任务的详细配置信息，包括源端与目标端的配置信息。如果迁移任 务使用的源端和目标端的数据库账户的密码更改导致 DTS 任务异常，可以点击“修 改原 / 目标实例密码”进行订正。修改密码需要使用旧密码（如果您旧密码忘记无法 修改，此时需要重建任务）。如下图 3-24。
3.4.1.2 迁移详情
此功能展示了 DTS 迁移过程中各个环节的迁移状态，详细说明如下。
3.4.1.2.1 结构迁移
如下图 3-25，展示了结构迁移页面迁移的数据库结构的信息（此处只展示了 tables、views、functions、procedures）。如果结构迁移时迁移的数据库对象有异 常，会在“状态”列显示。点击“查看创建语法”可以查看 DTS 是以何种 SQL 语 句在目标端创建对象结构的。您也可以自行创建目标数据库的表结构信息，不使用 DTS 进行结构迁移（如果您目标数据库已经有对应的表结构了，在“3.3.10 迁移类 型”选择时，无需选择结构迁移）。
结构迁移部分失败分为 2 点：
● DTS 通过 SQL 语句在源端数据库获取数据库对象的相关信息时异常，如 下图 3-26 的例子就是 DTS 通过 SELECT 语句在源端执行 SQL 时，出现 Unknown error 的错误。这个图里有 2 个关键的信息，其中“err msg”指 的是 SQL 语句执行时的错误信息（此处为 Unknown error）。“sqls”指的是 DTS 在源端执行哪一个 SQL 查询哪一个对象时出现了 Unknow error( 此 处 是 select routine_schema,routine_name….. from information_ schema.ROUTINES where… 和 select parameter_mode,parameter_ name… from information_schema.PARAMETERS WHERE specific_ schema=? and …)。判断这个问题的原因可以拿这两个 SQL 在源端数据库 执行复现问题，确认 Unknown error 的原因。
● DTS 通过源端数据库获取到对象的相关信息后，DTS 内部会组合成 DDL 语 句在目标端数据库进行执行。当 DTS 把这些 DDL 语句在目标端执行时异常。 如下图 3-27 的例子就是 DTS 在目标执行 DDL 时出现了异常。这个错误比较 简单，指的是 DTS 在目标端数据库创建表时，提示表已存在。要解决这个问 题，需要去目标端查看下，是否有对应的表以及存在。根据错误，找解决方案。
3.4.1.2.2 全量迁移
如下图 3-28，是结构迁移部分顺利运行完成后，进行全量迁移的展示页面。
为什么结构迁移在前？因为只有先创建表，才能往目标实例写数据。全量迁移要 从源端抽取数据然后把数据写入目标端，这会导致源端与目标端数据库实例的负 载（CPU,IOPS 等）增加，因为全量迁移的是源端数据库表里已经存在的数据（这 些数据可能是历史数据，早已经写入，也可能刚刚写入不久的数据，非未来新增的 数据）。
与结构迁移相同的是全量迁移出现问题也分为 2 点：
● DTS 通过 SQL 语句（一般是 SELECT）在源端数据库获取数据库表的数据的 时候异常。如下图 3-29 就是在源端使用 SELECT 抽取数据时，由于 MAX_ ALLOW_PACKET 参数设置过小导致数据查询异常。您可以通过调整参数的 大小来解决该问题，如果参数已经调到最大后依然无法避免这种情况，请反馈 阿里云售后。
● DTS 通过源端数据库获取到的数据库数据，DTS 内部会组合成 DML 语句（INSERT、UPDATE、DELETE 等）在目标端数据库进行执行。当 DTS 把这些 DML 语句在目标端执行时异常。如下图 3-30 是指 DTS 在把数据写入 目标端数据库时，提示表不存在。遇到该问题，需要在目标端数据库查看数据 库的表是否正常可写入以及 DTS 目标端的数据库账户权限是否正常。
3.4.1.2.3 增量迁移
如下图 3-31，是 DTS 进行增量时的对象展示页面。此处可以看到有一个“待 修复”标识，说明在增量环节出现了异常，需要修复。具体的异常和修复方案，我 们会在“3.4.2 查看原因并修复”章节详细说明。增量迁移不会导致源端数据库的 负载有明细增加。由于要把增量数据写入目标端，目标端数据库实例的负载可能会 增加。
再次强调下，dts 的增量迁移的实现方法，大多和数据库本身的复制功能相关，借助的是源端数据库的一些日志来实现，以 mysql 为例，dts 借助的是 binlog，dts启动增量的时候，会在源端启动一个 binlog dump 进程，源端实例会推送 binlog 的 记录给 dts，dts 解析这些记录，然后在目标实例应用，实现增量同步。
同时，DTS 的增量数据迁移延迟是无法保证的，正常情况下 DTS 的增量迁移是 秒级延迟，但是当遇到一些 DDL、大量更新时或者 DTS 规格达到瓶颈等情况时，增 量数据迁移延迟会增高。如果您遇到大的延迟（比如超过 1000S），可与阿里云售后 反馈。
3.4.1.3 性能监控
该功能展示了全量和增量迁移阶段，DTS任务的迁移性能，详细说明如下。
3.4.1.3.1 全量迁移性能
前面我们讨论过，DTS 进行全量迁移，实际上就是在源端执行 SELECT 获取数 据，然后再把获取的数据写入到目标端的过程。如下图 3-32，“全量迁移链路拓扑” 形象的展示了这个过程，并且也展示了全量抽取与全量写入两个个环节的 BPS( 全量 迁移阶段 DTS 全量迁移服务的 IOPS，单位：Bytes/Second) 与 RPS( 全量迁移阶 段 DTS 全量迁移服务的记录数量，单位：Records/Second) 信息。同时“全量迁移 性能”部分也展示了全量迁移的四个关键指标以及“指标含义”：全量迁移流量，原、 目标实例 RPS，源库网络延迟、目标库网络延迟，源库 SQL 执行 RT、目标库 SQL 执行 RT。
3.4.1.3.2 全量迁移慢的定位与处理
在“3.4.1.3.1 全量迁移性能”章节了解了全量迁移的性能指标，本章节讨论 下遇到全量迁移慢如何分析定位与处理。全量迁移慢分为 3 个部分：源端抽取慢、 DTS 服务本身对数据处理慢、目标端写入慢。
● 源端抽取慢：要判断这一点，首先要在源端查看 DTS 的会话状态，以 MySQL 为 例， 可 以 通 过 执 行 select * from information_schema.processlist 与 show processlist 获取，查到会话状态后有如下 3 种情况： ○ 没有 DTS 的任何会话，遇到这个情况，说明 DTS 与源端实例的链接可能存 在问题。 ○ DTS 的会话存在，但是状态全部是 sleep，遇到这个情况，说明 DTS 抽取 已经完成，或者 DTS 抽取存在异常。 ○ DTS 会话存在，部分会话在执行 query 获取数据，遇到这个情况，说明 DTS 正在抽取源端数据库的数据，状态正常 , 您需要关注下源端数据库的负 载，避免出现性能瓶颈。
● DTS 服务本身对数据处理慢 : 因为 DTS 负责把源端数据库数据获取后写入到目 标端，DTS 服务本身的链路规格以及内存资源都可能会导致全量迁移慢的情况， 比较常见的是 DTS 内存较低导致在迁移大数据对象时频繁 OOM(DTS 的错误 表现是 Java heap space)，遇到这方面的问题，可以反馈阿里云售后核实。
● 目标写入慢：要判断这一点，同样需要在目标端查看 DTS 的会话状态，以 MySQL 为例，可以通过执行 select * from information_schema.processlist 与 show processlist 获取，查到会话状态后有如下 3 种情况：
○ 没有任何的 DTS 会话在执行 DML 操作，说明 DTS 与目标实例的链接可能 存在问题。
○ DTS 的会话存在，但是状态全部是 sleep，遇到这个情况，说明 DTS 与目 标端数据库连通性正常，但是 DTS 无法在目标端执行 SQL。
○ DTS 会话存在，部分会话在执行 DML 写入数据，遇到这个情况，说明 DTS 状态正常。如果 DML 耗时太长，需要关注下阻塞，数据库负载等方面。
3.4.1.3.3 增量迁移性能
DTS 增量迁移分为 3 个阶段，如下图 3-33：
- DTS 通过数据库的日志，获取源端的新增数据（全量迁移之后的新增数据）， 这部分工作由 DTS 采集模块实现。
- DTS 拿到这些数据后，在 DTS 侧缓存起来，以便后面写入目标端数据库。 这部分工作由 DTS 缓存模块实现。
- DTS 获取缓存起来的增量数据，进行处理后把这些数据应用到目标端数据 库，这部分工作由 DTS 写入模块实现。
同样，增量迁移时，每个环节也都有性能指标。重点关注的指标是增量迁移的 RPS 和迁移延迟。增量抽取不会对源端的数据库性能产生大的影响。
3.4.1.3.4 增量迁移延迟的定位与处理
通过“3.4.1.3.3 增量迁移性能”章节说明了解了 DTS 增量迁移阶段的 3 个步
骤，当出现增量延迟的时候，也会出在这三个部分：DTS 采集模块获取源端增量日志
延迟、DTS 本身服务异常导致数据处理延迟、DTS 写入模块写入目标数据库延迟。
最长遇到问题的时采集延迟和写入延迟：
● DTS 采集模块获取源端增量日志延迟 : 这个主要出现在源端的日志缺失、日
志过大或者源端数据库链接异常时出现，以 MySQL 为例，如果手动清理掉了
DTS 还未获取的源端 binlog，此时 DTS 采集模块就会异常。还有如果源端的
binlog 单个文件特别大（比如大事务产生了 100G 的单个 binlog 文件），DTS
也可能存在拉取文件超时的情况，导致延迟。如果要判断增量采集模块是否有
异常或者延迟，以 MySQL 为例，DTS 是通过在源端建立一个 binlog dump
的会话实现的 binlog 的抽取，故可以通过执行 select * from information_
schema.processlist 与 show processlist 获取，查到会话状态后有如下 3 种情况：
○ binlog dump 进程不存在，说明 DTS 与源端数据库的连通性可能存在问题。
○ binlog dump 进程存在，且状态为 Master has sent all binlog to slave; waiting for more updates，如下图 3-34。如果是这种状态，可以基本说 明源端数据库的 binlog 已经全部发到了 DTS 侧。
○ binlog dump 进程存在，但是状态非 Master has sent all binlog to slave;waiting for more updates，可以说明源端数据库正在发送 binlog 文件给DTS，中间可能存在一些问题或者耗时较长。
● DTS 写入模块写入目标数据库延迟：如果 DTS 源端数据库抽取数据非常的及 时，那出现延迟很可能是在写入目标数据库的时候写入较慢或者并发不高导 致。遇到这类问题，主要排查如下 3 个方面。
○ 目标数据库的 IO、CPU 负载等资源是否正常，如果这些正常，可以排除性 能瓶颈。
○ 目标数据库的 SQL 执行状态是否正常，比如是否耗时较长或者遇到了阻 塞，以 MySQL 为例，可以通过执行 select * from information_schema. processlist 与 show processlist 获取会话的执行状态，查看 DML 语句的 执行情况与耗时，问题判断和分析与“3.4.1.3.2 全量迁移慢的定位与处 理”章节的“目标写入慢”部分相同。
3.4.1.4 监控报警
此功能用来监控 DTS 迁移任务的延迟与状态情况，如下图 3-35。DTS 迁移只 支持监控这两项，您可以设置这两项的报警接收的手机号。
DTS 的增量数据迁移延迟是无法保证的，正常情况下 DTS 的增量迁移是秒级 延迟，但是当遇到一些 DDL、大量更新时或者 DTS 规格达到瓶颈等情况时，增量 数据迁移延迟会增高。如果您遇到大的延迟（比如超过 1000S），可与阿里云售后 反馈。
3.4.2查看原因并修复
当 DTS 任务出现异常的时候，我们需要查看异常原因以及尝试修复它，从“3.4.1.2.3 增量迁移”章节可以看到，这个任务增量异常，我们要查看异常的原因，需要查看任务列表页面，如下图 3-35 和图 3-36。这里的迁移错误是因为 DTS 使用的源端账户缺少 SUPER 或者 REPLICATION CLIENT 权限导致增量异常。处理方法则是把账户的 REPLICATION CLIENT 权限加上然后重启任务即可。
3.4.3启动任务
当任务暂停，失败时，可以点击启动任务来启动。
3.4.4查看详情
查看详情功能与“3.4.1 ID/ 名称”功能相同。
3.4.5创建类似任务
该功能用来创建与当前 DTS 任务近似的新任务，点击后，会跳转新的创建页面，如下图 3-37。该功能不推荐使用，如果您需要创建新的任务，请点击“3.3 创建迁移任务页面”。
3.4.6升级
当 DTS 任务规格不足时，比如我们通过在“3.4.1.3 性能监控”章节讨论的性 能指标判断出迁移性能的瓶颈在 DTS，此时就需要升级 DTS 的任务规格。需要注意 如下 3 点：
● 如果您配置 DTS 任务时，没有选择增量，在任务配置时是不收费的，但是如 果点击升级 DTS 任务（无增量的 DTS 任务），则会产生费用，如下图 3-38。
● DTS 的规格现在还只能升级，不能降级。
● 不同的 DTS 数据迁移规格，性能不同，具体可以参考这里的测试结果：https://help.aliyun.com/document_detail/26606.html?spm=a2c4g.11186623.6.559.2ab2179776BAy8
3.4.7监控报警
该功能与“3.4.1.4 监控报警”功能相同。
3.4.8修改密码
该功能与“3.4.1.1 任务配置”的修改密码功能相同，修改密码只支持密码修改，账户不可修改。并且修改密码需要使用旧密码（如果您旧密码忘记无法修改，此时需要重建任务）。
3.4.9暂停任务
暂停任务一般可以用于当因为 DTS 的迁移操作导致源端数据库或者目标端数据 库负载消耗较大时，此时暂停任务来缓解数据库的压力（点击暂停后，请查看数据库 种 DTS 会话的状态，如果 DTS 会话长时间未结束可以考虑手动 KILL 掉未结束的会 话）。这是比较特殊的情况下的使用。 大多数情况下不推荐暂停任务（全量任务与增量任务都不推荐暂停），主要原因为 如下 2 点：
全量任务
因为全量迁移阶段，DTS 会对源端已存在的数据进行抽取，抽取这 些数据无法短时间内完成（数据量大时可能要经历好几个小时），如果我们在全 量任务阶段暂停了全量任务，然后又重启，全量数据的迁移会重新开始，比如 有 A、B、C、D 四个表要进行迁移，此时 A 表迁移完成，D 表还未开始迁移， 正在迁移 B 表（假设已经完成 70%）和 C 表（假设已经完成 30%），如果此时 暂停全量迁移，B 表和 C 表的源端数据库 SELECT 请求将会停止，除非您已 经放弃进行全量迁移，否则最终还是要重新启动全量任务的，如果再次启动全 量任务，DTS 会重新对 B 表和 C 表进行数据的迁移，也就是意味着前面的 B 表（假设已经完成 70%）和 C 表（假设已经完成 30%）已经迁移完成的这些数 据并不会续传（DTS 不支持续传）。这也就导致如下 2 个问题：
○ 如果 B 表和 C 表没有主键或者唯一键，数据可能会出现重复甚至是丢失等 不一致的情况。
○ 如果 B 表和 C 表有主键或者唯一键，DTS 在重新抽取源库的 B 表和 C 表 的数据写入目标端时，可能会出现主键冲突的情况，影响迁移效率。
增量迁移
对增量迁移来说，暂停任务比全量任务安全很多，但是也存在如下 3 点注意事项，这是重点：
● 增量迁移任务暂停时间过长，会导致增量失败。原因在于“3.4.1.3.3 增量迁移 性能”章节中我们讨论过，DTS 的增量迁移会有一个 DTS 缓存模块对源端数 据库的增量数据进行缓存。这个缓存模块的数据有效期为 7 天（大多数 DTS 任务都是 7 天，少量的 DTS 任务非 7 天）。当我们暂停 DTS 任务超过 7 天 时，DTS 增量任务会出现异常。比如我们在 2020 年 6 月 12 日 15:00:00 进 行了任务暂停 , 此时 DTS 采集模块不停止，一直实时的获取源端数据库的增 量数据（不会停止），然后这些增量数据由 DTS 缓存模块缓存，缓存的增量 DTS 写入模块暂停，停止写入，写入的数据最后一次时间点为 2020 年 6 月 12 日 15:00:00。随着时间的推移，我们在 2020 年 6 月 20 日 15:00:00 启 动 任 务， 由 于 2020 年 6 月 12 日 15:00:00~2020 年 6 月 20 日 15:00:00 期间，DTS 增量采集模块和缓存模块一直在工作，此时 DTS 增量采集模块采集的增量数据是最新的（2020 年 6 月 20 日 15:00:00 时间点的），而由于 DTS 缓存模块的增量数据只保存 7 天（不是所有 DTS 任务都是 7 天，请以 具体情况为准），此时 DTS 缓存模块里的增量的数据范围是 2020 年 6 月 13 日 15:00:00~2020 年 6 月 20 日 15:00:00。 但 是 由 于 2020 年 6 月 12 日 15:00:00 停止时，DTS 写入模块停止了写入，DTS 写入模块的写入时间点 依然在 2020 年 6 月 12 日 15:00:00，2020 年 6 月 20 日 15:00:00 启动后， DTS 写入模块继续写入去 DTS 缓存模块里寻找 2020 年 6 月 20 日 15:00:00 的数据，开始写入，由于 DTS 缓存模块里的增量数据已经变成了 2020 年 6 月 13 日 15:00:00~2020 年 6 月 20 日 15:00:00，此时 DTS 写入模块会失 败。DTS 整个任务也就会失败。遇到这种情况，解决办法有 3 个：
○ 如果源端数据库的相关增量数据的日志还存在（以 MySQL 为例，源端数据 库的 binlog 还一直存在并未删除），该问题的修复方案可以使 DTS 的采集 模块重新从 2020 年 6 月 12 日 15:00:00 采集增量数据，DTS 缓存模块重 新缓存 2020 年 6 月 12 日 15:00:00 的增量数据，这样 DTS 写入模块也就 可以正常从 2020 年 6 月 12 日 15:00:00 写入增量数据
○ 如果源端数据库的相关增量数据的日志已经不存在被删除，也可以选择放弃 2020 年 6 月 12 日 15:00:00~2020 年 6 月 13 日 15:00:00 的增量数据， 直接让 DTS 写入模块从 2020 年 6 月 13 日 15:00:00 开始写入，这会导致 数据不一致（2020 年 6 月 12 日 15:00:00~2020 年 6 月 13 日 15:00:00 的增量数据未迁移，产生了丢失），该操作非特殊情况不建议。
○ 如果源端数据库的相关增量数据的日志已经不存在被删除，且要保证数据 一致性。您可以重新进行一次 DTS 任务（重新进行结构 + 全量 + 增量的迁 移），保证数据一致性。
● DTS 迁移任务暂停后，由于 DTS 写入模块暂停，再次重新（7 天内）启动后 会产生延迟（因为要重新写入未写入的增量数据，追赶最新的增量数据），这个 延迟理论上是逐渐降低的。
3.4.10结束任务
使用该功能，有 4 种情况，分别是：
● DTS 未选择增量迁移，全量迁移或者结构迁移完成后，任务自动结束（此时不 需手动结束）
● DTS 未选择增量迁移，但是全量迁移或者结构迁移出现异常，该异常无法修 复，放弃该 DTS 任务时，可以手动结束该 DTS。
● DTS 选择了增量迁移，增量迁移一直在正常的同步增量数据，您选择在合适 的时间切换业务，停止增量迁移时，可以使用结束任务。
● DTS 选择了增量迁移，但是增量任务异常或者无法修复，您放弃该 DTS 任务 时，手动结束该 DTS。 无论哪一种情况，结束任务意味着完全放弃这个任务的所有已完成或者未完成的 任务环节，结束后无法恢复。
3.4.10释放任务
“3.4.10 结束任务”只是把任务状态由“运行中”、“暂停中”、“迁移失败”等改成“已完成”。任务信息依然在任务列表展示，如下图 3-40。要把该任务从任务列
表删除，则需要释放它。
