TiDB 生态工具实践

CloudMamba 2021-05-24

725

最近因工作需要使用到TiDB数据库及TiDB生态工具。本篇主要阐述经过实践的TiDB 生态工具，在介绍TiDB 工具实践之前，先引用下TiDB的基础及架构内容。

TiDB 概念

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

TiDB 五大核心能力

•一键水平扩容或者缩容•金融级高可用•实时 HTAP•云原生的分布式数据库•兼容 MySQL 5.7 协议和 MySQL 生态

TiDB 架构

与传统的单机数据库相比，TiDB 具有以下优势：

纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

•TiDB Server：SQL 层对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。•PD (Placement Driver) Server: 整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。•存储节点 TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiDB 生态工具

•Dumpling 是一个用于从 MySQL/TiDB 进行全量逻辑导出的工具。•TiDB Lightning 是一个用于将全量数据导入到 TiDB 集群的工具。•BR （Backup & Restore）是一个对 TiDB 进行分布式备份和恢复的工具，可以高效地对大数据量的 TiDB 集群进行数据备份和恢复。•TiDB Binlog 是收集 TiDB 的增量 binlog 数据，并提供准实时同步和备份的工具。该工具可用于 TiDB 集群间的增量数据同步，如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群。•TiDB Data Migration (DM) 是将 MySQL/MariaDB 数据迁移到 TiDB 的工具，支持全量数据的迁移和增量数据的复制。•sync-diff-inspector 是一个用于校验 MySQL／TiDB 中两份数据是否一致的工具。该工具提供了修复数据的功能（适用于修复少量不一致的数据）。•Loader 是由 PingCAP 开发的数据导入工具，用于向 TiDB 中导入数据。（Loader 目前适用于v4.x 版本，官方已说明，目前已经不再维护，其功能已经完全被 TiDB Lightning 的 TiDB backend 功能取代，强烈建议切换到 TiDB Lightning。）•Syncer 是一个数据导入工具，能方便地将 MySQL 的数据增量导入到 TiDB。

TiDB 生态工具实践

本次我们需要借助TiDB的生态工具，将A Cloud 的MySQL 迁移至 B Cloud MySQL 环境中，经过多次的验证，发现采用TiDB 的Dumpling + Loader + Syncer 工具可以满足本次迁移需求。本次迁移的结构如下：：

•ACloud -MySQL （主）===> ACloud - MySQL （从） ====> B Cloud - MySQL (从)

安装工具

由于TiDB 生态工具组件非常简单，下载下来就可以直接使用，配置如下：

$ wget https://download.pingcap.org/tidb-toolkit-v4.0.11-linux-amd64.tar.gz
$ tar zxvf tidb-toolkit-v4.0.11-linux-amd64.tar.gz 
tidb-toolkit-v4.0.11-linux-amd64/
tidb-toolkit-v4.0.11-linux-amd64/bin/
tidb-toolkit-v4.0.11-linux-amd64/bin/br
tidb-toolkit-v4.0.11-linux-amd64/bin/tidb-lightning
tidb-toolkit-v4.0.11-linux-amd64/bin/mydumper
tidb-toolkit-v4.0.11-linux-amd64/bin/sync_diff_inspector
tidb-toolkit-v4.0.11-linux-amd64/bin/pd-tso-bench
tidb-toolkit-v4.0.11-linux-amd64/bin/tidb-lightning-ctl
tidb-toolkit-v4.0.11-linux-amd64/bin/tikv-importer
tidb-toolkit-v4.0.11-linux-amd64/bin/dumpling
$ mv tidb-toolkit-v4.0.11-linux-amd64 tidb-toolkit

$ wget https://download.pingcap.org/tidb-enterprise-tools-nightly-linux-amd64.tar.gz
$ tar zxvf tidb-enterprise-tools-nightly-linux-amd64.tar.gz 
tidb-enterprise-tools-nightly-linux-amd64/
tidb-enterprise-tools-nightly-linux-amd64/bin/
tidb-enterprise-tools-nightly-linux-amd64/bin/mydumper
tidb-enterprise-tools-nightly-linux-amd64/bin/loader
tidb-enterprise-tools-nightly-linux-amd64/bin/sync_diff_inspector
tidb-enterprise-tools-nightly-linux-amd64/bin/ddl_checker
tidb-enterprise-tools-nightly-linux-amd64/bin/importer
tidb-enterprise-tools-nightly-linux-amd64/bin/syncer

数据全量导出

数据全量导出推荐使⽤dumpling , 配置如下:

$ ./tidb-toolkit/bin/dumpling --database cluedtest --host 192.168.1.10 --port 3306 --user root --output="/tmp/data" -F 64M -t 16

查看备份的数据

$ cd data/
$ ls
cluedtest-schema-create.sql     cluedtest.test_innodb-schema.sql   cluedtest.test_myisam-schema.sql
cluedtest.test_innodb.000000000.sql cluedtest.test_myisam.000000000.sql metadata

数据导出成功，需要将数据拷贝至 B Cloud 端的一台实例（中间机器）上，再将其数据进行全量导入B Cloud 端的RDS MySQL 上。

创建目标端数据库

在B Cloud 上创建托管的RDS MySQL数据库，用于后面全量数据的导入/恢复，

选择MySQL 版本

设置Mysql 数据裤密码

选择数据库实例规格，这里根据源端MySQL 的规格，IOPS 进行对应的规格和参数。

选择云上指定的网络，子网组，由于是测试环境，所以这里允许了Public 访问，实际生产建议通过专线以及，内网的方式进行访问。

数据全量导入配置文件设定

当完成数据的全量导出后，可执⾏数据全量恢复，全量恢复可以通过lightning 和 loader ⼯具执⾏操作。本次采用的是loader ，Loader 不关⼼你下游是何种数据库，只要兼容MySQL 协议即可；配置文件设置如下：

$ cat loadconfig.toml

log-level = "info"
log-file = "/tmp/loader.log"
dir = "/tmp/data"
status-addr = ":8272"
checkpoint-schema = "tidb_loader"
pool-size = 16
[db]
host = "Your RDS MySQL Server Domain/IP"
user = "admin"
password = "123456"
port = 3306

执行数据全量导入

sudo ./tidb-enterprise-tools-nightly-linux-amd64/bin/loader -c=/home/ec2-user/loadconfig.toml

目标端数据库查看

mysql -h " Your RDS MySQL Server Domain/IP"  -u admin -p
Enter password: 
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 2057
Server version: 5.7.33-log Source distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> show databases;
+--------------------+
| Database      |
+--------------------+
| information_schema |
| awsdms_control   |
| cluedtest     |    ### 数据库导入成功
| innodb       |
| mysql       |
| performance_schema |
| sys        |
| tidb_loader    |
+--------------------+
8 rows in set (0.00 sec)

|  82206 | SL3QTM4QPuNnjhkBQjQ7 |    77 | 2021-05-14 03:51:03 |
|  82207 | 9LfKPMeDkyEpWmMFR9Zn |    56 | 2021-05-14 03:51:03 |
|  82208 | loNCzPgGs5T3sV7GQ3ys |    31 | 2021-05-14 03:51:03 |
|  82209 | PAjARl2YC0ZOV19x5CJC |    57 | 2021-05-14 03:51:03 |
|  82210 | FWzTyXZTjIvdqi5mmzDj |    35 | 2021-05-14 03:51:03 |
|  82211 | rw7SSz6CFgc2rV8MiXNU |    87 | 2021-05-14 03:51:03 |
|  82212 | h8FORIRX5nu9970xtAmS |    97 | 2021-05-14 03:51:03 |
|  82213 | SRsAo2S4BB3lmBO5QPom |    28 | 2021-05-14 03:51:03 |
|  82214 | YqZvsyiC3gYUuzdb9ZoQ |    69 | 2021-05-14 03:51:03 |

数据增量当完成全量数据导⼊，可以使⽤syncer 进⾏增量数据追加配置Meta 文件当你完成dumping 后，数据导出⽬录中⼀般都会⾃动⽣成metadata

SHOW MASTER STATUS:
Log: mysql-bin.000021
Pos: 559492058
GTID:
SHOW SLAVE STATUS:
Host: 10.10.16.6
Log: mysql-bin.000307
Pos: 65978528
GTID:

你可以使⽤上述⽂件中：

SHOW MASTER STATUS 的binlog 和pos信息, 来编辑meta⽂件。如上metadata ，⽣成的meta⽂件如下：（注：请使⽤master binlog 进⾏syncer）

binlog-name = "mysql-bin.000021"
binlog-pos = 559492058

Syncer 配置

在开始使用Syncer前，需进行Syncer 的配置文件 config.toml：

log-level = "info"
log-file = "/data/syncer.log"
log-rotate = "day"
server-id = 169044077
## meta ⽂件地址
meta = "./meta/ticktocks.meta"
worker-count = 16
batch = 100
flavor = "mysql"
## Prometheus 可以通过该地址拉取 Syncer metrics也是 Syncer 的 pprof 调试地址
status-addr = ":8271"
## 如果设置为 trueSyncer 遇到 DDL 语句时就会停⽌退出
stop-on-ddl = false
## SQL 请求由于⽹络异常等原因出错时的最⼤重试次数
max-retry = 100
## 推荐调过该语句，确保下游数据不出问题
skip-ddls = ["ALTER USER", "CREATE USER"]
[from]
host = "10.10.6.120"
user = "root"
password = "123456"
port = 3306
[to]
host = "10.101.10.11" 
user = "root"
password = "123456"
port = 4000

执行Syner 同步

./bin/syncer -config config.toml

数据验证

当我们通过执行完Syncer后，可通过8271 的端口来监控其增量数据的同步进行情况，待数据同步完成，可以通过下面的验证方

在源端执⾏SQL命令

SHOW MASTER STATUS;

⽬标源同样执⾏

SHOW MASTER STATUS;

对⽐binlog_pos 是否⽆限接近⼀致来判断增量同步进度，当前只是通过binlog_pos 比对了下，后期仍需结合业务进行数据的验证。

TiDB 生态工具实践

TiDB 概念

TiDB 五大核心能力

TiDB 架构

TiDB 生态工具

TiDB 生态工具实践

安装工具

数据全量导出

查看备份的数据

创建目标端数据库

数据全量导入配置文件设定

执行数据全量导入

目标端数据库查看

Syncer 配置

执行Syner 同步

数据验证

在源端执⾏SQL命令

⽬标源同样执⾏

推荐阅读

评论