DM (Data Migration) 使用 sharding DDL lock 来确保分库分表的 DDL 操作可以正确执行。绝大多数情况下,该锁定机制可自动完成;但在部分异常情况发生时,需要使用 shard-ddl-lock
手动处理异常的 DDL lock。
注意
shard-ddl-lock unlock
命令,除非完全明确当前场景下使用这些命令可能会造成的影响,并能接受这些影响。shard-ddl-lock
该命令用于查看 DDL lock 和主动请求 DM-master 解除指定的 DDL lock。命令仅在 DM v6.0 及其以后版本支持, 之前版本可使用 show-ddl-locks
和 unlock-ddl-lock
命令。
shard-ddl-lock -h
maintain or show shard-ddl locks information Usage: dmctl shard-ddl-lock [task] [flags] dmctl shard-ddl-lock [command] Available Commands: unlock Unlock un-resolved DDL locks forcely Flags: -h, --help help for shard-ddl-lock Global Flags: -s, --source strings MySQL Source ID. Use "dmctl shard-ddl-lock [command] --help" for more information about a command.
参数解释
shard-ddl-lock [task] [flags]
:
shard-ddl-lock [command]
command
只支持 unlock
shard-ddl-lock [task] [flags]
使用 shard-ddl-lock [task] [flags]
命令,查询当前 DM-master 上存在的 DDL lock 信息。
例如:
shard-ddl-lock test
期望输出
shard-ddl-lock unlock
用于主动请求 DM-master 解除指定的 DDL lock,包括的操作:请求 owner 执行 DDL 操作,请求其他非 owner 的 DM-worker 跳过 DDL 操作,移除 DM-master 上的 lock 信息。
注意
shard-ddl-lock unlock
当前仅对悲观协调模式 (pessimistic
) 下产生的 lock 有效。
shard-ddl-lock unlock -h
Unlock un-resolved DDL locks forcely Usage: dmctl shard-ddl-lock unlock
shard-ddl-lock unlock
命令支持以下参数:
-o, --owner
:
shard-ddl-lock
返回结果中的 owner
)执行 DDL 操作;指定时,请求该 MySQL source(替代默认的 owner)执行 DDL 操作-f, --force-remove
:
lock-id
:
shard-ddl-lock
返回结果中的 ID
)以下是一个使用 shard-ddl-lock unlock
命令的示例:
shard-ddl-lock unlock test-`shard_db`.`shard_table`
{ "result": true, # unlock lock 操作是否成功 "msg": "", # unlock lock 操作失败时的原因 }
目前,使用 shard-ddl-lock unlock
命令仅支持处理以下两种 sharding DDL lock 异常情况。
Lock 异常原因
在 DM-master 尝试自动 unlock sharding DDL lock 之前,需要等待所有 MySQL source 的 sharding DDL events 全部到达(详见分库分表合并迁移原理)。如果 sharding DDL 已经在迁移过程中,同时有部分 MySQL source 被移除,且不再计划重新加载它们(按业务需求移除了这部分 MySQL source),则会由于永远无法等齐所有的 DDL 而造成 lock 无法自动 unlock。
手动处理示例
假设上游有 MySQL-1(mysql-replica-01
)和 MySQL-2(mysql-replica-02
)两个实例,其中 MySQL-1 中有 shard_db_1
.shard_table_1
和 shard_db_1
.shard_table_2
两个表,MySQL-2 中有 shard_db_2
.shard_table_1
和 shard_db_2
.shard_table_2
两个表。现在需要将这 4 个表合并后迁移到下游 TiDB 的 shard_db
.shard_table
表中。
初始表结构如下:
SHOW CREATE TABLE shard_db_1.shard_table_1;
+---------------+------------------------------------------+ | Table | Create Table | +---------------+------------------------------------------+ | shard_table_1 | CREATE TABLE `shard_table_1` ( `c1` int(11) NOT NULL, PRIMARY KEY (`c1`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +---------------+------------------------------------------+
上游分表将执行以下 DDL 语句变更表结构:
ALTER TABLE shard_db_*.shard_table_* ADD COLUMN c2 INT;
MySQL 及 DM 操作与处理流程如下:
mysql-replica-01
对应的两个分表执行了对应的 DDL 操作进行表结构变更。
ALTER TABLE shard_db_1.shard_table_1 ADD COLUMN c2 INT;
ALTER TABLE shard_db_1.shard_table_2 ADD COLUMN c2 INT;
DM-worker 接受到 mysql-replica-01
两个分表的 DDL 之后,将对应的 DDL 信息发送给 DM-master,DM-master 创建相应的 DDL lock。
使用 shard-ddl-lock
查看当前的 DDL lock 信息。
shard-ddl-lock test
{ "result": true, "msg": "", "locks": [ { "ID": "test-`shard_db`.`shard_table`", "task": "test", "mode": "pessimistic" "owner": "mysql-replica-01", "DDLs": [ "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" ], "synced": [ "mysql-replica-01" ], "unsynced": [ "mysql-replica-02" ] } ] }
由于业务需要,mysql-replica-02
对应的数据不再需要迁移到下游 TiDB,对 mysql-replica-02
执行了移除操作。
DM-master 上 ID 为 test-`shard_db`.`shard_table`
的 lock 无法等到 mysql-replica-02
的 DDL 操作信息。
shard-ddl-lock
返回的 unsynced
中一直包含 mysql-replica-02
的信息。
使用 shard-ddl-lock unlock
来请求 DM-master 主动 unlock 该 DDL lock。
如果 DDL lock 的 owner 也已经被移除,可以使用 --owner
参数指定其他 MySQL source 作为新 owner 来执行 DDL。
当存在任意 MySQL source 报错时,result
将为 false
,此时请仔细检查各 MySQL source 的错误是否是预期可接受的。
shard-ddl-lock unlock test-`shard_db`.`shard_table`
{ "result": true, "msg": ""
使用 shard-ddl-lock
确认 DDL lock 是否被成功 unlock。
shard-ddl-lock test
{ "result": true, "msg": "no DDL lock exists", "locks": [ ] }
查看下游 TiDB 中的表结构是否变更成功。
SHOW CREATE TABLE shard_db.shard_table;
+-------------+--------------------------------------------------+ | Table | Create Table | +-------------+--------------------------------------------------+ | shard_table | CREATE TABLE `shard_table` ( `c1` int(11) NOT NULL, `c2` int(11) DEFAULT NULL, PRIMARY KEY (`c1`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin | +-------------+--------------------------------------------------+
使用 query-status
确认迁移任务是否正常。
手动处理后的影响
使用 shard-ddl-lock unlock
手动执行 unlock 操作后,由于该任务的配置信息中仍然包含了已下线的 MySQL source,如果不进行处理,则当下次 sharding DDL 到达时,仍会出现 lock 无法自动完成迁移的情况。
因此,在手动解锁 DDL lock 后,需要再执行以下操作:
stop-task
停止运行中的任务。start-task
及新任务配置文件重新启动任务。注意
在 shard-ddl-lock unlock
之后,如果已下线的 MySQL source 重新加载并尝试对其中的分表进行数据迁移,则会由于数据与下游的表结构不匹配而发生错误。
Lock 异常原因
在 DM-master 收到所有 DM-worker 的 DDL 信息后,执行自动 unlock DDL lock 的操作主要包括以下步骤:
上述 unlock DDL lock 的操作不是原子的。如果非 owner 跳过 DDL 操作成功后,所在的 DM-worker 异常停止或与下游 TiDB 发生网络异常,造成无法成功更新 checkpoint。
当非 owner 对应的 MySQL source 恢复数据迁移时,会尝试请求 DM-master 重新协调异常发生前已经协调过的 DDL、且永远无法等到其他 MySQL source 的对应 DDL,造成该 DDL 操作对应 lock 的自动 unlock。
手动处理示例
仍然假设是 部分 MySQL source 被移除 示例中的上下游表结构及合表迁移需求。
当在 DM-master 自动执行 unlock 操作的过程中,owner(mysql-replica-01
)成功执行了 DDL 操作且开始继续进行后续迁移,但在请求非 owner(mysql-replica-02
)跳过 DDL 操作的过程中,由于对应的 DM-worker 发生了重启在跳过 DDL 后未能更新 checkpoint。
mysql-replica-02
对应的数据迁移子任务恢复后,将在 DM-master 上创建一个新的 lock,但其他 MySQL source 此时已经执行或跳过 DDL 操作并在进行后续迁移。
处理流程如下:
使用 shard-ddl-lock
确认 DM-master 上存在该 DDL 操作对应的 lock。
应该仅有 mysql-replica-02
处于 synced
状态:
shard-ddl-lock
{ "result": true, "msg": "", "locks": [ { "ID": "test-`shard_db`.`shard_table`", "task": "test", "mode": "pessimistic" "owner": "mysql-replica-02", "DDLs": [ "USE `shard_db`; ALTER TABLE `shard_db`.`shard_table` ADD COLUMN `c2` int(11);" ], "synced": [ "mysql-replica-02" ], "unsynced": [ "mysql-replica-01" ] } ] }
使用 shard-ddl-lock unlock
请求 DM-master unlock 该 lock。
Lock 过程中会尝试再次向下游执行该 DDL 操作(重启前的原 owner 已向下游执行过该 DDL 操作),需要确保该 DDL 操作可被多次执行。
shard-ddl-lock unlock test-`shard_db`.`shard_table`
{ "result": true, "msg": "", }
使用 shard-ddl-lock
确认 DDL lock 是否被成功 unlock。
使用 query-status
确认迁移任务是否正常。
手动处理后的影响
手动 unlock sharding DDL lock 后,后续的 sharding DDL 将可以自动正常迁移。