给敏捷模式做下体检——多方位平凯数据库 TiDB 敏捷模式和 MySQL 的性能测试 (上)｜金融行业可参考
作者： TiDBer_FvfLzhd0 原文来源：https://tidb.net/blog/55666062
一、前言
企业 & 行业背景
本人从事金融行业运维工作，日常工作中偶尔涉及数据库相关操作。在当前信息技术应用创新和国产化替代的背景下，大环境下正积极引入具备分布式架构、强一致性且具备良好扩展性的数据库产品。TiDB 作为一款领先的分布式 NewSQL 数据库，其“敏捷模式”吸引了我的关注，本次重点围绕该模式展开技术调研与测试验证。
目前遇到的数据库挑战
随着业务规模不断扩大和监管政策趋严，行业临诸多关键挑战：传统集中式数据库（如 Oracle、MySQL）在面对高并发实时交易和海量数据批量处理时扩展能力有限，运维复杂度高、成本攀升；同时，在国产化转型过程中，需保障系统平滑迁移、数据一致性及业务连续性，对数据库产品的兼容性、稳定性及生态完整性提出了极高要求。
*** 3. 敏捷模式的体验总结 ***
敏捷模式的使用体验 TiDB 在敏捷模式下表现良好，通过标准基准测试及真实业务仿真，其在写入吞吐量、低延迟查询和故障恢复等关键指标上均符合预期，展现出良好的技术成熟度和工程可用性。
二、平凯数据库敏捷模式功能体验
本测试案例及数据分析均由研究者独立完成。鉴于个人研究条件的局限性，实验设计可能存在优化空间，数据采集与处理环节或有待完善之处。诚挚欢迎同行专家与读者对研究中任何不当之处提出宝贵意见。
1. 敏捷模式集群部署
1.1 概述
体验 TiDB 敏捷模式的部署与管理流程，通过 TiDB TEM 快速部署一套 TiDB 敏捷版集群，并验证其基本功能与性能优化效果。
1.2. 环境部署
1.2.1 硬件配置
TiDB 服务器：1 台 8 核 16GB 内存
TEM 管理服务器：1 台 2 核 4GB 内存
操作系统：RHEL 9.2 x86_64
2.2 软件准备
配置阿里云 CentOS Stream 9 yum 源
安装必要软件包：openssh-clients, openssh-server, tar
关闭防火墙和 SELinux
配置 SSH 互信
1.2.3 TEM 部署流程
系统初始化
TEM 安装
下载 TEM 安装包（tem-package-v3.0.0-linux-amd64.tar.gz）
解压并进入目录
修改配置文件中的 IP 地址为 TEM 主机 IP
4. 执行 install.sh 完成安装
# 访问 TEM，http://<TEM 部署 ip 地址 >:<port>/login
TEM 默认⽤户为 admin, 默认密码为 admin（请在登录后在 TEM 页面 - 设置 - 用户与角色 - 用户尽快修改）。
通过 http://192.168.151.100:8080/login 访问 TEM
默认用户：admin
默认密码：admin
1.2.4 TiDB 敏捷集群部署
TEM 配置
配置凭证：设置 → 凭证 → 主机 → 添加凭证
2. 导入组件：设置 → 组件管理 → 添加组件（导入 TiDB 敏捷模式安装包）
3. 配置中控机：主机 → 集群管理中控机 → 添加中控机
IP 地址：中控机 IP
SSH 端口：22（默认）
服务端口：9090（默认）
凭证：之前添加的 SSH 凭证
服务根目录：/root/tidb-cm-service
启用自动安装 TiUP
添加主机
主机 → 主机 → 添加共享主机
填写主机 IP、SSH 端口和对应凭证
创建集群
集群 → 创建集群
配置集群基本信息：
- 集群名称：自定义 - Root 用户密码：设置数据库 root 密码 - CPU 架构：x86_64 - 部署用户：tidb3. 选择中控机和集群版本 4. 选择 ” 共享 ” 部署模式 5. 规划集群节点： - 必须组件：PingKaiDB Fusion、Grafana、Prometheus、Alertmanager - 可选组件：TiFlash（用于 HTAP 功能测试）6. 完成创建并等待集群部署完成
1.2.5 集群验证
通过 TiDB Dashboard 验证
访问地址：{pd-ip}:{pd-port}/dashboard
使用 root 用户和设置的密码登录
验证集群各组件状态正常
通过 Grafana 监控验证
访问地址：{Grafana-ip}:3000
默认账户：admin/admin
查看 Overview 页面，确认监控数据正常
Prometheus 检查
确认所有 target 状态为 UP
1.2.6. 集群优化
通过 TEM SQL 编辑器执行以下优化参数：
1.2.7.MySQL 部署与配置
MySQL 8.4 安装
MySQL 优化配置
在 /etc/my.cnf.d/mysql-server.cnf 中添加：
1.2.8 测试工具部署
部署 sysbench
1. 概览
Sysbench 用于 OLTP 场景（短事务、高并发），我们以
oltp_read_write为示例。Sysbench 通过 MySQL 协议连接到 TiDB 的 MySQL 端口。
记录每一步的时间戳与日志，便于后续把性能变化与扩容操作关联。
2. 安装 Sysbench
校验：
3. Sysbench 使用示例（在 TiDB 上执行 OLTP 测试）
准备数据库（在 TiDB 上创建 sbtest DB）
准备 sysbench 数据（在压力机上）
示例命令：
--tables与--table-size根据测试需求调整。prepare阶段会在sbtest下建立表并插入数据。
运行（示例）
清理
关键命令
Sysbench prepare / run / cleanup
3. 性能进行对比分析
TiDB 与 MySQL Sysbench OLTP 性能测试对比
3.1 概述
本报告基于标准的 Sysbench OLTP 基准测试，对比了 TiDB 和 MySQL 在两个关键维度的性能表现：吞吐量 和 延迟。测试采用 128 个并发线程，持续运行约 10 分钟，以模拟高并发压力场景。
3.2 测试配置
3.3 总体性能数据对比
结论：在吞吐量（TPS/QPS）和延迟（平均延迟、95% 延迟、最大延迟）所有关键指标上，TiDB 优于 MySQL，性能提升约 46%，延迟降低约 31%。
3.4 详细分析
3.4.1 吞吐量 随时间变化分析
TiDB：
启动后快速爬升，在 40 秒后进入稳定状态。
在整个测试过程中表现极其稳定，TPS 稳定在 25-35 之间，且后期随着可能的热点优化，性能略有提升，峰值达到 37.29。
体现了分布式架构良好的扩展性和稳定性。
MySQL：
启动阶段性能波动巨大。
在 130s 至 150s 期间，出现了长达 20 秒 的性能崩溃，TPS 降至 0。这通常是由于严重的锁竞争、缓冲池不足、或磁盘 I/O 瓶颈导致的系统僵死。
恢复后性能波动依然明显，TPS 在 20-25 之间震荡。
3.4.2 延迟 (95th Percentile) 随时间变化分析
TiDB：
初始延迟较高，但迅速下降。
整个测试期间，95% 延迟非常稳定地集中在 6000ms - 8000ms 之间，表现出良好的性能。
MySQL：
延迟表现不稳定，出现了多次延迟尖峰。
在测试中期（100s-200s），95% 延迟多次飙升至 20000ms (20 秒) 以上，甚至最高达到 ~65000ms (65 秒)。
这意味着在此期间，95% 的用户请求需要等待数十秒才能得到响应。
稳定性与可靠性分析
TiDB：测试曲线平滑，无异常抖动或中断，证明了其分布式架构在高并发负载下的卓越稳定性。
MySQL：出现了严重的性能中断和极高的延迟抖动，表明在 128 线程的高并发压力下，单机架构遇到了严重的资源竞争或瓶颈。
3.5. 结论
结论
在此次 Sysbench OLTP 高并发测试中，TiDB 在性能、延迟和稳定性方面全方位显著优于 MySQL。
性能：TiDB 的吞吐量比 MySQL 高出 46%。
延迟：TiDB 的 95% 延迟比 MySQL 低 31%，且最大延迟降低了 87%，表现更加优秀。
稳定性：TiDB 提供了平滑稳定的性能输出，而 MySQL 出现了长时间的性能崩溃和剧烈的延迟抖动。
4. 压缩比测试
4.1 测试目标
对比对象：TiDB（使用 TiKV 存储引擎，默认启用压缩） vs MySQL（使用 InnoDB 存储引擎）。
核心指标：压缩比，计算公式为
MySQL 数据物理大小 / TiDB 数据物理大小。
4.2 测试环境与数据准备
测试数据：使用 Sysbench 的
oltp_write_only脚本在两库中生成完全相同的测试数据集（sbtest库下的sbtest1至sbtest5表）。数据规模：确保两库中的数据行数及表结构完全一致。经查询，两库中 5 张表的总行数均约为 1.28 亿行。
4.3 测试步骤
确保 TiKV 压缩完成：
使用 RocksDB 作为底层存储，其压缩过程由后台自动触发。为确保数据压缩到最紧凑状态，在测量前手动触发全集群压缩并等待完成。
# 登录到 TiKV 节点机器，找到 tikv-ctl 工具路径
操作命令：
等待压缩操作在后台完全结束（通常需等待数十分钟，取决于数据量）。
测量物理磁盘空间：
MySQL：测量其数据目录的总大小。
TiDB：测量所有 TiKV 实例数据目录的总大小。
查询逻辑数据大小：
分别在 MySQL 和 TiDB 中执行 SQL，查询测试表的逻辑数据长度，用于辅助分析压缩效率。
查询语句：
4.4 测试结果与分析
1. 物理磁盘空间使用对比
压缩比计算：51 GB / 27 GB ≈ 1.96
结论：在此测试中，TiDB 的存储效率约为 MySQL 的 2 倍。存储相同规模的数据，TiDB 所需磁盘空间比 MySQL 节省了近 50%。
2. 逻辑数据大小对比（参考）
分析：逻辑大小与物理大小的差异揭示了不同的存储机制。TiDB 显示出极高的逻辑行存储密度，这得益于其优化的存储格式和压缩算法。而物理大小的对比则直接体现了压缩算法在磁盘上的实际节省效果。
4.5 综合结论
优秀的压缩能力：TiDB 凭借其先进的存储引擎和默认启用的压缩算法，在此次测试中实现了 1.96:1 的压缩比，显著降低了磁盘空间使用，存储成本降低。
性能与压缩的平衡：结合前面的性能测试可知，TiDB 在提供高达 46% 性能提升的同时，并未因压缩操作而牺牲性能或带来显著延迟。其压缩过程在后台异步进行，对前端业务影响极小。
成本效益显著：对于数据密集型应用，采用 TiDB 不仅可以获得更好的性能和高可用性，还能有效削减存储成本，实现“降本增效”的双重目标。
5. Online DDL 测试
5.1 概述
对比 MySQL 和 TiDB 数据库在持续 OLTP 读写负载下执行各类 DDL 操作时的性能表现和对在线业务的影响。测试通过 Sysbench 模拟业务压力，并在后台执行 13 种不同类型的 DDL 操作，通过 DDL 执行时间和 Sysbench TPS 波动两个关键指标来评估数据库的 Online DDL 能力。
5.2 测试环境与方法
5.2.1 环境配置
数据库版本: mysql 8.4.6, TiDB 敏捷模式
硬件配置: VMware 虚拟机，8 核 CPU，16GB 内存，普通 SSD
测试表:
sbtest1(约 200 万行数据)
负载工具: Sysbench 1.0.20+
并发设置: 8 线程
测试时长: 单次 DDL 测试时间不等，总测试时间较长
5.2.2 测试方法
数据初始化: 使用 Sysbench 准备
sbtest1表，包含约 200 万行数据。创建主测试表
2. 负载模拟: 使用 Sysbench oltp_read_write脚本，启动 8 个线程，进行持续的读写混合负载
3. 性能监控: Sysbench 每秒报告一次 TPS（每秒事务数）、QPS、延迟及错误率。
4. DDL 执行: 在负载稳定运行后，在后台依次执行 13 项预定义的 DDL 操作。每个 DDL 操作后等待系统稳定.
5. 度量标准:
DDL 执行时间 (秒): 从执行开始到结束的耗时。
3. 详细 DDL 操作对比分析
DDL 1: 增加索引（普通索引）
指标
TiDB：执行时间 ~9.23 s；平均 TPS 117.95；最低 66.99
MySQL：执行时间 ~29.60 s；平均 TPS 87.39；最低 0.00（存在多次归零 / 阻塞片段），最大峰值日志记录偏高
分析 TiDB 在建索引期间并未把写入完全阻塞（TPS 有下降但未归零），耗时显著短于 MySQL（约为 MySQL 的 31%）。MySQL 在索引构建阶段出现长期或间歇性 TPS 为 0，说明表重建 / 写锁导致业务可写中断或短暂失去吞吐。
DDL 2: 删除索引
指标
TiDB：执行时间 ~0.64 s；TPS 保持 136–152
MySQL：执行时间 ~26.18 s；平均 TPS 0.59，最小 0.00（长期为 0）
分析 TiDB 删除索引几乎瞬时完成，对并发写入无影响。MySQL 删除索引在本次测试表现为需要重建 / 重写，导致业务在该操作期间完全中断。
DDL 3: 重命名索引
指标
TiDB：执行时间 ~0.231 s；平均 TPS 126.51
MySQL：执行时间 ~0.056 s；平均 TPS 1192.66，分析双方均为瞬时 / 元数据级操作，几乎不影响并发写入。MySQL 在此类元数据操作上表现非常快速，TiDB 也表现良好。
DDL 4: 混合索引操作（增 / 删索引混合）
指标
TiDB：执行时间 ~19.45 s；平均 TPS 101.60；最低 58.83
MySQL：执行时间 ~523.77 s（非常长）；平均 TPS 26.34；最低 0.00（长时阻塞）
分析此类复合操作对 MySQL 极为不友好（本次几乎耗时 8.7 分钟且伴随长时间 TPS 为 0），而 TiDB 能在较短时间内并行完成，吞吐影响有限。混合索引变更是 MySQL 的高风险项。
DDL 5: 添加 VIRTUAL 列（生成列）
指标
TiDB：执行时间 ~0.64 s；平均 TPS 116.67；最低 91.04
MySQL：执行时间 ~20.61 s；平均 TPS 10.76；最低 0.00
分析 TiDB 添加虚拟列几乎无侵入；MySQL 在本测试中添加虚拟列导致显著写入中断 / 抖动，因此 MySQL 的生成列添加在该版本下表现不稳定。
DDL 6: 删除 VIRTUAL 列
指标
TiDB：执行时间 ~0.703 s；平均 TPS 132.66
MySQL：执行时间 ~0.064 s；平均 TPS 1225.08
分析删除生成列对两者均为快操作（MySQL 在删除时表现也很好）。因此删除虚拟列不是问题点。
DDL 7: 修改列为 NULL
指标
TiDB：执行时间 ~0.19 s；平均 TPS 134.43
MySQL：执行时间 ~26.85 s；平均 TPS 48.71；最低 0.00
分析 TiDB 几乎瞬时完成该元数据 / 小变更。MySQL 在此项上表现差很多并有阻塞，说明 MySQL 在一些列属性变更上仍可能触发表重建 / 阻塞路径。
DDL 8: 设列默认值
指标
TiDB：执行时间 ~0.231 s；平均 TPS 131.12
MySQL：执行时间 ~30.151 s；平均 TPS 110.56；最低 0.00（有短阻塞）分析 TiDB 快速完成，MySQL 耗时较长且存在 TPS 归零片段（影响不如某些长阻塞那么严重，但仍需注意）。
DDL 9: 修改自增列值
指标
TiDB：执行时间 ~0.161 s；平均 TPS 131.14
MySQL：执行时间 ~0.056 s；平均 TPS 1238.02 分析此类为典型元数据操作，双方均为瞬时完成且对业务无影响。
DDL 10: 增加列类型长度
指标
TiDB：执行时间 ~0.202 s；平均 TPS 130.50
MySQL：执行时间 ~250.773 s；平均 TPS 16.40；最低 0.00 分析 TiDB 对“扩展列长度”处理非常高效（几乎瞬时），而 MySQL 需要大量时间且在此过程里写入接近停滞。对于大表，这类差异会被放大。
DDL 11: 中间加列
指标
TiDB：执行时间 ~0.755 s；平均 TPS 132.75
MySQL：执行时间 ~0.057 s；平均 TPS 1377.95 分析两者均快速完成。MySQL 在“中间加列”上的快速完成可能与该版本支持在不重写全表的情况下完成该变更，或日志采样时的特殊性。总之该项不是主要风险点。
DDL 12: 重排列
指标
TiDB：执行时间 ~0.197 s；平均 TPS 127.35
MySQL：执行时间 ~126.051 s；平均 TPS 2.82；最低 0.00 分析 TiDB 能在线重排列而耗时极短；MySQL 在本次测试中需要长时间复制 / 重建表，导致业务基本停顿。若需在 MySQL 上重排列序，必须提前规划维护窗口或使用在线 schema-change 工具。
DDL 13: 修改列类型
指标
TiDB：执行时间 ~90.667 s；平均 TPS 76.36；最低 0.00（存在短时停顿）
MySQL：执行时间 ~295.310 s；平均 TPS 5.11；最低 0.00（长期停滞）
分析修改列类型属于需要“重写数据”的重型 DDL。TiDB 用时显著低于 MySQL（约 1/3），且恢复更快；MySQL 在近 5 分钟的窗口里对写入几乎完全阻塞。对大表生产环境影响尤为严重。
总体结论：在本次 8 线程、200 万行表的并发写入场景下，TiDB 的 Online DDL 能力优于 MySQL：多数 DDL 在 TiDB 上是在线、耗时短且对 DML 影响小；MySQL 在涉及表重写 / 重建的 DDL（例如混合索引变更、改列类型 / 长度、删除索引、重排列等）中会出现严重阻塞。
6. 数据迁移体验
6.1 概述
记录和总结使用 TiDB Data Migration (DM) 工具，从 MySQL 数据库到 TiDB 集群进行全量及增量数据迁移的实际操作体验。本次迁移基于官方推荐的单服务器架构进行，流程涵盖了环境准备、DM 集群部署、数据源配置、迁移任务创建与执行等关键环节，使用 TiDB DM 迁移的流程如下图所示。
6.2 测试环境配置
6.3 迁移操作流程
**** 前提条件
使用 TiUP 安装 DM 集群
DM 所需上下游数据库权限
6.3.1 使用 TiUP 安装 DM 集群
在中控机上安装 TiUP 组件
使用普通用户登录中控机，以 tidb 用户为例，后续安装 TiUP 及集群管理操作均通过该用户完成：
执行如下命令安装 TiUP 工具：
安装完成后，~/.bashrc 已将 TiUP 加入到路径中，新开一个终端或重新声明全局变量 source ~/.bashrc 来使用 TiUP。
6.3.2. 安装 TiUP DM 组件：
编辑初始化配置文件
请根据不同的集群拓扑，编辑 TiUP 所需的集群初始化配置文件。
请根据配置文件模板，新建一个配置文件 topology.yaml。如果有其他组合场景的需求，请根据多个模板自行调整。
可以使用 tiup dm template > topology.yaml 命令快速生成配置文件模板。
部署 1 个 DM-master、1 个 DM-worker 与 1 个监控组件的配置如下：
按照自己测试的情况配置好文件后部署 dm 工具
tiup dm deploy dm-test v9.0.0-beta.1 ./topology.yaml --user root -p
查看 TiUP 管理的集群情况
tiup dm list
TiUP 支持管理多个 DM 集群，该命令会输出当前通过 TiUP DM 管理的所有集群信息，包括集群名称、部署用户、版本、密钥信息等：
Name User Version Path PrivateKey—- —- ——- —- ———-dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa
检查部署的 DM 集群情况
例如，执行如下命令检查 dm-test 集群情况：
tiup dm display dm-test
预期输出包括 dm-test 集群中实例 ID、角色、主机、监听端口和状态（由于还未启动，所以状态为 Down/inactive）、目录信息。
启动集群
tiup dm start dm-test
预期结果输出 Started cluster `dm-test` successfully 表示启动成功。
验证集群运行状态
通过以下 TiUP 命令检查集群状态：
tiup dm display dm-test
在输出结果中，如果 Status 状态信息为 Up，说明集群状态正常。
使用 dmctl 管理迁移任务
6.4 开始做迁移工作：
1、创建 DM 专用用户：
-- 创建用户，允许从任何主机连接（根据你的网络环境调整）
-- 授予 DM 所需的权限
GRANT SELECT ON *.* TO 'dm_user'@'%';
-- 刷新权限
FLUSH PRIVILEGES;
2、开启 GTID 的步骤：
检查当前 GTID 状态：连接上游 MySQL 数据库，执行以下命令查看当前的 GTID 模式：
SHOW GLOBAL VARIABLES LIKE 'GTID_MODE';
修改 MySQL 的配置文件（如 my.cnf 或 my.ini），在 [mysqld] 段添加：
3、创建数据源
首先，新建 source1.yaml 文件，写入以下内容：
tiup dmctl --master-addr 192.168.151.103:8261 operate-source create source1.yaml
4、创建迁移任务
新建 task1.yaml 文件，写入以下内容：
以上内容为执行迁移的最小任务配置。关于任务的更多配置项，可以参考 DM 任务完整配置文件介绍。
5、启动任务
在启动数据迁移任务之前，建议使用 check-task 命令检查配置是否符合 DM 的配置要求，以避免后期报错。
tiup dmctl --master-addr 192.168.151.103:8261 check-task task.yaml
由于我这里使用的是 MySQL 8.4.6，一开始是使用全量 + binlog 迁移，出现了几个关于这个版本的报错。
> 1. Binlog 检查失败 > 错误信息: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'MASTER STATUS' at line 1 > > 原因分析: 在 MySQL 8.4.6 中，SHOW MASTER STATUS 这个命令可能已经被弃用或语法发生了变化。DM 在检查 binlog 配置时仍然使用了旧的语法。 > > 解决方案: > > > > 考虑使用一个兼容性更好的 MySQL 版本（如 5.7 或 8.0 的某个稳定版本）作为数据源。这是目前最稳妥的解决办法。 > > 2. MySQL 版本警告 > 警告信息: version suggested earlier than 8.1.0 but got 8.4.6 > > 原因分析: 使用的 MySQL 8.4.6 版本相对较新，可能超出了 DM 当前充分测试和官方支持的范围，存在未知兼容性风险。 > > 解决方案: > > 建议降级 MySQL 版本至 DM 官方支持更好的版本（例如 MySQL 5.7 或 8.0 系列）。 > ``` 后面改为全量迁移，忽略mysql版本，直接进行数据迁移。 使用 tiup dmctl 执行以下命令启动数据迁移任务。markdowntiup dmctl –master-addr 192.168.151.103:8261 start-task task.yaml
执行后会输出以下信息markdown[root@localhost ~]# tiup dmctl –master-addr 192.168.151.103:8261 start-task task1.yamlStarting component dmctl: /root/.tiup/components/dmctl/v8.5.3/dmctl/dmctl –master-addr 192.168.151.103:8261 start-task task1.yaml{ “result”: true, “msg”: “”, “sources”: [ { “result”: true, “msg”: “”, “source”: “mysql-01”, “worker”: “dm-192.168.151.103-8262” } ], “checkResult”: “fail to check synchronization configuration with type: no errors but some warnings detail: { “results”: [ { “id”: 0, “name”: “dumper_conn_number_checker”, “desc”: “check if connetion concurrency exceeds database’s maximum connection limit”, “state”: “warn”, “errors”: [ { “severity”: “warn”, “short_error”: “lack of Process global (.) privilege; “ } ] }, { “id”: 3, “name”: “mysql_version”, “desc”: “check whether mysql version is satisfied”, “state”: “warn”, “errors”: [ { “severity”: “warn”, “short_error”: “version suggested earlier than 8.1.0 but got 8.4.6” } ], “instruction”: “It is recommended that you select a database version that meets the requirements before performing data migration. Otherwise data inconsistency or task exceptions might occur.”, “extra”: “address of db instance - 192.168.151.102:3306” }, { “id”: 5, “name”: “table structure compatibility check”, “desc”: “check compatibility of table structure”, “state”: “warn”, “errors”: [ { “severity”: “warn”, “short_error”: “table
tpch.ordersForeign Key orders_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.partsuppForeign Key partsupp_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.partsuppForeign Key partsupp_ibfk_2 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.supplierForeign Key supplier_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.customerForeign Key customer_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.nationForeign Key nation_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.lineitemForeign Key lineitem_ibfk_1 is parsed but ignored by TiDB.” }, { “severity”: “warn”, “short_error”: “tabletpch.lineitemForeign Key lineitem_ibfk_2 is parsed but ignored by TiDB.” } ], “instruction”: “TiDB does not support foreign key constraints. See the document: https://docs.pingcap.com/tidb/stable/mysql-compatibility#unsupported-features" } ], “summary”: { “passed”: true, “total”: 6, “successful”: 3, “failed”: 0, “warning”: 3 } }”}可以通过以下命令**查看任务状态**，确认同步是否正在进行：tiup dmctl –master-addr 192.168.151.103:8261 query-status
如果之后想**暂停任务**，可以使用：tiup dmctl –master-addr 192.168.151.103:8261 pause-task test # test 是你的任务名
需要**继续任务**时，使用：tiup dmctl –master-addr 192.168.151.103:8261 resume-task test```
6.5 整体体验与优势总结
开箱即用，部署简单： TiUP 工具链极大地简化了集群的安装、部署和管理流程，是 TiDB 生态体系的巨大优势。
配置化与自动化： 全程通过 YAML 文件进行配置，声明式的方法易于版本管理和复用。操作命令化，自动化程度高。
功能完善，稳定可靠：
GTID 支持： 对上游高可用架构的兼容性好。
预检查机制： 防患于未然，提升了操作的成功率和体验。
灵活的任务模式： 满足不同场景下的迁移需求。
集中监控： 集成 Prometheus 和 Grafana，可以方便地监控迁移延迟、吞吐量、错误等信息，便于观察迁移状态和性能调优。
6.6 注意事项与建议
资源占用： 在单台服务器上部署所有组件，虽然简单，但需要注意资源争用问题。在生产环境中，建议将 DM-worker 单独部署，并确保其有足够的 I/O 和 CPU 资源来处理数据加载和 binlog 同步，以避免成为性能瓶颈。
其中有一个小插曲，可能由于我的敏捷部署资源分配不够。导致数据迁移到 tidb 集群时候出现多次 OOM 和多种告警，历时一个下午才把测试的数据迁移完。
网络与防火墙： 确保 DM 组件与上游 MySQL、下游 TiDB 之间的网络连通性，以及相关端口（如 MySQL 3306, DM-master 8261, DM-worker 8262）的防火墙规则已正确开放。
版本兼容性： 注意上游 MySQL 版本和 TiDB DM 版本的兼容性列表，避免使用未经验证的版本组合。
6.7 结论
本次使用 TiDB DM 进行数据迁移的体验非常积极。整个过程文档清晰、流程标准化、工具自动化程度高。从零开始搭建迁移环境到任务成功运行，没有遇到不可解决的障碍。
对于有计划将 MySQL 数据迁移至 TiDB 的用户，DM 是一个值得推荐的首选工具。它在易用性、功能性和可靠性之间取得了良好的平衡，能够高效地完成数据迁移这一复杂任务。
7. 可扩展性测试
7.1 测试目标
节点扩展性：验证集群从 1 个 TiDB/TiKV 节点无缝扩展到 3 个 TiDB/TiKV 节点时，在线业务的性能提升比例和数据一致性。
功能扩展性：验证在现有集群中动态添加 TiFlash、TiCDC、BR 等关键组件时，集群的兼容性、稳定性，以及对现有 OLTP 业务性能的影响。
7.2. 测试过程
第一部分：节点扩展性测试
测试环境与工具
TiDB 集群：TiDB 敏捷模式
初始架构：1x PD, 1x TiDB, 1x TiKV
目标架构：3x PD, 3x TiDB, 3x TiKV
压力工具：Sysbench
数据规模：5 张表，每张表 1000 万行数据 (-t 5 –table-size=10000000)
监控工具：TEM
测试目的：测量从 1 节点扩展到 3 节点过程中，系统性能的变化，并确保数据无丢失、无错乱。
测试步骤分为四个阶段：
阶段 1：空载监控 60 秒
阶段 2：负载测试 60 秒
阶段 3：负载测试 600 秒 + 扩容第一节点 + 扩容第二节点
阶段 4：扩容后负载测试 120 秒
手动记扩容开始结束时间，根据 sysbench 的输出结果统计采样点并进行对比。
下面表格每行的数字均来自对应日志的采样点统计；
扩容前短跑 TPS 在 ~360+，而扩容后短跑 TPS 在 ~130 左右，约下降到原来的 36% 左右。来源：扩容前 / 扩容后各自日志。
在 “扩容中”（同一 600s run）能看到两个明显的下降阶段：第 1 次扩容（100–250s）使 TPS 从 ~340 降到 ~276（约 19% 降幅）；第 2 次扩容（350–470s）进一步降到 ~226（相比扩容前窗口再降 ~33%）。
总体趋势是：扩容操作期间和之后延迟上升、吞吐下降。
扩容后集群稳定后恢复接近基线
对集群部署了 HA 之后又测了一轮：
量化变化
Aggregate TPS 变化（三节点 vs 扩容前负载单节点）：-14.6719 eps → -4.04%（下降约 4.04%）。（计算：(348.2836 - 362.9555) / 362.9555 × 100 = -4.0423%）
平均延迟：从 176.20 ms → 183.72 ms，+7.52 ms（+4.27%）。
p95 延迟：从 219.36 ms → 308.84 ms，+89.48 ms（+40.80%）。
max 延迟剧增：从 1.95 s → 6.80 s（极端 outlier）。
简短结论：吞吐略降 ~4%（几乎相当），但高分位延迟明显变差（p95 +41%），并出现极端最大延迟样本。这意味着系统在长 run/ 三节点环境下总体吞吐可接受，但尾部延迟与短时可用性出现问题。
集群性能变化
下面扩容阶段的一些性能指标：
7.3 阶段性结论
同次 run 的后期（471–600s）和独立的扩容后 run 都显示了 显著低于扩容前的吞吐（tps ~140 左右）与更高延迟（95% median 在 400–650ms 区间）。独立“扩容后”短跑，确认了扩容完成后系统在短期内未恢复到扩容前性能。
注意：同次 run 的最后阶段出现了若干“0 TPS”与单个极端超高延迟点（lat95 = 42134ms），表明在扩容过程或其后期可能发生短暂的服务不可用或长时间阻塞。
典型表现：TPS 再次下降到 ~226，95% 延迟中位数进一步上升到 ~370ms，90% 分位甚至接近 490ms。
说明：第二次扩容带来的影响更大（比第一次更显著）。可能因为第一次扩容期间集群尚未稳定（副本 /region 未完全同步），第二次扩容在未完成前一次收敛的情况下继续加入节点，造成更大的数据迁移、调度压力或短时元数据冲突。
典型表现：TPS 从 ~340→~276，95% 延迟从 ~227ms → ~262ms（median/avg 同比上升）。
说明：扩容第一节点期间系统出现明显性能下降与更多延迟抖动，但没有出现 0 TPS 的完全中断现象。可能在做数据迁移 / 副本同步 / 元数据变更时引入了额外负载与锁等待。
7.4 结论
本次测试显示：扩容操作对数据库性能有明显负面影响——扩容期间 TPS 与 QPS 明显下降、延迟上升；扩容完成后的短期内系统未恢复到扩容前性能，待集群稳定后性能恢复原有水平。
因篇幅所限，本文的完整内容将分为上下两篇发布，后续高可用测试、TEM 易用性等内容详见即将发布的第二部分
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/5eb2464aec75f6cb57b192a78】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论