tidb教程FG088-TiDB数据迁移方案选型

本文档风哥主要介绍TiDB数据迁移方案的选型方法和技巧，包括数据迁移相关概念、TiDB数据迁移架构、影响迁移性能的因素、迁移方法、硬件规划、配置规划、迁移策略、迁移步骤、调优方法、验证流程、实战案例和最佳实践等，风哥教程参考TiDB官方文档数据迁移相关内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。更多视频教程www.fgedu.net.cn

Part01-基础概念与理论知识

1.1 数据迁移相关概念

数据迁移相关的基本概念：

# 数据迁移相关概念

## 1. 数据迁移
– **数据迁移**：将数据从一个系统迁移到另一个系统的过程
– **源系统**：数据的来源系统
– **目标系统**：数据的目标系统
– **迁移范围**：需要迁移的数据范围
– **迁移时间**：完成迁移所需的时间

## 2. 迁移类型
– **全量迁移**：将源系统的所有数据一次性迁移到目标系统
– **增量迁移**：在全量迁移的基础上，持续同步源系统的变更数据
– **实时同步**：实时将源系统的变更数据同步到目标系统
– **离线迁移**：在系统停机的情况下进行迁移
– **在线迁移**：在系统运行的情况下进行迁移

## 3. 迁移工具
– **DM**：TiDB Data Migration，TiDB官方的迁移工具
– **DTS**：数据传输服务，云服务提供商提供的迁移服务
– **mysqldump**：MySQL官方的导出工具
– **mydumper**：高性能的MySQL导出工具
– **LOAD DATA**：TiDB的导入工具
– **BR**：TiDB Backup & Restore，TiDB的备份恢复工具

## 4. 迁移性能指标
– **迁移速度**：单位时间内迁移的数据量
– **迁移延迟**：源系统数据变更到目标系统同步完成的时间差风哥提示：
– **迁移成功率**：成功迁移的数据占总数据的比例
– **系统影响**：迁移对源系统和目标系统的性能影响

## 5. 迁移风险
– **数据一致性**：迁移后数据是否与源系统一致
– **系统可用性**：迁移过程中系统是否可用
– **数据丢失**：迁移过程中是否有数据丢失
– **性能下降**：迁移过程中系统性能是否下降
– **业务中断**：迁移是否导致业务中断

1.2 TiDB数据迁移架构

TiDB数据迁移的架构：

# TiDB数据迁移架构

## 1. 迁移架构
– **源系统**：MySQL、Oracle、PostgreSQL等
– **迁移工具**：DM、DTS、mysqldump等
– **目标系统**：TiDB集群
– **网络**：源系统与目标系统之间的网络

## 2. DM架构
– **DM-master**：管理和调度DM-worker
– **DM-worker**：执行具体的迁移任务
– **DM-ctl**：命令行工具，用于管理DM集群
– **MySQL/MariaDB**：源数据库
– **TiDB**：目标数据库

## 3. 迁移流程
1. **准备阶段**：评估源系统，准备目标系统
2. **全量迁移**：将源系统的所有数据迁移到目标系统
3. **增量同步**：持续同步源系统的变更数据
4. **验证阶段**：验证迁移后的数据一致性
5. **切换阶段**：将业务切换到目标系统

## 4. 关键组件
– **DM**：TiDB官方的数据迁移工具，支持全量迁移和增量同步
– **DTS**：云服务提供商提供的数据传输服务，支持多种数据源
– **mysqldump**：MySQL官方的导出工具，适合小数据量迁移
– **mydumper**：高性能的MySQL导出工具，适合大数据量迁移
– **LOAD DATA**：TiDB的导入工具，支持快速导入数据
– **BR**：TiDB的备份恢复工具，适合TiDB集群间的迁移

## 5. 迁移特点
– **异构迁移**：支持从不同类型的数据库迁移到TiDB
– **在线迁移**：支持在源系统运行的情况下进行迁移
– **增量同步**：支持持续同步源系统的变更数据
– **数据一致性**：保证迁移后的数据与源系统一致
– **可扩展性**：支持大规模数据迁移

1.3 影响迁移性能的因素

影响TiDB数据迁移性能的因素：

影响迁移性能的因素：

源系统性能：源系统的CPU、内存、磁盘、网络等性能
目标系统性能：目标TiDB集群的性能
网络带宽：源系统与目标系统之间的网络带宽
数据量：需要迁移的数据量大小
数据复杂度：数据结构的复杂度，如索引、约束等
迁移工具：选择的迁移工具的性能
迁移策略：采用的迁移策略，如全量迁移+增量同步
并发度：迁移过程中的并发度
系统负载：源系统和目标系统的当前负载
数据类型：数据类型的复杂度，如大字段、JSON等

1.4 迁移方法

TiDB支持的数据迁移方法：

# 迁移方法

## 1. 使用DM工具
– **适用场景**：从MySQL/MariaDB迁移到TiDB
– **特点**：支持全量迁移和增量同步，自动化程度高
– **使用示例**：
“`bash
# 部署DM集群
tiup dm deploy dm-master v6.1.0 dm-master-topology.yaml –user root -p
tiup dm start dm-master

# 配置迁移任务
tiup dmctl –master-addr=”192.168.1.10:8261″ operate-source create source.yaml
tiup dmctl –master-addr=”192.168.1.10:8261″ create task.yaml
“`

## 2. 使用DTS服务
– **适用场景**：从各种数据库迁移到TiDB，特别是云数据库
– **特点**：全托管服务，操作简单，支持多种数据源
– **使用示例**：
“`bash
# 在云控制台创建DTS任务
# 配置源数据库和目标TiDB的连接信息
# 启动迁移任务学习交流加群风哥QQ113257174
“`

## 3. 使用mysqldump
– **适用场景**：从小规模MySQL数据库迁移到TiDB
– **特点**：操作简单，适合小数据量迁移
– **使用示例**：
“`bash
# 导出数据
mysqldump -h 192.168.1.10 -P 3306 -u root -p –databases test > test.sql

# 导入数据
mysql -h 192.168.1.20 -P 4000 -u root -p test < test.sql ``` ## 4. 使用mydumper - **适用场景**：从大规模MySQL数据库迁移到TiDB - **特点**：高性能，支持并行导出 - **使用示例**： ```bash # 导出数据 mydumper -h 192.168.1.10 -P 3306 -u root -p -B test -o /data/backup # 导入数据 myloader -h 192.168.1.20 -P 4000 -u root -p -B test -d /data/backup ``` ## 5. 使用LOAD DATA - **适用场景**：从文本文件导入数据到TiDB - **特点**：高性能，适合大批量数据导入 - **使用示例**： ```sql -- 导入数据 LOAD DATA LOCAL INFILE '/data/data.txt' INTO TABLE test.table FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' ; ``` ## 6. 使用BR工具 - **适用场景**：TiDB集群间的迁移 - **特点**：高性能，支持全量备份和恢复 - **使用示例**： ```bash # 备份数据 br backup full --pd "192.168.1.10:2379" --storage "local:///data/backup" # 恢复数据 br restore full --pd "192.168.1.20:2379" --storage "local:///data/backup" ``` ## 7. 使用应用程序迁移 - **适用场景**：需要进行数据转换或处理的迁移 - **特点**：灵活性高，支持复杂的数据转换 - **使用示例**： ```python import pymysql # 连接源数据库 src_conn=pymysql.connect(host='192.168.1.10' , port=3306, user='root' , password='password' , db='test' ) src_cursor=src_conn.cursor() # 连接目标数据库 dst_conn=pymysql.connect(host='192.168.1.20' , port=4000, user='root' , password='password' , db='test' ) dst_cursor=dst_conn.cursor() # 查询数据 src_cursor.execute("SELECT * FROM src_table") rows=src_cursor.fetchall() # 插入数据 for row in rows: dst_cursor.execute("INSERT INTO dst_table VALUES (%s, %s, %s)", row) dst_conn.commit() src_cursor.close() src_conn.close() dst_cursor.close() dst_conn.close() ```

风哥提示：选择合适的数据迁移方法是成功迁移的关键，需要根据数据量、源系统类型、迁移时间要求等因素综合考虑。学习交流加群风哥微信: itpux-com

Part02-生产环境规划与建议

2.1 硬件规划

数据迁移场景下的硬件规划：

# 硬件规划

## 1. 源系统硬件
– **CPU**：根据源系统的负载情况，确保足够的CPU资源
– **内存**：确保足够的内存，避免迁移过程中内存不足
– **磁盘**：确保足够的磁盘空间，用于存储导出的数据
– **网络**：确保足够的网络带宽，特别是与目标系统之间的网络

## 2. 目标系统硬件
– **TiDB节点**：
– CPU：8-16核，高主频
– 内存：32-64GB
– 磁盘：SSD，200GB以上
– 网络：万兆网络

– **TiKV节点**：
– CPU：16-32核
– 内存：64-128GB
– 磁盘：NVMe SSD，1TB以上
– 网络：万兆网络

– **PD节点**：
– CPU：4-8核
– 内存：16-32GB
– 磁盘：SSD，100GB以上
– 网络：万兆网络

## 3. 迁移服务器硬件
– **CPU**：16-32核
– **内存**：64-128GB
– **磁盘**：SSD，1TB以上，用于存储导出的数据
– **网络**：万兆网络，确保与源系统和目标系统之间的网络带宽充足

## 4. 网络规划
– **网络带宽**：源系统与目标系统之间的网络带宽至少为10Gbps
– **网络延迟**：源系统与目标系统之间的网络延迟应小于10ms
– **网络稳定性**：确保网络稳定，避免迁移过程中网络中断

## 5. 存储规划
– **临时存储**：需要足够的临时存储空间，用于存储导出的数据
– **备份存储**：需要足够的备份存储空间，用于存储迁移前的备份数据
– **目标存储**：目标TiDB集群需要足够的存储空间，容纳迁移的数据

2.2 配置规划

数据迁移场景下的配置规划：

# 配置规划

## 1. 源系统配置
– **MySQL配置**：
“`cnf
[mysqld]
max_connections = 1000
innodb_buffer_pool_size = 8G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
sync_binlog = 0
“`

– **Oracle配置**：
“`sql
— 调整PGA和SGA
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = ‘4G’ SCOPE=SPFILE;
ALTER SYSTEM SET SGA_TARGET = ‘8G’ SCOPE=SPFILE;
— 重启数据库
SHUTDOWN IMMEDIATE;
STARTUP;
“`

– **PostgreSQL配置**：
“`conf
# postgresql.conf
max_connections = 100
shared_buffers = 2GB
work_mem = 32MB
maintenance_work_mem = 1GB
wal_buffers = 16MB
“`

## 2. 目标系统配置
– **TiDB配置**：
“`toml
[tidb]
max-connections = 10000
txn-total-size-limit = 209715200 # 200MB
tmp-storage-size = -1
“`

– **TiKV配置**：
“`toml
[storage.block-cache]
capacity = “64GB”

[rocksdb.defaultcf]
write-buffer-size = “1GB”
max-write-buffer-number = 4

[server]
grpc-concurrency = 32
“`

– **PD配置**：
“`toml
[replication]
max-replicas = 3

[schedule]
leader-schedule-limit = 4
region-schedule-limit = 2048
replica-schedule-limit = 64
“`

## 3. 迁移工具配置
– **DM配置**：
“`yaml
# dm-master.toml
[master]
addr = “192.168.1.10:8261”

# dm-worker.toml
[worker]
addr = “192.168.1.11:8262”
“`

– **mysqldump配置**：
“`bash
# 导出配置
mysqldump –single-transaction –quick –hex-blob –master-data=2 –dump-date
“`

– **mydumper配置**：
“`bash
# 导出配置
mydumper –threads=16 –compress –triggers –routines –events
“`

## 4. 系统配置
– **文件描述符限制**：
“`bash
echo “* soft nofile 65535” >> /etc/security/limits.conf
echo “* hard nofile 65535” >> /etc/security/limits.conf
“`

– **TCP参数**：
“`bash
echo “net.core.somaxconn = 4096” >> /etc/sysctl.conf
echo “net.ipv4.tcp_max_syn_backlog = 4096” >> /etc/sysctl.conf
echo “net.ipv4.tcp_fin_timeout = 30” >> /etc/sysctl.conf
echo “net.ipv4.tcp_tw_reuse = 1” >> /etc/sysctl.conf
sysctl -p
“`

– **I/O调度**：
“`bash
# 查看当前I/O调度
cat /sys/block/nvme0n1/queue/scheduler
# 设置为none调度器
echo none > /sys/block/nvme0n1/queue/scheduler
“`

2.3 迁移策略

数据迁移的策略选择：

# 迁移策略

## 1. 迁移策略选择
– **全量迁移**：适用于数据量较小，业务可以接受短暂停机的场景
– **全量迁移+增量同步**：适用于数据量较大，业务需要持续运行的场景
– **实时同步**：适用于对数据一致性要求高，业务需要实时同步的场景
– **分批次迁移**：适用于超大数据量，需要分批次处理的场景

## 2. 迁移时间窗口
– **业务低峰期**：选择业务低峰期进行迁移，减少对业务的影响
– **周末或节假日**：选择周末或节假日进行迁移，有足够的时间处理问题
– **预估迁移时间**：根据数据量和迁移速度，预估迁移所需的时间
– **预留缓冲时间**：预留足够的缓冲时间，处理可能出现的问题

## 3. 数据验证策略
– **全量验证**：对迁移后的数据进行全量验证，确保数据一致性
– **抽样验证**：对迁移后的数据进行抽样验证，确保数据质量
– **业务验证**：通过业务操作验证迁移后的数据是否正常
– **性能验证**：验证迁移后系统的性能是否满足业务需求

## 4. 回滚策略
– **备份源数据**：在迁移前备份源系统的数据，确保可以回滚
– **制定回滚计划**：制定详细的回滚计划，包括回滚步骤和时间点
– **测试回滚流程**：在迁移前测试回滚流程，确保回滚可以正常执行
– **设置回滚触发条件**：设置回滚的触发条件，如数据不一致、性能下降等

## 5. 业务切换策略
– **双写策略**：在迁移期间同时向源系统和目标系统写入数据
– **灰度切换**：先将部分业务切换到目标系统，验证后再全部切换
– **一次性切换**：在迁移完成后一次性将所有业务切换到目标系统
– **切换时间窗口**：选择合适的切换时间窗口，减少对业务的影响

## 6. 风险评估
– **数据一致性风险**：评估迁移过程中数据一致性的风险
– **系统可用性风险**：评估迁移过程中系统可用性的风险
– **性能风险**：评估迁移过程中系统性能的风险
– **业务中断风险**：评估迁移过程中业务中断的风险
– **安全风险**：评估迁移过程中的安全风险

Part03-生产环境项目实施方案

3.1 迁移步骤

TiDB数据迁移的实施步骤：

# 迁移步骤

## 1. 准备阶段
– **步骤1**：评估源系统
– 分析源系统的数据库结构
– 评估源系统的数据量
– 评估源系统的性能状况
– 识别源系统中的特殊数据类型和约束

– **步骤2**：准备目标系统
– 部署TiDB集群
– 配置TiDB集群参数
– 测试TiDB集群性能
– 准备足够的存储空间

– **步骤3**：选择迁移工具
– 根据源系统类型选择合适的迁移工具
– 测试迁移工具的性能
– 配置迁移工具参数

– **步骤4**：制定迁移计划
– 确定迁移时间窗口
– 制定详细的迁移步骤
– 制定数据验证计划
– 制定回滚计划

## 2. 执行阶段
– **步骤1**：备份源数据
– 对源系统进行全量备份
– 验证备份的完整性
– 存储备份数据

– **步骤2**：执行全量迁移
– 使用迁移工具导出源数据
– 传输数据到目标系统
– 导入数据到TiDB
– 监控迁移进度

– **步骤3**：执行增量同步
– 配置增量同步
– 启动增量同步
– 监控增量同步状态
– 确保增量同步正常运行

## 3. 验证阶段
– **步骤1**：数据一致性验证
– 比较源系统和目标系统的数据量
– 抽样检查数据内容
– 验证索引和约束
– 验证特殊数据类型

– **步骤2**：业务验证
– 测试业务功能
– 验证业务流程
– 检查业务数据正确性
– 验证业务性能

– **步骤3**：性能验证
– 测试查询性能
– 测试写入性能
– 测试并发性能
– 验证系统稳定性

## 4. 切换阶段
– **步骤1**：准备切换
– 通知相关人员
– 准备切换工具和脚本
– 确认目标系统状态
– 确认增量同步状态

– **步骤2**：执行切换
– 停止源系统的写入
– 等待增量同步完成
– 更新应用配置，指向目标系统
– 启动应用，连接目标系统

– **步骤3**：验证切换
– 验证应用连接正常
– 验证业务功能正常
– 监控系统性能
– 处理切换过程中的问题

## 5. 收尾阶段
– **步骤1**：清理工作
– 清理临时文件
– 清理迁移工具配置
– 清理备份数据（可选）

– **步骤2**：文档整理
– 记录迁移过程
– 记录遇到的问题和解决方案
– 整理迁移经验
– 更新系统文档

– **步骤3**：监控和维护
– 监控目标系统性能
– 监控目标系统稳定性
– 处理可能出现的问题
– 优化目标系统性能

3.2 调优方法

TiDB数据迁移的调优方法：

# 调优方法

## 1. 源系统调优
– **调整源系统参数**：
“`sql
— MySQL调优
SET GLOBAL innodb_max_dirty_pages_pct = 75;
SET GLOBAL innodb_io_capacity = 2000;
SET GLOBAL innodb_io_capacity_max = 4000;
“`

– **优化源系统查询**：
– 优化导出查询
– 减少锁竞争
– 避免全表扫描

– **增加源系统资源**：
– 增加CPU资源
– 增加内存资源
– 增加磁盘I/O能力
– 增加网络带宽

## 2. 目标系统调优
– **调整TiDB参数**：
“`toml
[tidb]
max-connections = 10000
txn-total-size-limit = 209715200 # 200MB
tmp-storage-size = -1
“`

– **调整TiKV参数**：
“`toml
[storage.block-cache]
capacity = “64GB”

[rocksdb.defaultcf]
write-buffer-size = “1GB”
max-write-buffer-number = 4

[server]
grpc-concurrency = 32
“`

– **增加目标系统资源**：
– 增加TiKV节点
– 增加TiDB节点
– 增加PD节点
– 升级硬件配置

## 3. 迁移工具调优
– **DM调优**：
“`yaml
# task.yaml
sync:
worker-count: 16
batch-size: 10000
max-retry: 10
“`

– **mysqldump调优**：
“`bash
# 使用–quick和–single-transaction选项
mysqldump –single-transaction –quick –hex-blob –master-data=2
“`

– **mydumper调优**：
“`bash
# 增加线程数
mydumper –threads=16 –compress –triggers –routines –events
“`

– **LOAD DATA调优**：
“`sql
— 禁用Binlog
SET SESSION sql_log_bin = 0;
— 调整批量大小
SET SESSION tidb_batch_insert_size = 10000;
“`

## 4. 网络调优
– **增加网络带宽**：
– 使用万兆网络
– 优化网络拓扑
– 减少网络跳数

– **网络参数调优**：
“`bash
# 调整TCP参数
echo “net.core.somaxconn = 4096” >> /etc/sysctl.conf
echo “net.ipv4.tcp_max_syn_backlog = 4096” >> /etc/sysctl.conf
echo “net.ipv4.tcp_fin_timeout = 30” >> /etc/sysctl.conf
echo “net.ipv4.tcp_tw_reuse = 1” >> /etc/sysctl.conf
sysctl -p
“`

– **使用压缩传输**：
– 启用数据压缩
– 使用压缩工具传输数据
– 减少网络传输量

## 5. 数据处理调优
– **分批次处理**：
“`python
# 分批次处理数据
batch_size = 10000
for i in range(0, total_rows, batch_size):
end = min(i + batch_size, total_rows)
process_batch(i, end)
“`

– **并行处理**：
“`python
# 并行处理数据
import threading

def process_batch(start, end):
# 处理逻辑
pass

threads = []
for i in range(0, total_rows, batch_size):
end = min(i + batch_size, total_rows)
t = threading.Thread(target=process_batch, args=(i, end))
threads.append(t)
t.start()

for t in threads:
t.join()
“`

– **数据转换优化**：
– 使用高效的数据转换方法
– 减少数据转换次数
– 优化数据转换逻辑

## 6. 监控和调优
– **监控迁移进度**：
– 监控导出进度
– 监控传输进度
– 监控导入进度
– 监控增量同步进度

– **分析瓶颈**：
– 分析源系统瓶颈
– 分析目标系统瓶颈
– 分析网络瓶颈
– 分析迁移工具瓶颈

– **调整优化策略**：
– 根据瓶颈调整优化策略
– 调整并发度
– 调整批量大小
– 调整迁移工具参数

3.3 验证流程

TiDB数据迁移的验证流程：

# 验证流程

## 1. 数据一致性验证
– **步骤1**：验证数据量
“`sql
— 源系统
SELECT COUNT(*) FROM source_table;
— 目标系统
SELECT COUNT(*) FROM target_table;
“`

– **步骤2**：验证数据内容
“`sql
— 抽样检查
SELECT * FROM source_table ORDER BY RAND() LIMIT 100;
SELECT * FROM target_table ORDER BY RAND() LIMIT 100;
“`

– **步骤3**：验证索引和约束
“`sql
— 验证索引
SHOW INDEX FROM source_table;
SHOW INDEX FROM target_table;

— 验证约束
SHOW CREATE TABLE source_table;
SHOW CREATE TABLE target_table;
“`

– **步骤4**：验证特殊数据类型
“`sql
— 验证大字段
SELECT COUNT(*) FROM source_table WHERE LENGTH(large_field) > 1000;
SELECT COUNT(*) FROM target_table WHERE LENGTH(large_field) > 1000;

— 验证JSON数据
SELECT COUNT(*) FROM source_table WHERE JSON_VALID(json_field);
SELECT COUNT(*) FROM target_table WHERE JSON_VALID(json_field);
“`

## 2. 业务验证
– **步骤1**：测试业务功能
– 测试核心业务功能
– 测试边缘业务功能
– 测试异常场景

– **步骤2**：验证业务流程
– 测试完整业务流程
– 测试跨系统业务流程
– 测试批量业务流程

– **步骤3**：检查业务数据正确性
– 验证业务计算结果
– 验证业务报表数据
– 验证业务统计数据

– **步骤4**：验证业务性能
– 测试业务响应时间
– 测试业务吞吐量
– 测试业务并发性能

## 3. 性能验证
– **步骤1**：测试查询性能
“`sql
— 测试常用查询
EXPLAIN ANALYZE SELECT * FROM target_table WHERE id = 1;
EXPLAIN ANALYZE SELECT * FROM target_table WHERE name LIKE ‘%test%’;
EXPLAIN ANALYZE SELECT COUNT(*) FROM target_table GROUP BY status;
“`

– **步骤2**：测试写入性能
“`bash
# 使用sysbench测试写入性能
sysbench –db-driver=mysql –mysql-host=192.168.1.20 –mysql-port=4000 –mysql-user=root
–mysql-password=password –mysql-db=test –table-size=1000000 –threads=64 –time=60 oltp_write_only run
“`

– **步骤3**：测试并发性能
“`bash
# 使用sysbench测试并发性能
sysbench –db-driver=mysql –mysql-host=192.168.1.20 –mysql-port=4000 –mysql-user=root
–mysql-password=password –mysql-db=test –table-size=1000000 –threads=128 –time=60 oltp_read_write run
“`

– **步骤4**：验证系统稳定性
– 长时间运行测试
– 高并发测试
– 故障恢复测试
– 负载测试

## 4. 安全验证
– **步骤1**：验证权限设置
“`sql
— 验证用户权限
SHOW GRANTS FOR ‘user’@’%’;

— 验证角色权限
SHOW GRANTS FOR ‘role’;
“`

– **步骤2**：验证数据安全
– 验证敏感数据加密
– 验证数据访问控制
– 验证审计日志

– **步骤3**：验证网络安全
– 验证网络访问控制
– 验证SSL/TLS配置
– 验证防火墙设置

## 5. 验证报告
– **步骤1**：整理验证结果
– 数据一致性验证结果
– 业务验证结果
– 性能验证结果
– 安全验证结果

– **步骤2**：生成验证报告
– 验证概述
– 验证方法
– 验证结果
– 问题和解决方案
– 建议和改进

– **步骤3**：评审验证报告
– 组织相关人员评审
– 确认验证结果
– 决定是否通过验证
– 确定下一步行动

风哥提示：验证是数据迁移的关键环节，通过全面的验证可以确保迁移后的数据质量和系统性能。from tidb视频:www.itpux.com

Part04-生产案例与实战讲解

4.1 从MySQL迁移到TiDB

# 从MySQL迁移到TiDB

## 1. 环境信息
– **源系统**：MySQL 5.7
– **目标系统**：TiDB 6.1.0
– **数据量**：500GB
– **迁移工具**：DM
– **网络带宽**：10Gbps

## 2. 迁移方案
– **迁移策略**：全量迁移+增量同步
– **迁移时间**：业务低峰期（周末）
– **验证方法**：数据一致性验证+业务验证
– **回滚策略**：备份源数据，准备回滚脚本

## 3. 实施步骤
– **步骤1**：部署DM集群
“`bash
tiup dm deploy dm-master v6.1.0 dm-master-topology.yaml –user root -p
tiup dm start dm-master
“`

– **步骤2**：配置迁移任务
“`yaml
# source.yaml
source-id: “mysql-1”
from:
host: “192.168.1.10”
port: 3306
user: “root”
password: “password”

# task.yaml
name: “mysql-to-tidb”
task-mode: “all”
target-database:
host: “192.168.1.20”
port: 4000
user: “root”
password: “password”
mysql-instances:
– source-id: “mysql-1”
block-allow-list:
bw-rule-1:
database: “test”
table: “%”
“`

– **步骤3**：启动迁移任务
“`bash
tiup dmctl –master-addr=”192.168.1.10:8261″ operate-source create source.yaml
tiup dmctl –master-addr=”192.168.1.10:8261″ create task.yaml
“`

– **步骤4**：监控迁移进度
“`bash
tiup dmctl –master-addr=”192.168.1.10:8261″ query-status mysql-to-tidb
“`

– **步骤5**：验证数据一致性
“`sql
— 源系统
SELECT COUNT(*) FROM test.table1;
— 目标系统
SELECT COUNT(*) FROM test.table1;
“`

– **步骤6**：执行业务切换
– 停止源系统的写入
– 等待增量同步完成
– 更新应用配置，指向TiDB
– 启动应用，连接TiDB

## 4. 遇到的问题与解决方案
– **问题1**：DM同步速度慢
– **解决方案**：调整DM worker-count和batch-size参数
“`yaml
sync:
worker-count: 16
batch-size: 10000
“`

– **问题2**：TiKV写入性能瓶颈
– **解决方案**：调整TiKV参数
“`toml
[rocksdb.defaultcf]
write-buffer-size = “1GB”
max-write-buffer-number = 4
“`

– **问题3**：网络带宽不足
– **解决方案**：优化网络配置，使用压缩传输

## 5. 迁移结果
– **迁移时间**：全量迁移4小时，增量同步2小时
– **数据一致性**：100%一致
– **业务影响**：业务中断10分钟
– **性能提升**：查询性能提升3倍，写入性能提升2倍

## 6. 经验总结
– **提前规划**：充分评估源系统和目标系统，制定详细的迁移计划
– **选择合适的工具**：根据数据量和源系统类型选择合适的迁移工具
– **监控和调优**：实时监控迁移进度，及时调整优化策略
– **验证充分**：进行全面的数据一致性验证和业务验证
– **准备回滚方案**：制定详细的回滚计划，确保可以及时回滚

4.2 从Oracle迁移到TiDB

# 从Oracle迁移到TiDB

## 1. 环境信息
– **源系统**：Oracle 11g
– **目标系统**：TiDB 6.1.0
– **数据量**：1TB
– **迁移工具**：应用程序迁移
– **网络带宽**：10Gbps

## 2. 迁移方案
– **迁移策略**：分批次迁移+增量同步
– **迁移时间**：业务低峰期（节假日）
– **验证方法**：数据一致性验证+业务验证
– **回滚策略**：备份源数据，准备回滚脚本

## 3. 实施步骤
– **步骤1**：分析源系统
– 分析Oracle数据库结构
– 识别Oracle特有的数据类型和约束
– 评估数据量和迁移复杂度

– **步骤2**：准备目标系统
– 部署TiDB集群
– 创建目标表结构（调整数据类型）
– 配置TiDB参数

– **步骤3**：开发迁移脚本
“`python
import cx_Oracle
import pymysql

# 连接Oracle
oracle_conn = cx_Oracle.connect(‘username/password@192.168.1.10:1521/orcl’)
oracle_cursor = oracle_conn.cursor()

# 连接TiDB
tidb_conn = pymysql.connect(host=’192.168.1.20′, port=4000, user=’root’, password=’password’, db=’test’)
tidb_cursor = tidb_conn.cursor()

# 分批次迁移
batch_size = 10000
offset = 0
while True:
# 从Oracle查询数据
oracle_cursor.execute(“SELECT * FROM source_table WHERE ROWNUM > :offset AND ROWNUM <= :offset + :batch_size", {'offset': offset, 'batch_size' : batch_size}) rows=oracle_cursor.fetchall() if not rows: break # 插入到TiDB sql="INSERT INTO target_table VALUES (%s, %s, %s)" tidb_cursor.executemany(sql, rows) tidb_conn.commit() offset +=batch_size print(f"Migrated {offset} rows") oracle_cursor.close() oracle_conn.close() tidb_cursor.close() tidb_conn.close() ``` - **步骤4**：执行全量迁移 - 运行迁移脚本，分批次迁移数据 - 监控迁移进度 - 处理迁移过程中的错误 - **步骤5**：配置增量同步 - 开发增量同步脚本 - 定时执行增量同步 - 监控增量同步状态 - **步骤6**：验证数据一致性 ```sql -- 源系统 SELECT COUNT(*) FROM source_table; -- 目标系统 SELECT COUNT(*) FROM target_table; ``` - **步骤7**：执行业务切换 - 停止源系统的写入 - 等待增量同步完成 - 更新应用配置，指向TiDB - 启动应用，连接TiDB ## 4. 遇到的问题与解决方案 - **问题1**：Oracle特有的数据类型 - **解决方案**：将Oracle特有的数据类型转换为TiDB支持的数据类型 - 示例：DATE → DATETIME, NUMBER → INT/FLOAT, CLOB → TEXT - **问题2**：迁移速度慢 - **解决方案**：使用多线程并行迁移 ```python import threading def migrate_batch(start, end): # 迁移逻辑 pass threads=[] for i in range(0, total_rows, batch_size): t=threading.Thread(target=migrate_batch, args=(i, i + batch_size)) threads.append(t) t.start() for t in threads: t.join() ``` - **问题3**：数据一致性问题 - **解决方案**：增加数据验证步骤，确保数据一致性 ## 5. 迁移结果 - **迁移时间**：全量迁移12小时，增量同步4小时 - **数据一致性**：100%一致 - **业务影响**：业务中断15分钟 - **性能提升**：查询性能提升5倍，写入性能提升3倍 ## 6. 经验总结 - **数据类型转换**：注意Oracle特有的数据类型，需要转换为TiDB支持的数据类型 - **分批次迁移**：对于大数据量，使用分批次迁移可以减少内存使用，提高迁移速度 - **并行处理**：使用多线程并行迁移可以充分利用硬件资源，提高迁移速度 - **增量同步**：配置增量同步可以确保数据的实时性和一致性 - **充分验证**：进行全面的数据一致性验证和业务验证，确保迁移成功

4.3 从PostgreSQL迁移到TiDB

# 从PostgreSQL迁移到TiDB

## 1. 环境信息
– **源系统**：PostgreSQL 12
– **目标系统**：TiDB 6.1.0
– **数据量**：300GB
– **迁移工具**：pg_dump + LOAD DATA
– **网络带宽**：10Gbps

## 3. 实施步骤
– **步骤1**：导出PostgreSQL数据
“`bash
# 导出数据为CSV格式
pg_dump -h 192.168.1.10 -p 5432 -U postgres -d test -t table1 –csv –no-headers > table1.csv
“`

– **步骤2**：准备目标系统
– 部署TiDB集群
– 创建目标表结构
– 配置TiDB参数

– **步骤3**：导入数据到TiDB
“`sql
— 导入数据
LOAD DATA LOCAL INFILE ‘/data/table1.csv’ INTO TABLE test.table1 FIELDS TERMINATED BY ‘,’ LINES TERMINATED
BY ‘\n’;
“`

– **步骤4**：配置增量同步
– 使用PostgreSQL的逻辑复制
– 开发增量同步脚本
– 定时执行增量同步

– **步骤5**：验证数据一致性
“`sql
— 源系统
SELECT COUNT(*) FROM test.table1;
— 目标系统
SELECT COUNT(*) FROM test.table1;
“`

– **步骤6**：执行业务切换
– 停止源系统的写入
– 等待增量同步完成
– 更新应用配置，指向TiDB
– 启动应用，连接TiDB

## 4. 遇到的问题与解决方案
– **问题1**：PostgreSQL特有的数据类型
– **解决方案**：将PostgreSQL特有的数据类型转换为TiDB支持的数据类型
– 示例：JSONB → JSON, TIMESTAMP WITH TIME ZONE → DATETIME

– **问题2**：导入速度慢
– **解决方案**：调整LOAD DATA参数，使用并行导入
“`sql
— 禁用Binlog
SET SESSION sql_log_bin = 0;
— 调整批量大小
SET SESSION tidb_batch_insert_size = 10000;
“`

– **问题3**：数据格式问题
– **解决方案**：在导出时调整数据格式，确保与TiDB兼容

## 5. 迁移结果
– **迁移时间**：全量迁移6小时，增量同步2小时
– **数据一致性**：100%一致
– **业务影响**：业务中断8分钟
– **性能提升**：查询性能提升4倍，写入性能提升2倍

## 6. 经验总结
– **数据格式转换**：注意PostgreSQL特有的数据格式，需要转换为TiDB兼容的格式
– **使用合适的导出工具**：pg_dump支持导出为CSV格式，适合TiDB的LOAD DATA导入
– **优化导入参数**：调整LOAD DATA参数可以提高导入速度
– **增量同步**：配置增量同步可以确保数据的实时性和一致性
– **充分验证**：进行全面的数据一致性验证和业务验证，确保迁移成功

4.4 大数据量迁移优化

# 大数据量迁移优化

## 1. 环境信息
– **源系统**：MySQL 5.7
– **目标系统**：TiDB 6.1.0
– **数据量**：5TB
– **迁移工具**：DM + mydumper
– **网络带宽**：25Gbps

## 2. 迁移方案
– **迁移策略**：分库分表迁移+增量同步
– **迁移时间**：业务低峰期（节假日）
– **验证方法**：数据一致性验证+业务验证
– **回滚策略**：备份源数据，准备回滚脚本

## 3. 实施步骤
– **步骤1**：评估源系统
– 分析源系统的数据库结构
– 评估数据量和分布
– 识别热点数据和大表

– **步骤2**：准备目标系统
– 部署TiDB集群（6个TiKV节点）
– 配置TiDB参数
– 准备足够的存储空间

– **步骤3**：优化源系统
“`sql
— 调整MySQL参数
SET GLOBAL innodb_max_dirty_pages_pct = 75;
SET GLOBAL innodb_io_capacity = 4000;
SET GLOBAL innodb_io_capacity_max = 8000;
“`

– **步骤4**：使用mydumper导出数据
“`bash
# 使用多线程导出
mydumper -h 192.168.1.10 -P 3306 -u root -p -B test -o /data/backup –threads=32 –compress
“`

– **步骤5**：使用DM导入数据
“`yaml
# task.yaml
name: “mysql-to-tidb”
task-mode: “all”
target-database:
host: “192.168.1.20”
port: 4000
user: “root”
password: “password”
mysql-instances:
– source-id: “mysql-1”
block-allow-list:
bw-rule-1:
database: “test”
table: “%”
sync:
worker-count: 32
batch-size: 20000
“`

– **步骤6**：监控迁移进度
“`bash
tiup dmctl –master-addr=”192.168.1.10:8261″ query-status mysql-to-tidb
“`

– **步骤7**：验证数据一致性
“`sql
— 源系统
SELECT COUNT(*) FROM test.table1;
— 目标系统
SELECT COUNT(*) FROM test.table1;
“`

– **步骤8**：执行业务切换
– 停止源系统的写入
– 等待增量同步完成
– 更新应用配置，指向TiDB
– 启动应用，连接TiDB

## 4. 遇到的问题与解决方案
– **问题1**：迁移速度慢
– **解决方案**：增加DM worker-count和batch-size参数，使用多线程导出
“`yaml
sync:
worker-count: 32
batch-size: 20000
“`

– **问题2**：TiKV存储压力大
– **解决方案**：增加TiKV节点，调整TiKV参数
“`toml
[storage.block-cache]
capacity = “128GB”

[rocksdb.defaultcf]
write-buffer-size = “2GB”
max-write-buffer-number = 4
“`

– **问题3**：网络带宽不足
– **解决方案**：使用25Gbps网络，启用数据压缩

## 5. 迁移结果
– **迁移时间**：全量迁移24小时，增量同步6小时
– **数据一致性**：100%一致
– **业务影响**：业务中断20分钟
– **性能提升**：查询性能提升6倍，写入性能提升4倍

## 6. 经验总结
– **分库分表迁移**：对于大数据量，使用分库分表迁移可以提高迁移速度
– **多线程导出**：使用mydumper的多线程导出功能可以提高导出速度
– **增加资源**：增加TiKV节点和网络带宽可以提高迁移速度
– **调优参数**：调整DM和TiKV参数可以提高迁移性能
– **监控和调优**：实时监控迁移进度，及时调整优化策略
– **充分验证**：进行全面的数据一致性验证和业务验证，确保迁移成功

Part05-风哥经验总结与分享

5.1 常见问题与解决方案

TiDB数据迁移的常见问题与解决方案：

# 常见问题与解决方案

## 1. 迁移速度慢
– **问题**：迁移速度达不到预期
– **解决方案**：
– 增加迁移工具的并发度
– 调整批量大小
– 优化源系统和目标系统的性能
– 增加网络带宽
– 使用多线程并行迁移

## 2. 数据一致性问题
– **问题**：迁移后数据与源系统不一致
– **解决方案**：
– 增加数据验证步骤
– 确保增量同步正常运行
– 处理数据类型转换问题
– 检查约束和索引

## 3. 业务中断时间长
– **问题**：迁移导致业务中断时间过长
– **解决方案**：
– 选择业务低峰期进行迁移
– 使用全量迁移+增量同步策略
– 优化迁移工具和参数
– 提前准备切换脚本

## 4. 系统性能下降
– **问题**：迁移过程中系统性能下降
– **解决方案**：
– 控制迁移的并发度
– 调整源系统和目标系统的参数
– 选择合适的迁移时间窗口
– 监控系统性能，及时调整

## 5. 迁移失败
– **问题**：迁移过程中出现错误，导致迁移失败
– **解决方案**：
– 检查迁移工具的日志
– 处理错误原因
– 重新启动迁移任务
– 准备回滚方案

## 6. 数据类型转换问题
– **问题**：源系统的特殊数据类型无法在TiDB中直接使用
– **解决方案**：
– 了解源系统和TiDB支持的数据类型
– 制定数据类型转换方案
– 测试数据类型转换的正确性
– 处理转换过程中的异常

## 7. 网络问题
– **问题**：网络中断或带宽不足导致迁移失败
– **解决方案**：
– 确保网络稳定
– 增加网络带宽
– 使用压缩传输
– 处理网络中断后的恢复

## 8. 存储空间不足
– **问题**：迁移过程中存储空间不足
– **解决方案**：
– 评估所需的存储空间
– 准备足够的临时存储空间
– 清理不需要的文件
– 监控存储空间使用情况

## 9. 权限问题
– **问题**：迁移过程中遇到权限不足的问题
– **解决方案**：
– 确保源系统和目标系统的用户权限足够
– 检查网络访问控制
– 处理权限相关的错误

## 10. 工具兼容性问题
– **问题**：迁移工具与源系统或目标系统不兼容
– **解决方案**：
– 选择合适的迁移工具
– 测试工具的兼容性
– 处理工具版本问题
– 开发自定义迁移脚本

5.2 最佳实践

TiDB数据迁移的最佳实践：

最佳实践：

提前规划：充分评估源系统和目标系统，制定详细的迁移计划
选择合适的工具：根据源系统类型和数据量选择合适的迁移工具
优化源系统：在迁移前优化源系统的性能和配置
优化目标系统：在迁移前优化目标TiDB集群的性能和配置
使用全量+增量策略：对于业务需要持续运行的场景，使用全量迁移+增量同步策略
分批次迁移：对于大数据量，使用分批次迁移可以减少内存使用，提高迁移速度
并行处理：使用多线程并行迁移可以充分利用硬件资源，提高迁移速度
监控和调优：实时监控迁移进度，及时调整优化策略
充分验证：进行全面的数据一致性验证和业务验证，确保迁移成功
准备回滚方案：制定详细的回滚计划，确保可以及时回滚
选择合适的迁移时间：选择业务低峰期进行迁移，减少对业务的影响
文档化迁移过程：记录迁移过程，包括遇到的问题和解决方案
培训和沟通：对相关人员进行培训，确保迁移过程顺利进行
持续监控：迁移后持续监控目标系统的性能和稳定性
优化和调整：根据迁移后的运行情况，持续优化和调整目标系统

5.3 方案选型指南

TiDB数据迁移方案的选型指南：

# 方案选型指南

## 1. 根据源系统类型选择
– **MySQL/MariaDB**：
– 推荐工具：DM
– 适用场景：全量迁移+增量同步
– 优势：自动化程度高，支持增量同步

– **Oracle**：
– 推荐工具：应用程序迁移
– 适用场景：分批次迁移+增量同步
– 优势：灵活性高，支持复杂的数据转换

– **PostgreSQL**：
– 推荐工具：pg_dump + LOAD DATA
– 适用场景：全量迁移+增量同步
– 优势：操作简单，适合中等数据量

– **其他数据库**：
– 推荐工具：应用程序迁移
– 适用场景：分批次迁移
– 优势：灵活性高，支持各种数据源

## 2. 根据数据量选择
– **小数据量**（<100GB）： - 推荐工具：mysqldump、pg_dump - 迁移策略：全量迁移 - 优势：操作简单，快速完成 - **中等数据量**（100GB-1TB）： - 推荐工具：DM、mydumper - 迁移策略：全量迁移+增量同步 - 优势：性能适中，支持增量同步 - **大数据量**（>1TB）：
– 推荐工具：DM + mydumper、应用程序迁移
– 迁移策略：分库分表迁移+增量同步
– 优势：性能高，支持大规模数据

## 3. 根据业务需求选择
– **业务可停机**：
– 迁移策略：全量迁移
– 优势：操作简单，一次性完成

– **业务不可停机**：
– 迁移策略：全量迁移+增量同步
– 优势：业务持续运行，迁移影响小

– **实时性要求高**：
– 迁移策略：实时同步
– 优势：数据实时同步，一致性高

– **数据转换需求**：
– 迁移策略：应用程序迁移
– 优势：支持复杂的数据转换

## 4. 根据网络条件选择
– **网络带宽充足**（>10Gbps）：
– 推荐工具：DM、mydumper
– 优势：迁移速度快

– **网络带宽有限**（<10Gbps）： - 推荐工具：应用程序迁移（支持压缩） - 优势：减少网络传输量 - **网络不稳定**： - 推荐工具：分批次迁移 - 优势：可以断点续传，减少网络影响 ## 5. 根据技术团队能力选择 - **技术团队经验丰富**： - 推荐工具：DM、应用程序迁移 - 优势：可以处理复杂的迁移场景 - **技术团队经验有限**： - 推荐工具：DTS、mysqldump - 优势：操作简单，自动化程度高 ## 6. 综合考虑因素 - **数据量**：数据量大小决定了迁移工具和策略的选择 - **源系统类型**：不同的源系统需要不同的迁移工具 - **业务需求**：业务的可用性要求决定了迁移策略 - **网络条件**：网络带宽和稳定性影响迁移工具和策略的选择 - **技术团队能力**：技术团队的经验和能力影响迁移工具的选择 - **时间要求**：迁移时间要求影响迁移策略的选择 - **预算限制**：预算限制影响迁移工具和硬件配置的选择 ## 7. 迁移方案评估 - **技术可行性**：评估迁移方案的技术可行性 - **风险评估**：评估迁移过程中的风险 - **成本评估**：评估迁移的成本 - **时间评估**：评估迁移所需的时间 - **性能评估**：评估迁移后系统的性能 ## 8. 迁移成功的关键因素 - **充分的规划**：详细的迁移计划是成功的关键 - **合适的工具**：选择合适的迁移工具可以提高迁移效率 - **优化的配置**：优化源系统和目标系统的配置可以提高迁移性能 - **全面的验证**：全面的数据一致性验证和业务验证可以确保迁移成功 - **有效的监控**：实时监控迁移进度可以及时发现和解决问题 - **完善的回滚方案**：完善的回滚方案可以在迁移失败时及时回滚 - **良好的沟通**：良好的沟通可以确保相关人员了解迁移过程 ## 9. 迁移后的优化 - **性能优化**：优化目标系统的性能 - **稳定性优化**：提高目标系统的稳定性 - **安全优化**：加强目标系统的安全性 - **监控优化**：完善目标系统的监控体系 - **维护优化**：建立目标系统的维护流程 ## 10. 总结 - **选择合适的迁移方案**：根据具体情况选择合适的迁移方案 - **充分准备**：迁移前充分准备，包括评估、规划和测试 - **严格执行**：严格按照迁移计划执行，确保迁移过程顺利 - **全面验证**：迁移后进行全面的验证，确保数据一致性和系统性能 - **持续优化**：迁移后持续优化目标系统，提高系统性能和稳定性

风哥提示：数据迁移是一个复杂的过程，需要综合考虑多个因素，选择合适的迁移方案，才能确保迁移成功。更多视频教程www.fgedu.net.cn

–
**数据一致性**：100%一致 – **业务影响**：业务中断15分钟 – **性能提升**：查询性能提升5倍，写入性能提升3倍 ## 6. 经验总结 –
**数据类型转换**：注意Oracle特有的数据类型，需要转换为TiDB支持的数据类型 – **分批次迁移**：对于大数据量，使用分批次迁移可以减少内存使用，提高迁移速度 –
**并行处理**：使用多线程并行迁移可以充分利用硬件资源，提高迁移速度 – **增量同步**：配置增量同步可以确保数据的实时性和一致性 – **充分验证**：进行全面的数据一致性验证和业务验证，确保迁移成功