DM迁移polardb到TIDB

1.DM工具介绍

​ 从兼容MySQL协议的数据源，将数据(异步)迁移到TiDB中。支持全量和增量数据传输。可以数据过滤，可以将源端的分库分表数据合并迁移。

2.安装配置DM

2.1 下载DM

# 1. 下载并安装 TiUP工具
wget https://tiup-mirrors.pingcap.com/install.sh
sh install.sh
source .bash_profile
# 2. 部署 DM 集群
tiup install dm
# 3. 升级到最新版本
tiup update --self && tiup update dm  
# 4. tiup dm template > topology.yaml获取官方DM集群配置文件模板
复制

2.2 配置DM集群配置文件

vim  topology.yaml

# The topology template is used deploy a minimal DM cluster, which suitable
# for scenarios with only three machinescontains. The minimal cluster contains
# - 3 master nodes
# - 3 worker nodes
# You can change the hosts according your environment
---
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/home/tidb/dm/deploy"   
  data_dir: "/home/tidb/dm/data"  
  # arch: "amd64"

master_servers:
  - host: 172.16.200.243

worker_servers:
  - host: 172.16.201.108

复制

2.2.1 官方DM集群配置文档详解

https://docs.pingcap.com/zh/tidb/stable/tiup-dm-topology-reference
复制

2.3 启动DM集群

# 查询当前最新版本
tiup list dm-master
# 下载最新版本
tiup dm deploy dm-test v6.6.0 ./topology.yaml --user root -p
ps 1.这里尝试使用tidb用户去启动安装一直报错，摆烂了使用了root
ps 2.dm会去拿着后面输入的账号ssh到dm-worker节点安装
# 启动
tiup dm start dm-test
# 查看状态
tiup dm display dm-test
复制

2.4 安装DM管理工具

tiup dmctl
复制

3.管理配置DM任务

3.1DM工作结构

3.2 配置数据源

# 修改配置文件
vim wisdom_guide_uat.yaml 
source-id: "wisdom_guide_uat"  #数据源别名/ID
enable-gtid: true				#数据源是否开启GTID
from:
  host: "172.16.203.4"
  user: "db_admin"
  password: "R2xT1QlwZkGcFRA9Iky4REB4uwip/Kv1DQ=="
  port: 3306
  
  
# 加载源配置文件
tiup dmctl --master-addr=172.16.200.243:8261 operate-source create wisdom_guide_uat.yaml
ps 1.“--master-addr=”可以添加到环境变量中  export DM_MASTER_ADDR=172.16.200.243:8261

# 查看数据源
tiup dmctl get-config  source wisdom_guide_uat
Starting component `dmctl`: /root/.tiup/components/dmctl/v6.6.0/dmctl/dmctl get-config source wisdom_guide_uat
{
    "result": true,
    "msg": "",
    "cfg": "enable: true\nenable-gtid: true\nauto-fix-gtid: false\nrelay-dir: relay-dir\nmeta-dir: \"\"\nflavor: mysql\ncharset: \"\"\nenable-relay: false\nrelay-binlog-name: \"\"\nrelay-binlog-gtid: \"\"\nsource-id: wisdom_guide_uat\nfrom:\n  host: 172.16.203.4\n  port: 3306\n  user: db_admin\n  password: '******'\n  max-allowed-packet: null\n  session: {}\n  security: null\npurge:\n  interval: 3600\n  expires: 0\n  remain-space: 15\nchecker:\n  check-enable: true\n  backoff-rollback: 5m0s\n  backoff-max: 5m0s\n  check-interval: 5s\n  backoff-min: 1s\n  backoff-jitter: true\n  backoff-factor: 2\nserver-id: 429553756\ntracer: {}\ncase-sensitive: false\nfilters: []\n"
}




复制

加载完成后集群会分配dm-worker

# DM数据源操作
修改数据源配置文件后需要停止任务
tiup dmctl operate-source stop  wisdom_guide_uat.yaml
然后再重新启动
复制

3.3 DM迁移任务配置

任务配置文件官方模板

---

# ----------- 全局配置 -----------
## ********* 基本信息配置 *********
name: test                      # 任务名称，需要全局唯一
task-mode: all                  # 任务模式，可设为 "full" - "只进行全量数据迁移"、"incremental" - "Binlog 实时同步"、"all" - "全量 + Binlog 实时同步"
shard-mode: "pessimistic"       # 任务协调模式，可选的模式有 ""、"pessimistic、"optimistic"。默认值为 "" 即无需协调。如果是分库分表合并任务，请设置为悲观协调模式 "pessimistic"。
                                # 在 v2.0.6 版本后乐观模式逐渐成熟，深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic"
meta-schema: "dm_meta"          # 下游储存 `meta` 信息的数据库
# timezone: "Asia/Shanghai"     # 指定数据迁移任务时 SQL Session 使用的时区。DM 默认使用目标库的全局时区配置进行数据迁移，并且自动确保同步数据的正确性。使用自定义时区依然可以确保整个流程的正确性，但一般不需要手动指定。

case-sensitive: false           # schema/table 是否大小写敏感
online-ddl: true                # 支持上游 "gh-ost" 、"pt" 的自动处理
online-ddl-scheme: "gh-ost"     # `online-ddl-scheme` 已被弃用，建议使用 `online-ddl`。
clean-dump-file: true           # 是否清理 dump 阶段产生的文件，包括 metadata 文件、建库建表 SQL 文件以及数据导入 SQL 文件
collation_compatible: "loose"   # 同步 CREATE 语句中缺省 Collation 的方式，可选 "loose" 和 "strict"，默认为 "loose"。"loose" 模式不会显式补充上游缺省的 Collation，"strict" 会显式补充上游缺省的 Collation。当使用 "strict" 模式，但下游不支持上游缺省的 Collation 时，下游可能会报错。
ignore-checking-items: []       # 忽略检查项。可用值请参考 precheck 说明：https://docs.pingcap.com/zh/tidb/stable/dm-precheck。

target-database:                # 下游数据库实例配置
  host: "192.168.0.1"
  port: 4000
  user: "root"
  password: "/Q7B9DizNLLTTfiZHv9WoEAKamfpIUs="  # 推荐使用经 `dmctl encrypt` 加密后的密码
  max-allowed-packet: 67108864                  # 设置 DM 内部连接 TiDB 服务器时，TiDB 客户端的 "max_allowed_packet" 限制（即接受的最大数据包限制），单位为字节，默认 67108864 (64 MB)
                                                # 该配置项从 DM v2.0.0 起弃用，DM 会自动获取连接 TiDB 的 "max_allowed_packet"
  session:                                      # 设置 TiDB 的 session 变量，在 v1.0.6 版本引入。更多变量及解释参见 `https://docs.pingcap.com/zh/tidb/stable/system-variables`
    sql_mode: "ANSI_QUOTES,NO_ZERO_IN_DATE,NO_ZERO_DATE" # 从 DM v2.0.0 起，如果配置文件中没有出现该项，DM 会自动从下游 TiDB 中获得适合用于 "sql_mode" 的值。手动配置该项具有更高优先级
    tidb_skip_utf8_check: 1                              # 从 DM v2.0.0 起，如果配置文件中没有出现该项，DM 会自动从下游 TiDB 中获得适合用于 "tidb_skip_utf8_check" 的值。手动配置该项具有更高优先级
    tidb_constraint_check_in_place: 0
  security:                       # 下游 TiDB TLS 相关配置
    ssl-ca: "/path/to/ca.pem"
    ssl-cert: "/path/to/cert.pem"
    ssl-key: "/path/to/key.pem"

## ******** 功能配置集 **********

routes:                           # 上游和下游表之间的路由 table routing 规则集
  route-rule-1:                   # 配置名称
    schema-pattern: "test_*"      # 库名匹配规则，支持通配符 "*" 和 "?"
    table-pattern: "t_*"          # 表名匹配规则，支持通配符 "*" 和 "?"
    target-schema: "test"         # 目标库名称
    target-table: "t"             # 目标表名称
    # 可选配置：提取各分库分表的源信息，并写入下游用户自建的列，用于标识合表中各行数据的来源。如果配置该项，需要提前在下游手动创建合表，具体可参考 “table routing 文档” <https://docs.pingcap.com/zh/tidb/dev/dm-key-features#table-routing>。
    # extract-table:                                        # 提取分表去除 t_ 的后缀信息，并写入下游合表 c_table 列，例如，t_01 分表的数据会提取 01 写入下游 c_table 列
    #   table-regexp: "t_(.*)"
    #   target-column: "c_table"
    # extract-schema:                                       # 提取分库去除 test_ 的后缀信息，并写入下游合表 c_schema 列，例如，test_02 分库的数据会提取 02 写入下游 c_schema 列
    #   schema-regexp: "test_(.*)"
    #   target-column: "c_schema"
    # extract-source:                                       # 提取数据库源实例信息写入 c_source 列，例如，mysql-replica-01 数据源实例的数据会提取 mysql-replica-01 写入下游 c_source 列
    #   source-regexp: "(.*)"
    #   target-column: "c_source"
  route-rule-2:
    schema-pattern: "test_*"
    target-schema: "test"

filters:                                        # 上游数据库实例匹配的表的 binlog event filter 规则集
  filter-rule-1:                                # 配置名称
    schema-pattern: "test_*"                    # 库名匹配规则，支持通配符 "*" 和 "?"
    table-pattern: "t_*"                        # 表名匹配规则，支持通配符 "*" 和 "?"
    events: ["truncate table", "drop table"]    # 匹配哪些 event 类型
    action: Ignore                              # 对与符合匹配规则的 binlog 迁移（Do）还是忽略(Ignore)
  filter-rule-2:
    schema-pattern: "test_*"
    events: ["all dml"]
    action: Do

expression-filter:                   # 定义数据源迁移行变更的过滤规则，可以定义多个规则
  # 过滤 `expr_filter`.`tbl` 的 c 为偶数的插入
  even_c:                            # 规则名称
    schema: "expr_filter"            # 要匹配的上游数据库库名，不支持通配符匹配或正则匹配
    table: "tbl"                     # 要匹配的上游表名，不支持通配符匹配或正则匹配
    insert-value-expr: "c % 2 = 0"

block-allow-list:                    # 定义数据源迁移表的过滤规则，可以定义多个规则。如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
  bw-rule-1:                         # 规则名称
    do-dbs: ["~^test.*", "user"]     # 迁移哪些库
    ignore-dbs: ["mysql", "account"] # 忽略哪些库
    do-tables:                       # 迁移哪些表
    - db-name: "~^test.*"
      tbl-name: "~^t.*"
    - db-name: "user"
      tbl-name: "information"
  bw-rule-2:                         # 规则名称
    ignore-tables:                   # 忽略哪些表
    - db-name: "user"
      tbl-name: "log"

mydumpers:                           # dump 处理单元的运行配置参数
  global:                            # 配置名称
    threads: 4                       # dump 处理单元从上游数据库实例导出数据和 check-task 访问上游的线程数量，默认值为 4
    chunk-filesize: 64               # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB
    extra-args: "--consistency none" # dump 处理单元的其他参数，不需要在 extra-args 中配置 table-list，DM 会自动生成

loaders:                             # load 处理单元的运行配置参数
  global:                            # 配置名称
    pool-size: 16                    # load 处理单元并发执行 dump 处理单元的 SQL 文件的线程数量，默认值为 16，当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值

    # 保存上游全量导出数据的目录。该配置项的默认值为 "./dumped_data"。
    # 支持配置为本地文件系统路径，也支持配置为 Amazon S3 路径，如: s3://dm_bucket/dumped_data?endpoint=s3-website.us-east-2.amazonaws.com&access_key=s3accesskey&secret_access_key=s3secretkey&force_path_style=true
    dir: "./dumped_data"

    # 全量阶段数据导入的模式。可以设置为如下几种模式：
    # - "sql"(默认)。使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) TiDB-backend 进行导入。
    # - "loader"。使用 Loader 导入。此模式仅作为兼容模式保留，目前用于支持 TiDB Lightning 尚未包含的功能，预计会在后续的版本废弃。
    import-mode: "sql"
    # 全量导入阶段针对冲突数据的解决方式：
    # - "replace"（默认值）。仅支持 import-mode 为 "sql"，表示用最新数据替代已有数据。
    # - "ignore"。仅支持 import-mode 为 "sql"，保留已有数据，忽略新数据。
    # - "error"。仅支持 import-mode 为 "loader"。插入重复数据时报错并停止同步任务。
    on-duplicate: "replace"

syncers:                             # sync 处理单元的运行配置参数
  global:                            # 配置名称
    worker-count: 16                 # 应用已传输到本地的 binlog 的并发线程数量，默认值为 16。调整此参数不会影响上游拉取日志的并发，但会对下游产生显著压力。
    batch: 100                       # sync 迁移到下游数据库的一个事务批次 SQL 语句数，默认值为 100，建议一般不超过 500。
    enable-ansi-quotes: true         # 若 `session` 中设置 `sql-mode: "ANSI_QUOTES"`，则需开启此项

    # 设置为 true，则将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。
    safe-mode: false
    # 自动安全模式的持续时间
    # 如不设置或者设置为 ""，则默认为 `checkpoint-flush-interval`（默认为 30s）的两倍，即 60s。
    # 如设置为 "0s"，则在 DM 自动进入安全模式的时候报错。
    # 如设置为正常值，例如 "1m30s"，则在该任务异常暂停、记录 `safemode_exit_point` 失败、或是 DM 进程异常退出时，把安全模式持续时间调整为 1 分 30 秒。详情可见[自动开启安全模式](https://docs.pingcap.com/zh/tidb/stable/dm-safe-mode#自动开启)。
    safe-mode-duration: "60s"
    # 设置为 true，DM 会在不增加延迟的情况下，尽可能地将上游对同一条数据的多次操作压缩成一次操作。
    # 如 INSERT INTO tb(a,b) VALUES(1,1); UPDATE tb SET b=11 WHERE a=1; 会被压缩成 INSERT INTO tb(a,b) VALUES(1,11); 其中 a 为主键
    # 如 UPDATE tb SET b=1 WHERE a=1; UPDATE tb(a,b) SET b=2 WHERE a=1; 会被压缩成 UPDATE tb(a,b) SET b=2 WHERE a=1; 其中 a 为主键
    # 如 DELETE FROM tb WHERE a=1; INSERT INTO tb(a,b) VALUES(1,1); 会被压缩成 REPLACE INTO tb(a,b) VALUES(1,1); 其中 a 为主键
    compact: false
    # 设置为 true，DM 会尽可能地将多条同类型的语句合并到一条语句中，生成一条带多行数据的 SQL 语句。
    # 如 INSERT INTO tb(a,b) VALUES(1,1); INSERT INTO tb(a,b) VALUES(2,2); 会变成 INSERT INTO tb(a,b) VALUES(1,1),(2,2);
    # 如 UPDATE tb SET b=11 WHERE a=1; UPDATE tb(a,b) set b=22 WHERE a=2; 会变成 INSERT INTO tb(a,b) VALUES(1,11),(2,22) ON DUPLICATE KEY UPDATE a=VALUES(a), b=VALUES(b); 其中 a 为主键
    # 如 DELETE FROM tb WHERE a=1; DELETE FROM tb WHERE a=2 会变成 DELETE FROM tb WHERE (a) IN (1),(2)；其中 a 为主键
    multiple-rows: false

validators:              # 增量数据校验的运行配置参数
  global:                # 配置名称
    # full：校验每一行中每一列数据是否正确
    # fast：仅校验这一行是否有成功迁移到下游
    # none：不校验
    mode: full           # 可选填 full，fast 和 none，默认是 none，即不开启校验。
    worker-count: 4      # 后台校验的 validation worker 数量，默认是 4 个
    row-error-delay: 30m # 某一行多久没有校验通过会被标记为 error row，默认是 30 分钟

# ----------- 实例配置 -----------
mysql-instances:
  -
    source-id: "mysql-replica-01"           # 对应 source.toml 中的 `source-id`
    meta:                                   # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 `checkpoint` 为准。如果 `meta` 项和下游数据库的 `checkpoint` 都不存在，则从上游当前最新的 binlog 位置开始迁移
      binlog-name: binlog.000001
      binlog-pos: 4
      binlog-gtid: "03fc0263-28c7-11e7-a653-6c0b84d59f30:1-7041423,05474d3c-28c7-11e7-8352-203db246dd3d:1-170"  # 对于 source 中指定了 `enable-gtid: true` 的增量任务，需要指定该值

    route-rules: ["route-rule-1", "route-rule-2"]    # 该上游数据库实例匹配的表到下游数据库的 table routing 规则名称
    filter-rules: ["filter-rule-1", "filter-rule-2"] # 该上游数据库实例匹配的表的 binlog event filter 规则名称
    block-allow-list:  "bw-rule-1"                   # 该上游数据库实例匹配的表的 block-allow-list 过滤规则名称，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list
    expression-filters: ["even_c"]                   # 使用名为 even_c 的表达式过滤规则

    mydumper-config-name: "global"          # mydumpers 配置的名称
    loader-config-name: "global"            # loaders 配置的名称
    syncer-config-name: "global"            # syncers 配置的名称
    validator-config-name: "global"         # validators 配置的名称
  -
    source-id: "mysql-replica-02"  # 对应 source.toml 中的 `source-id`
    mydumper-thread: 4             # dump 处理单元用于导出数据的线程数量，等同于 mydumpers 配置中的 `threads`，当同时指定它们时 `mydumper-thread` 优先级更高
    loader-thread: 16              # load 处理单元用于导入数据的线程数量，等同于 loaders 配置中的 `pool-size`，当同时指定它们时 `loader-thread` 优先级更高。当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值
    syncer-thread: 16              # sync 处理单元用于复制增量数据的线程数量，等同于 syncers 配置中的 `worker-count`，当同时指定它们时 `syncer-thread` 优先级更高。当有多个实例同时向 TiDB 迁移数据时可根据负载情况适当调小该值

复制

https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full
复制

# 此次配置迁移任务最小化配置文件
name: "guide_task"
task-mode: all
#ignore-checking-items: ["auto_increment_ID"] 
target-database:
  host: "172.16.203.183"
  port: 4000
  user: "root"
  password: "R2xT1QlwZkGcFRA9Iky4REB4uwip/Kv1DQ=="

mysql-instances:
-  
  source-id: "wisdom_guide_uat"
  block-allow-list: "wisdom_guide"
  mydumper-config-name: "global"

block-allow-list:
 wisdom_guide:
  do-dbs: ["wisdom_guide"]

mydumpers:
 global:
  threads: 12
  chunk-filesize: 64

复制

3.4 检查配置文件

tiup dmctl check-task guide_task.yaml

ps 1.不支持外键、没有主键、字符集识别等都会报警告，但不影响任务启动。
ps 2.dm早前版本是用mydumper导出，然后loader到tidb，然后优化成dumpling导出，tidb-lightning导入（tidb模式）。最新版本是dumpling导出，支持了tidb-lughtning（local模式）导入tidb
ps 3.源端存在_gho后缀表名将会报错“short_error": "your ddl is in pt/ghost online-ddl”，需要删除或改名。
ps 4.全量是需要文件落地，备份数据存储目录是data_dir，建议准备一个至少1.5倍空间的nas挂上。
复制

3.5 开启迁移任务

tiup dmctl  start-task guide_task.yaml 
复制

3.6 查看任务状态

tiup dmctl  query-status guide_task.yaml 
复制

3.7 控制迁移任务

# 暂停任务
tiup dmctl  pause-task guide_task.yaml 

#恢复任务
tiup dmctl  resume-task guide_task.yaml

# 停止任务
tiup dmctl  stop-task guide_task.yaml 


复制

3.8 扩容DM 节点

vi dm-scale.yaml 
加入如下内容： 
worker_servers: 
  - host: 172.16.203.19
  
tiup dm scale-out dm-test dm-scale.yaml -uroot -p 
tiup dm display dm-test

复制