一、mysql数据迁移

博主使用了 navicat工具 （导入导出、转存sql结构和数据）、mysqldump命令等模式进行数据迁移尝试后，果断放弃（当mysql导出的文件达到3GB后，效率低下）！直接使用 TiUP DM 集群进行数据迁移。

二、DM组件安装部署

TiUP DM 是 TiUP 提供的使用 Golang 编写的集群管理组件，通过 TiUP DM 组件就可以进行日常的运维工作，主要包含：数据迁移、数据热同步。

[参考管网资料] : https://docs.pingcap.com/zh/tidb/stable/deploy-a-dm-cluster-using-tiup

2.1、安装TiUP DM组件：

tiup install dm dmctl

2.2、创建标准目录：

2.3、配置DM的集群配置文件：

global:
  user: "tidm"
  ssh_port: 22
  deploy_dir: "/home/TiDM/dm-deploy"
  data_dir: "/home/TiDM/dm-data"

server_configs:
  master:
    log-level: info
  worker:
    log-level: info

master_servers:
  - host: 10.10.26.233
    name: master1
    ssh_port: 22
    port: 8261
    config:
      log-level: info
  
worker_servers:
  - host: 10.10.26.233
    ssh_port: 22
    port: 8262
    deploy_dir: "/home/TiDM/dm-deploy/dm-worker-8262"
    log_dir: "/home/TiDM/dm-deploy/dm-worker-8262/log"
    config:
      log-level: info

monitoring_servers:
  - host: 10.10.26.233
    ssh_port: 22
    port: 9090

grafana_servers:
  - host: 10.10.26.233
    port: 3000
    #deploy_dir: /tidb-deploy/grafana-3000

alertmanager_servers:
  - host: 10.10.26.233
    ssh_port: 22
    web_port: 9093

如果不需要确保 DM 集群高可用，则可只部署 1 个 DM-master 节点，且部署的 DM-worker 节点数量不少于上游待迁移的 MySQL/MariaDB 实例数，不然可能导致迁移速度较慢。

2.4、部署DM集群：

# 通过 tiup list dm-master 查看TiUP 支持的最新版本。（输入本机的ssh密码）
tiup dm deploy tidm v6.1.7 /home/TiDM/topology.yaml --user root -p

2.5、检查DM集群状态和开启集群：

# 查看 TiUP 管理的集群情况
tiup dm list
# 检查部署的 DM 集群情况
tiup dm display tidm
# 启动集群
tiup dm start tidm

3、准备执行数据迁移

这里需要创建两个yaml文件，一个是mysql的数据源描述，一个是task迁移任务的描述，建议做好目录存放，如下图：

[参考管网资料] : https://docs.pingcap.com/zh/tidb/stable/migrate-small-mysql-to-tidb

3.1、设置mysql的数据源：

# 这里描述数据源的id
source-id: "mysql-01"

enable-gtid: false

from:
  host: "10.10.26.233"         
  user: "root"
  password: "cdxxxx.com" 
  port: 3306

3.2、使用 TiUP dmctl 将数据源配置加载到 DM 集群中

tiup dmctl --master-addr 10.10.26.233:8261 operate-source create source1.yaml

3.3、创建任务 task.yaml 文件（全库同步）

name: task-zw                      # 任务名称，需要全局唯一。
# 任务模式，可设为
# full：只进行全量数据迁移
# incremental： binlog 实时同步
# all： 全量 + binlog 迁移
task-mode: full

# 配置下游 TiDB 数据库实例访问信息
target-database:                     # 下游数据库实例配置。
  host: "10.10.26.233"                    # 例如：127.0.0.1
  port: 4000
  user: "root"
  password: "cdqcp01.com"            # 推荐使用经过 dmctl 加密的密文。

#  使用黑白名单配置需要同步的表
block-allow-list:                    # 数据源数据库实例匹配的表的 block-allow-list 过滤规则集，如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
  bw-rule-1:                         # 黑白名单配置项 ID。
    do-dbs: ["bst_zw_station_local_cll"]           # 迁移哪些库。

# 配置数据源
mysql-instances:
  - source-id: "mysql-01"            # 数据源 ID，即 source1.yaml 中的 source-id
    block-allow-list: "bw-rule-1"    # 引入上面黑白名单配置。
    # syncer-config-name: "global"    # 引用下面的 syncers 增量数据配置。
    #meta:                            # task-mode 为 incremental 且下游数据库的 checkpoint 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 checkpoint 为准。
      #binlog-name: "mysql-bin.000022"  # 第 1 步中记录的日志位置，当上游存在主从切换时，必须使用 gtid。
      #binlog-pos: 156
      #binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"

注意：task-mode如果是incremental，代表只是增量更新，需要下面的 mysql-instances 开启meta配置，也需要源 mysql 数据库开启binlog。

3.4、启动迁移任务：

# 检查task.yaml 文件是否符合迁移要求
tiup dmctl --master-addr 10.10.26.233:8261 check-task task.yaml

检查后发现，部分表因为外键、主键缺失的关系，需要对mysql进行处理。

# 全部符合条件后就可以启动迁移任务了，如下
tiup dmctl --master-addr 10.10.26.233:8261 start-task task.yaml
# 检查进度
tiup dmctl --master-addr 10.10.26.233:8261 query-status task.yaml

3.5、迁移期间出现问题

query-status 随时监控迁移情况，若出现error则需要先处理异常
异常：table: bst_zw_station_local_cll.tbl_busi_dispatch_sign, stmt: restore table schema: run create schema job failed: Error 1273: Unsupported collation when new collation is enabled: ‘utf8_danish_ci’",

# 处理mysql表的外键
SHOW CREATE TABLE tbl_busi_dispatch_sign;
ALTER TABLE tbl_busi_dispatch_sign CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE tbl_busi_dispatch_sign MODIFY traffic_list_valid_period VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_general_ci;

# 发现问题后先处理问题，暂停迁移任务 ：task-zw 这里可以是任务名称，或者任务路径
tiup dmctl --master-addr 10.10.26.233:8261 pause-task task-zw
# 处理完问题后，恢复任务
tiup dmctl --master-addr 10.10.26.233:8261 resume-task task-zw
# 该任务节点已经完全阻断，则直接终止任务
tiup dmctl --master-addr 10.10.26.233:8261 stop-task task-zw

坑点：处理数据库的字符集问题后，stop-task、start-task 并没有任何作用，还是会出现上述的异常，怀疑是因为 tiup dmctl 在执行task任务时，已经对mysql进行了 dump，生成了 dump文件，所以无论再如何修改mysql表本身的配置已经无效了。
重新创建任务 task1.yaml 文件 内部任务命令为 task-zw1 执行顺利。

3.6、其他坑点

坑点：创建新的task2以后，也创建了一个新的source2.yaml数据源，但是无论如何启动task都不成功，甚至影响之前的task，原因是数据源和dm集群的work节点是一一绑定的。
如果只配置了一个work，但是加载了两个数据源，则无论是解绑，更换数据源都是无效的。重启dm集群解决。

#查看数据源配置文件
tiup dmctl --master-addr 10.10.26.233:8261 get-config source mysql-01
#查看数据源和 work 节点对应关系
tiup dmctl --master-addr 10.10.26.233:8261 operate-source show
#查看work节点的信息
tiup dmctl --master-addr 10.10.26.233:8261 list-member --worker
#改变work节点和数据源的关系
tiup dmctl --master-addr 10.10.26.233:8261 transfer-source mysql-02 dm-10.10.26.233-8262

4、等待数据迁移完成

在一个work节点的情况下，3G数据库耗时4小时左右迁移完毕！