- 文档中心
- 关于 TiDB
- 快速上手
- 部署标准集群
- 数据迁移
- 运维操作
- 监控与告警
- 故障诊断
- 性能调优
- 系统调优
- 软件调优
- SQL 性能调优
- SQL 性能调优概览
- 理解 TiDB 执行计划
- SQL 优化流程
- 控制执行计划
- 教程
- 同城多中心部署
- 两地三中心部署
- 同城两中心部署
- 读取历史数据
- 使用 Stale Read 功能读取历史数据(推荐)
- 使用系统变量
tidb_snapshot
读取历史数据
- 最佳实践
- Placement Rules 使用文档
- Load Base Split 使用文档
- Store Limit 使用文档
- TiDB 工具
- 功能概览
- 适用场景
- 工具下载
- TiUP
- 文档地图
- 概览
- 术语及核心概念
- TiUP 组件管理
- FAQ
- 故障排查
- TiUP 命令参考手册
- 命令概览
- TiUP 命令
- TiUP Cluster 命令
- TiUP Cluster 命令概览
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUP DM 命令
- TiUP DM 命令概览
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDB 集群拓扑文件配置
- DM 集群拓扑文件配置
- TiUP 镜像参考指南
- TiUP 组件文档
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB Data Migration
- Backup & Restore (BR)
- TiDB Binlog
- TiCDC
- TiUniManager
- sync-diff-inspector
- TiSpark
- 参考指南
- 架构
- 监控指标
- 安全加固
- 权限
- SQL
- SQL 语言结构和语法
- SQL 语句
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER USER
ANALYZE TABLE
BACKUP
BEGIN
CHANGE COLUMN
CHANGE DRAINER
CHANGE PUMP
COMMIT
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
RENAME USER
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW [BACKUPS|RESTORES]
SHOW ANALYZE STATUS
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- 数据类型
- 函数与操作符
- 聚簇索引
- 约束
- 生成列
- SQL 模式
- 表属性
- 事务
- 垃圾回收 (GC)
- 视图
- 分区表
- 临时表
- 字符集和排序
- Placement Rules in SQL
- 系统表
mysql
- INFORMATION_SCHEMA
- Overview
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_RULES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- CLI
- 命令行参数
- 配置文件参数
- 系统变量
- 存储引擎
- 遥测
- 错误码
- 通过拓扑 label 进行副本调度
- 常见问题解答 (FAQ)
- 版本发布历史
- 术语表
你正在查看 TiDB 数据库的较旧版本 (TiDB v5.4) 的文档。
从 Amazon Aurora 迁移数据到 TiDB
本文档介绍如何从 Amazon Aurora 迁移数据到 TiDB,迁移过程采用 DB snapshot,可以节约大量的空间和时间成本。整个迁移包含两个过程:
- 使用 Lightning 导入全量数据到 TiDB
- 使用 DM 持续增量同步到 TiDB(可选)
前提条件
导入全量数据到 TiDB
第 1 步: 导出 Aurora 快照文件到 Amazon S3
在 Aurora 上,执行以下命令,查询并记录当前 binlog 位置:
mysql> SHOW MASTER STATUS;
你将得到类似以下的输出,请记录 binlog 名称和位置,供后续步骤使用:
+------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000002 | 52806 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.012 sec)
导出 Aurora 快照文件。具体方式请参考 Aurora 的官方文档:Exporting DB snapshot data to Amazon S3.
请注意,上述两步的时间间隔建议不要超过 5 分钟,否则记录的 binlog 位置过旧可能导致增量同步时产生数据冲突。
完成上述两步后,你需要准备好以下信息:
- 创建快照点时,Aurora binlog 的名称及位置。
- 快照文件的 S3 路径,以及具有访问权限的 SecretKey 和 AccessKey。
第 2 步: 导出 schema
因为 Aurora 生成的快照文件并不包含建表语句文件,所以你需要使用 Dumpling 自行导出 schema 并使用 Lightning 在下游创建 schema。你也可以跳过此步骤,并以手动方式在下游自行创建 schema。
运行以下命令,建议使用 --filter
参数仅导出所需表的 schema:
tiup dumpling --host ${host} --port 3306 --user root --password ${password} --filter 'my_db1.table[12]' --no-data --output 's3://my-bucket/schema-backup?region=us-west-2' --filter "mydb.*"
命令中所用参数描述如下。如需更多信息可参考 Dumpling overview。
参数 | 说明 |
---|---|
-u 或 --user | Aurora MySQL 数据库的用户 |
-p 或 --password | MySQL 数据库的用户密码 |
-P 或 --port | MySQL 数据库的端口 |
-h 或 --host | MySQL 数据库的 IP 地址 |
-t 或 --thread | 导出的线程数 |
-o 或 --output | 存储导出文件的目录,支持本地文件路径或外部存储 URL 格式 |
-r 或 --row | 单个文件的最大行数 |
-F | 指定单个文件的最大大小,单位为 MiB, 建议值 256 MiB |
-B 或 --database | 导出指定数据库 |
-T 或 --tables-list | 导出指定数据表 |
-d 或 --no-data | 不导出数据,仅导出 schema |
-f 或 --filter | 导出能匹配模式的表,不可用 -T 一起使用,语法可参考table filter |
第 3 步: 编写 Lightning 配置文件
根据以下内容创建tidb-lightning.toml
配置文件:
vim tidb-lightning.toml
[tidb]
# 目标 TiDB 集群信息.
host = ${host} # 例如:172.16.32.1
port = ${port} # 例如:4000
user = "${user_name}" # 例如:"root"
password = "${password}" # 例如:"rootroot"
status-port = ${status-port} # 表结构信息在从 TiDB 的“状态端口”获取例如:10080
pd-addr = "${ip}:${port}" # 集群 PD 的地址,lightning 通过 PD 获取部分信息,例如 172.16.31.3:2379。当 backend = "local" 时 status-port 和 pd-addr 必须正确填写,否则导入将出现异常。
[tikv-importer]
# "local":默认使用该模式,适用于 TB 级以上大数据量,但导入期间下游 TiDB 无法对外提供服务。
# "tidb":TB 级以下数据量也可以采用`tidb`后端模式,下游 TiDB 可正常提供服务。 关于后端模式更多信息请参阅:https://docs.pingcap.com/tidb/stable/tidb-lightning-backends
backend = "local"
# 设置排序的键值对的临时存放地址,目标路径必须是一个空目录,目录空间须大于待导入数据集的大小,建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质,独占 IO 会获得更好的导入性能。
sorted-kv-dir = "${path}"
[mydumper]
# 快照文件的地址
data-source-dir = "${s3_path}" # eg: s3://my-bucket/sql-backup?region=us-west-2
[[mydumper.files]]
# 解析 parquet 文件所需的表达式
pattern = '(?i)^(?:[^/]*/)*([a-z0-9_]+)\.([a-z0-9_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$'
schema = '$1'
table = '$2'
type = '$3'
如果需要在 TiDB 开启 TLS ,请参考 TiDB Lightning Configuration。
第 4 步: 导入全量数据到 TiDB
使用 Lightning 在下游 TiDB 建表:
tiup tidb-lightning -config tidb-lightning.toml -d 's3://my-bucket/schema-backup?region=us-west-2' -no-schema=false
运行
tidb-lightning
。如果直接在命令行中启动程序,可能会因为SIGHUP
信号而退出,建议配合nohup
或screen
等工具,如:将有权限访问该 Amazon S3 后端存储的账号的 SecretKey 和 AccessKey 作为环境变量传入 Lightning 节点。同时还支持从
~/.aws/credentials
读取凭证文件。export AWS_ACCESS_KEY_ID=${access_key} export AWS_SECRET_ACCESS_KEY=${secret_key} nohup tiup tidb-lightning -config tidb-lightning.toml -no-schema=true > nohup.out 2>&1 &
导入开始后,可以采用以下任意方式查看进度:
- 通过
grep
日志关键字progress
查看进度,默认 5 分钟更新一次。 - 通过监控面板查看进度,请参考 TiDB Lightning 监控。
- 通过 Web 页面查看进度,请参考 Web 界面。
- 通过
导入完毕后,TiDB Lightning 会自动退出。查看日志的最后 5 行中会有
the whole procedure completed
,则表示导入成功。
无论导入成功与否,最后一行都会显示 tidb lightning exit
。它只是表示 TiDB Lightning 正常退出,不代表任务完成。
如果导入过程中遇到问题,请参见 TiDB Lightning 常见问题。
持续增量同步数据到 TiDB(可选)
前提条件
第 1 步: 创建数据源
新建
source1.yaml
文件, 写入以下内容:# 唯一命名,不可重复。 source-id: "mysql-01" # DM-worker 是否使用全局事务标识符 (GTID) 拉取 binlog。使用前提是上游 MySQL 已开启 GTID 模式。若上游存在主从自动切换,则必须使用 GTID 模式。 enable-gtid: false from: host: "${host}" # 例如:172.16.10.81 user: "root" password: "${password}" # 支持但不推荐使用明文密码,建议使用 dmctl encrypt 对明文密码进行加密后使用 port: 3306
在终端中执行下面的命令,使用
tiup dmctl
将数据源配置加载到 DM 集群中:tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml
该命令中的参数描述如下:
参数 描述 --master-addr
dmctl 要连接的集群的任意 DM-master 节点的 {advertise-addr},例如:172.16.10.71:8261 operate-source create
向 DM 集群加载数据源
第 2 步: 创建迁移任务
新建 task1.yaml
文件, 写入以下内容:
# 任务名,多个同时运行的任务不能重名。
name: "test"
# 任务模式,可设为
# full:只进行全量数据迁移
# incremental: binlog 实时同步
# all: 全量 + binlog 迁移
task-mode: "incremental"
# 下游 TiDB 配置信息。
target-database:
host: "${host}" # 例如:172.16.10.83
port: 4000
user: "root"
password: "${password}" # 支持但不推荐使用明文密码,建议使用 dmctl encrypt 对明文密码进行加密后使用
# 黑白名单全局配置,各实例通过配置项名引用。
block-allow-list: # 如果 DM 版本早于 v2.0.0-beta.2 则使用 black-white-list。
listA: # 名称
do-tables: # 需要迁移的上游表的白名单。
- db-name: "test_db" # 需要迁移的表的库名。
tbl-name: "test_table" # 需要迁移的表的名称。
# 配置数据源
mysql-instances:
- source-id: "mysql-01" # 数据源 ID,即 source1.yaml 中的 source-id
block-allow-list: "listA" # 引入上面黑白名单配置。
# syncer-config-name: "global" # 引用上面的 syncers 增量数据配置。
meta: # task-mode 为 incremental 且下游数据库的 checkpoint 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在,则以 checkpoint 为准。
binlog-name: "mysql-bin.000004" # “Step 1. 导出 Aurora 快照文件到 Amazon S3” 中记录的日志位置,当上游存在主从切换时,必须使用 gtid。
binlog-pos: 109227
# binlog-gtid: "09bec856-ba95-11ea-850a-58f2b4af5188:1-9"
# 【可选配置】 如果增量数据迁移需要重复迁移已经在全量数据迁移中完成迁移的数据,则需要开启 safe mode 避免增量数据迁移报错。
## 该场景多见于以下情况:全量迁移的数据不属于数据源的一个一致性快照,随后从一个早于全量迁移数据之前的位置开始同步增量数据。
# syncers: # sync 处理单元的运行配置参数。
# global: # 配置名称。
# safe-mode: true # 设置为 true,会将来自数据源的 INSERT 改写为 REPLACE,将 UPDATE 改写为 DELETE 与 REPLACE,从而保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 1 分钟内 TiDB DM 会自动启动 safe mode。
以上内容为执行迁移的最小任务配置。关于任务的更多配置项,可以参考 DM 任务完整配置文件介绍
第 3 步: 启动任务
在你启动数据迁移任务之前,建议使用 check-task
命令检查配置是否符合 DM 的配置要求,以降低后期报错的概率:
tiup dmctl --master-addr ${advertise-addr} check-task task.yaml
使用 tiup dmctl
执行以下命令启动数据迁移任务。
tiup dmctl --master-addr ${advertise-addr} start-task task.yaml
该命令中的参数描述如下:
参数 | 描述 |
---|---|
--master-addr | dmctl 要连接的集群的任意 DM-master 节点的 {advertise-addr},例如: 172.16.10.71:8261 |
start-task | 命令用于创建数据迁移任务 |
如果任务启动失败,可根据返回结果的提示进行配置变更后,再次执行上述命令,重新启动任务。遇到问题请参考故障及处理方法以及常见问题。
第 4 步: 查看任务状态
如需了解 DM 集群中是否存在正在运行的迁移任务及任务状态等信息,可使用 tiup dmctl
执行 query-status
命令进行查询:
tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}
关于查询结果的详细解读,请参考查询状态。
第 5 步: 监控任务与查看日志
要查看迁移任务的历史状态以及更多的内部运行指标,可参考以下步骤。
如果使用 TiUP 部署 DM 集群时,正确部署了 Prometheus、Alertmanager 与 Grafana,则使用部署时填写的 IP 及端口进入 Grafana,选择 DM 的 dashboard 查看 DM 相关监控项。
DM 在运行过程中,DM-worker, DM-master 及 dmctl 都会通过日志输出相关信息。各组件的日志目录如下:
- DM-master 日志目录:通过 DM-master 进程参数
--log-file
设置。如果使用 TiUP 部署 DM,则日志目录默认位于/dm-deploy/dm-master-8261/log/
。 - DM-worker 日志目录:通过 DM-worker 进程参数
--log-file
设置。如果使用 TiUP 部署 DM,则日志目录默认位于/dm-deploy/dm-worker-8262/log/
。