PingCAP
  • PingCAP University
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
PingCAP
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
  • PingCAP University

Contact

  • Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

English
文档
v3.0 (stable) dev v2.1
  • 关于 TiDB
    • TiDB 简介
    • Benchmark 测试
      • 如何用 Sysbench 测试 TiDB
      • 如何对 TiDB 进行 TPC-C 测试
      • Sysbench 性能对比 - v3.0 对比 v2.1
      • TPC-C 性能对比 - v3.0 对比 v2.1
      • 线上负载与 `Add Index` 相互影响测试
      • TiDB in Kubernetes Sysbench 性能测试
      • DM 1.0-GA 性能测试
  • 主要概念
    • 整体架构
    • 核心特性
      • 水平扩展
      • 高可用
  • 操作指南
    • 快速上手
      • 创建集群
        • 使用 Docker Compose 部署 TiDB 集群
      • SQL 基本操作
      • 读取历史数据
      • TiDB Binlog 教程
      • TiDB Data Migration 教程
      • TiDB Lightning 教程
      • TiSpark 教程
    • 部署
      • 软硬件环境需求
      • 集群部署方式
        • 使用 Ansible 部署(推荐)
        • 使用 Ansible 离线部署
        • 使用 Docker 部署
      • 跨地域冗余
        • 跨数据中心部署方案
        • 配置集群拓扑
      • 使用 Ansible 部署 DM 集群
    • 配置
      • 时区
      • 内存控制
    • 安全
      • 安全传输层协议 (TLS)
        • 为 MySQL 客户端开启 TLS
        • 为 TiDB 组件间开启 TLS
      • 生成自签名证书
    • 监控
      • 概述
      • 监控 TiDB 集群
    • 迁移
      • 概述
      • 从 MySQL 迁移
        • 全量迁移
        • 增量复制
      • 从 Amazon Aurora MySQL 迁移数据
      • 从 CSV 迁移
    • 运维
      • Ansible 常见运维操作
      • 备份与恢复
      • 定位慢查询
    • 扩容缩容
      • 使用 Ansible 扩容缩容
    • 升级
      • 升级至 TiDB 3.0
    • 故障诊断
      • 集群配置诊断
      • TiDB Lightning 故障诊断
  • 参考手册
    • SQL
      • 与 MySQL 兼容性对比
      • SQL 语言结构
        • 字面值
        • Schema 对象名
        • 关键字和保留字
        • 用户自定义变量
        • 表达式语法
        • 注释语法
      • 数据类型
        • 概述
        • 默认值
        • 数值类型
          • `BIT`
          • `BOOL|BOOLEAN`
          • `TINYINT`
          • `SMALLINT`
          • `MEDIUMINT`
          • `INT|INTEGER`
          • `BIGINT`
          • `DECIMAL`
          • `FLOAT`
          • `DOUBLE`
        • 日期和时间类型
          • `DATE`
          • `DATETIME`
          • `TIMESTAMP`
          • `TIME`
          • `YEAR`
        • 字符串类型
          • `CHAR`
          • `VARCHAR`
          • `TEXT`
          • `LONGTEXT`
          • `BINARY`
          • `VARBINARY`
          • `TINYBLOB`
          • `BLOB`
          • `MEDIUMBLOB`
          • `LONGBLOB`
          • `ENUM`
          • `SET`
        • JSON Type
      • 函数与操作符
        • 函数与操作符概述
        • 表达式求值的类型转换
        • 操作符
        • 控制流程函数
        • 字符串函数
        • 数值函数与操作符
        • 日期和时间函数
        • 位函数和操作符
        • Cast 函数和操作符
        • 加密和压缩函数
        • 信息函数
        • JSON 函数
        • GROUP BY 聚合函数
        • 窗口函数
        • 其它函数
        • 精度数学
        • 下推到 TiKV 的表达式列表
      • SQL 语句
        • `ADD COLUMN`
        • `ADD INDEX`
        • `ADMIN`
        • `ALTER DATABASE`
        • `ALTER TABLE`
        • `ALTER USER`
        • `ANALYZE TABLE`
        • `BEGIN`
        • `COMMIT`
        • `CREATE DATABASE`
        • `CREATE INDEX`
        • `CREATE TABLE LIKE`
        • `CREATE TABLE`
        • `CREATE USER`
        • `CREATE VIEW`
        • `DEALLOCATE`
        • `DELETE`
        • `DESC`
        • `DESCRIBE`
        • `DO`
        • `DROP COLUMN`
        • `DROP DATABASE`
        • `DROP INDEX`
        • `DROP TABLE`
        • `DROP USER`
        • `DROP VIEW`
        • `EXECUTE`
        • `EXPLAIN ANALYZE`
        • `EXPLAIN`
        • `FLUSH PRIVILEGES`
        • `FLUSH STATUS`
        • `FLUSH TABLES`
        • `GRANT <privileges>`
        • `INSERT`
        • `KILL [TIDB]`
        • `LOAD DATA`
        • `MODIFY COLUMN`
        • `PREPARE`
        • `RECOVER TABLE`
        • `RENAME INDEX`
        • `RENAME TABLE`
        • `REPLACE`
        • `REVOKE <privileges>`
        • `ROLLBACK`
        • `SELECT`
        • `SET [NAMES|CHARACTER SET]`
        • `SET PASSWORD`
        • `SET TRANSACTION`
        • `SET [GLOBAL|SESSION] <variable>`
        • `SHOW CHARACTER SET`
        • `SHOW COLLATION`
        • `SHOW [FULL] COLUMNS FROM`
        • `SHOW CREATE TABLE`
        • `SHOW CREATE USER`
        • `SHOW DATABASES`
        • `SHOW ENGINES`
        • `SHOW ERRORS`
        • `SHOW [FULL] FIELDS FROM`
        • `SHOW GRANTS`
        • `SHOW INDEXES [FROM|IN]`
        • `SHOW INDEX [FROM|IN]`
        • `SHOW KEYS [FROM|IN]`
        • `SHOW PRIVILEGES`
        • `SHOW [FULL] PROCESSSLIST`
        • `SHOW SCHEMAS`
        • `SHOW [FULL] TABLES`
        • `SHOW TABLE REGIONS`
        • `SHOW TABLE STATUS`
        • `SHOW [GLOBAL|SESSION] VARIABLES`
        • `SHOW WARNINGS`
        • `SPLIT REGION`
        • `START TRANSACTION`
        • `TRACE`
        • `TRUNCATE`
        • `UPDATE`
        • `USE`
      • 约束
      • 生成列
      • 分区表
      • 字符集
      • SQL 模式
      • 视图
    • 配置
      • tidb-server
        • MySQL 系统变量
        • TiDB 特定系统变量
        • 配置参数
        • 配置文件描述
      • pd-server
        • 配置参数
        • 配置文件描述
      • tikv-server
        • 配置参数
        • 配置文件描述
    • 安全
      • 与 MySQL 的安全特性差异
      • TiDB 数据库权限管理
      • TiDB 用户账户管理
      • 基于角色的访问控制
    • 事务
      • 事务语句
      • 事务模型
      • 隔离级别
      • 悲观事务
    • 系统数据库
      • `mysql`
      • `information_schema`
    • 错误码
    • 支持的连接器和 API
    • 垃圾回收 (GC)
      • GC 机制简介
      • GC 配置
    • 性能调优
      • SQL 优化流程
      • 理解 TiDB 执行计划
      • 执行计划绑定
      • 统计信息概述
      • Optimizer Hints
      • 使用 SQL 语句检查 TiDB 集群状态
      • Statement Summary Table
      • TiKV 调优
      • TiDB 最佳实践
    • 监控指标
      • Overview 面板
      • TiDB 面板
      • PD 面板
      • TiKV 面板
    • 报警规则
    • 最佳实践
      • HAProxy 最佳实践
      • Java 应用开发最佳实践
      • 高并发写入场景最佳实践
      • Grafana 监控最佳实践
      • PD 调度策略最佳实践
      • 海量 Region 集群调优最佳实践
      • 乐观锁事务最佳实践
    • TiSpark 使用指南
    • TiDB Binlog
      • 概述
      • 部署使用
      • 运维管理
      • 版本升级
      • 监控告警
      • 增量恢复
      • Kafka 自定义开发
      • 故障诊断
        • 故障诊断
        • 常见错误修复
      • FAQ
    • 周边工具
      • Mydumper
      • Loader
      • Syncer
      • Data Migration
        • 概述
          • DM 架构
          • 同步功能介绍
          • 使用限制
          • DM-worker 简介
          • DM Relay Log
        • 核心特性
          • Table Routing
          • Black & White Lists
          • Binlog Event Filter
          • 同步延迟监控
          • Shard Support
            • 简介
            • 使用限制
            • 手动处理 Sharding DDL Lock
        • 使用场景
          • 简单的从库同步场景
          • 分库分表合并场景
          • 分表合并数据迁移最佳实践
          • DM-worker 在上游 MySQL 主从间切换
        • 部署使用
        • 配置
          • 概述
          • DM-master 配置
          • DM-worker 配置
          • 任务配置
        • DM 集群管理
          • 集群操作
          • 集群升级
        • DM 同步任务管理
          • 管理数据同步任务
          • 任务前置检查
          • 任务状态查询
          • 跳过或替代执行异常的 SQL 语句
        • 监控 DM 集群
        • 从与 MySQL 兼容的数据库迁移数据
          • 从 Amazon Aurora MySQL 迁移数据
        • DM Portal
        • DM 故障诊断
          • 故障诊断
          • 错误含义
          • 常见错误修复
        • DM FAQ
        • 版本发布历史
          • v1.0
            • 1.0.2
        • TiDB DM 术语表
      • TiDB Lightning
        • 概述
        • 部署执行
        • 断点续传
        • 表库过滤
        • CSV 支持
        • 监控告警
        • 故障诊断
        • FAQ
      • sync-diff-inspector
      • PD Control
      • PD Recover
      • TiKV Control
      • TiDB Controller
      • 工具下载
  • TiDB in Kubernetes
    • TiDB Operator 简介
    • 快速上手
      • kind
      • GKE
      • Minikube
    • 部署
      • 集群环境要求
      • 部署 TiDB Operator
      • 标准 Kubernetes 上的 TiDB 集群
      • AWS EKS 上的 TiDB 集群
      • GCP 上的 TiDB 集群
      • 阿里云上的 TiDB 集群
      • 访问 Kubernetes 上的 TiDB 集群
    • 配置
      • 初始化集群
    • 监控
    • 运维
      • 销毁 TiDB 集群
      • 维护 TiDB 集群所在节点
      • 备份与恢复
      • 恢复 Kubernetes 上的 TiDB 集群数据
      • 收集日志
      • 集群故障自动转移
      • TiDB Binlog
    • 扩缩容
    • 升级
      • TiDB 集群
      • TiDB Operator
    • 参考信息
      • 配置
        • 集群配置
        • 备份配置
        • PV 配置
        • TiDB Drainer
      • 工具
        • tkctl
        • 相关工具使用
    • 故障诊断
    • 常见问题
  • 常见问题 (FAQ)
    • TiDB FAQ
    • TiDB Lightning FAQ
    • 升级 FAQ
  • 技术支持
    • 支持渠道
    • 反馈问题
  • 贡献
    • 贡献代码
    • 改进文档
  • TiDB 路线图
  • 版本发布历史
    • v3.0
      • 3.0.7
      • 3.0.6
      • 3.0.5
      • 3.0.4
      • 3.0.3
      • 3.0.2
      • 3.0.1
      • 3.0 GA
      • 3.0.0-rc.3
      • 3.0.0-rc.2
      • 3.0.0-rc.1
      • 3.0.0-beta.1
      • 3.0.0-beta
    • v2.1
      • 2.1.18
      • 2.1.17
      • 2.1.16
      • 2.1.15
      • 2.1.14
      • 2.1.13
      • 2.1.12
      • 2.1.11
      • 2.1.10
      • 2.1.9
      • 2.1.8
      • 2.1.7
      • 2.1.6
      • 2.1.5
      • 2.1.4
      • 2.1.3
      • 2.1.2
      • 2.1.1
      • 2.1 GA
      • 2.1 RC5
      • 2.1 RC4
      • 2.1 RC3
      • 2.1 RC2
      • 2.1 RC1
      • 2.1 Beta
    • v2.0
      • 2.0.11
      • 2.0.10
      • 2.0.9
      • 2.0.8
      • 2.0.7
      • 2.0.6
      • 2.0.5
      • 2.0.4
      • 2.0.3
      • 2.0.2
      • 2.0.1
      • 2.0
      • 2.0 RC5
      • 2.0 RC4
      • 2.0 RC3
      • 2.0 RC1
      • 1.1 Beta
      • 1.1 Alpha
    • v1.0
      • 1.0
      • Pre-GA
      • RC4
      • RC3
      • RC2
      • RC1
  • 术语表

分表合并数据迁移最佳实践

本文阐述了使用 TiDB Data Migration(以下简称 DM)对分库分表进行合并迁移的场景中,DM 相关功能的支持和限制,旨在给出一个业务的最佳实践。

独立的数据迁移任务

在分库分表合并同步的实现原理部分,我们介绍了 sharding group 的概念,简单来说可以理解为需要合并到下游同一个表的所有上游表即组成一个 sharding group。

当前的 sharding DDL 算法为了能协调在不同分表执行 DDL 对 schema 变更的影响,加入了一些使用限制。而当这些使用限制由于某些异常原因被打破时,我们需要手动处理 Sharding DDL Lock 甚至是完整重做整个数据迁移任务。

因此,为了减小异常发生时对数据迁移的影响,我们推荐将每一个 sharding group 拆分成一个独立的数据迁移任务。这样当异常发生时,可能只有少部分迁移任务需要进行手动处理,其他数据迁移任务可以不受影响。

手动处理 sharding DDL lock

从分库分表合并同步的实现原理部分我们可以知道,DM 中的 sharding DDL lock 是用于协调不同上游分表向下游执行 DDL 的一种机制,本身并不是异常。

因此,当通过 show-ddl-locks 查看到 DM-master 上存在 sharding DDL lock 时,或通过 query-status 查看到某些 DM-worker 有 unresolvedGroups 或 blockingDDLs 时,并不要急于使用 unlock-ddl-lock 或 break-ddl-lock 尝试去手动解除 sharding DDL lock。

只有在确认当前未能自动解除 sharding DDL lock 是文档中所列的支持场景之一时,才能参照对应支持场景中的手动处理示例进行处理。对于其他未被支持的场景,我们建议完整重做整个数据迁移任务,即清空下游数据库中的数据以及该数据迁移任务相关的 dm_meta 信息后,重新执行全量数据及增量数据的迁移。

自增主键冲突处理

在 DM 中,我们提供了 Column mapping 用于处理 bigint 类型的自增主键在合并时可能出现冲突的问题,但我们强烈不推荐使用该功能。如果业务上允许,我们推荐使用以下两种处理方式。

去掉自增主键的主键属性

假设上游分表的表结构如下:

CREATE TABLE `tbl_no_pk` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uk_c2` bigint(20) NOT NULL,
  `content_c3` text,
  PRIMARY KEY (`auto_pk_c1`),
  UNIQUE KEY `uk_c2` (`uk_c2`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

如果满足下列条件:

  • auto_pk_c1 列对业务无意义,且不依赖该列的 PRIMARY KEY 属性。
  • uk_c2 列有 UNIQUE KEY 属性,且能保证在所有上游分表间全局唯一。

则可以用以下步骤处理合表时可能由 auto_pk_c1 导致的 ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY' 问题:

  1. 在开始执行全量数据迁移前,在下游数据库创建用于合表迁移的表,但将 auto_pk_c1 的 PRIMARY KEY 属性修改为普通索引。

    CREATE TABLE `tbl_no_pk_2` (
      `auto_pk_c1` bigint(20) NOT NULL,
      `uk_c2` bigint(20) NOT NULL,
      `content_c3` text,
      INDEX (`auto_pk_c1`),
      UNIQUE KEY `uk_c2` (`uk_c2`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  2. 启动数据迁移任务,执行全量与增量数据迁移。

  3. 通过 query-status 验证数据迁移任务是否正常,在下游数据库中验证合表中是否已经存在了来自上游的数据。

使用联合主键

假设上游分表的表结构如下:

CREATE TABLE `tbl_multi_pk` (
  `auto_pk_c1` bigint(20) NOT NULL,
  `uuid_c2` bigint(20) NOT NULL,
  `content_c3` text,
  PRIMARY KEY (`auto_pk_c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

如果满足下列条件:

  • 业务不依赖 auto_pk_c1 的 PRIMARY KEY 属性。
  • auto_pk_c1 与 uuid_c2 的组合能确保全局唯一。
  • 业务能接受将 auto_pk_c1 与 uuid_c2 组成联合 PRIMARY KEY。

则可以用以下步骤处理合表时可能由 auto_pk_c1 导致的 ERROR 1062 (23000): Duplicate entry '***' for key 'PRIMARY' 问题:

  1. 在开始执行全量数据迁移前,在下游数据库创建用于合表迁移的表,但不为 auto_pk_c1 指定 PRIMARY KEY 属性,而是将 auto_pk_c1 与 uuid_c2 一起组成 PRIMARY KEY。

    CREATE TABLE `tbl_multi_pk_c2` (
      `auto_pk_c1` bigint(20) NOT NULL,
      `uuid_c2` bigint(20) NOT NULL,
      `content_c3` text,
      PRIMARY KEY (`auto_pk_c1`,`uuid_c2`)
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1
  2. 启动数据迁移任务,执行全量与增量数据迁移。

  3. 通过 query-status 验证数据迁移任务是否正常,在下游数据库中验证合表中是否已经存在了来自上游的数据。

合表迁移过程中在上游增/删表

从分库分表合并同步的实现原理部分我们可以知道,sharding DDL lock 的协调依赖于是否已收到上游已有各分表对应的 DDL,且当前 DM 在合表迁移过程中暂时不支持在上游动态增加或删除分表。如果需要在合表迁移过程中,对上游执行增、删分表操作,推荐按以下方式进行处理。

在上游增加分表

如果需要在上游增加新的分表,推荐按以下顺序执行操作:

  1. 等待在上游分表上执行过的所有 sharding DDL 协调同步完成。
  2. 通过 stop-task 停止任务。
  3. 在上游添加新的分表。
  4. 确保 task.yaml 配置能使新添加的分表与其他已有的分表能合并到同一个下游表。
  5. 通过 start-task 启动任务。
  6. 通过 query-status 验证数据迁移任务是否正常,在下游数据库中验证合表中是否已经存在了来自上游的数据。

在上游删除分表

如果需要在上游删除原有的分表,推荐按以下顺序执行操作:

  1. 在上游删除原有的分表,并通过 SHOW BINLOG EVENTS 获取该 DROP TABLE 语句在 binlog 中对应的 End_log_pos,记为 _Pos-M_。
  2. 通过 query-status 获取当前 DM 已经处理完成的 binlog event 对应的 position(syncerBinlog),记为 _Pos-S_。
  3. 当 Pos-S 比 Pos-M 更大后,则说明 DM 已经处理完 DROP TABLE 语句,且该表在被删除前的数据都已经同步到下游,可以进行后续操作;否则,继续等待 DM 进行数据同步。
  4. 通过 stop-task 停止任务。
  5. 确保 task.yaml 配置能忽略上游已删除的分表。
  6. 通过 start-task 启动任务。
  7. 通过 query-status 验证数据迁移任务是否正常。

数据迁移限速/流控

当将多个上游 MySQL/MariaDB 实例的数据合并迁移到下游同一个 TiDB 集群时,由于每个与上游 MySQL/MariaDB 对应的 DM-worker 都会并发地进行全量与增量数据迁移,默认的并发度(全量阶段的 pool-size 与增量阶段的 worker-count)通过多个 DM-worker 累加后,可能会给下游造成过大的压力,此时应根据 TiDB 监控及 DM 监控进行初步的性能分析后,适当地调整各并发度参数的大小。后续 DM 也将考虑支持部分自动的流控策略。

"分表合并数据迁移最佳实践" 更新于 Sep 30 2019: tools: remove column mapping in DM (#1899) (e2d671a)
修改本文 反馈文档问题

本页导航

产品

  • TiDB
  • TiSpark
  • TiDB 路线图

文档

  • 快速入门
  • 最佳实践
  • 常见问题解答
  • TiDB 周边工具
  • 版本发布说明

资源

  • 博客
  • GitHub
  • 知乎专栏
  • PingCAP University
  • 联合解决方案
  • Ask TUG

公司

  • 关于我们
  • 招贤纳士
  • 新闻报道

联系我们

  • Twitter
  • LinkedIn
  • Reddit
  • Google Group
  • Stack Overflow
  • 微信公众号
    Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

© 2019 北京平凯星辰科技发展有限公司

English