作者： TiDBer_ 小阿飞原文来源：https://tidb.net/blog/1d37929e

第六部分 数据备份及数据迁移

一、TiDB Data Migration (DM) 安装部署

TiDB Data Migration (DM) 是一款便捷的数据迁移工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的全量数据迁移和增量数据同步。

1. 解压 DM 包

在 TOOLS 的文件夹中，找到 dm-master-v6.5.2-linux-amd64.tar.gz 包，解压到本地

# tar zxvf dm-master-v6.5.2-linux-amd64.tar.gz

2. 配置文件

编写安装配置拓扑文件

# vim dmtopo.yaml

编辑如下内容，注意格式，这里测试时只用单节点来部署。

注意事项：要和 TIDB 的数据库拓扑 IP 区分开，否则会造成 TIDB 集群的 granafa 和 dashboard 监控因 IP 冲突而导致访问失效。

-–

global:

  user: “tidb”

  ssh_port: 22

  deploy_dir: “/home/tidb/dm/deploy”

  data_dir: “/home/tidb/dm/data”

  # arch: “amd64”

master_servers:

  - host: 21.72.124.42

worker_servers:

  - host: 21.72.124.42

monitoring_servers:

  - host: 21.72.124.42

grafana_servers:

  - host: 21.72.124.42

alertmanager_servers:

  - host: 21.72.124.42

3. 安装

安装 DM 组件

# tiup dm deploy dm-test v6.5.2 ./dmtopo.yaml –user tidb

4. 查看状态

# tiup dm display dm-test

二、DM 任务设置

1. 配置数据源

（1）加密数据源密码

# tiup dmctl encrypt ‘abc!@#123’

（2）编写数据源配置文件

source-id: “mysql-01”    # 数据源 ID，在数据迁移任务配置和 dmctl 命令行中引用该 source-id 可以关联到对应的数据源

from:

  host: “127.0.0.1”

  port: 3306

  user: “root”

  password: “MKxn0Qo3m3XOyjCnhEMtsUCm83EhGQDZ/T4=” # 推荐使用 dmctl 对上游数据源的用户密码加密之后的密码

  security:                                        # 上游数据源 TLS 相关配置。如果没有需要则可以删除

    ssl-ca: “/path/to/ca.pem”

    ssl-cert: “/path/to/cert.pem”

ssl-key: “/path/to/key.pem”

2. 创建数据源

# tiup dmctl –master-addr 21.72.124.42:8261 operate-source create

source-mysql-01.yaml

3. 配置任务

# vim dm-task.yaml

# 注意文件格式

name: testdm

task-mode: all

target-database:

  host: “127.0.0.1”

  port: 4000

  user: “root”

  password: “” # 如果密码不为空，则推荐使用经过 dmctl 加密的密文

# 填写一个或多个所需同步的数据源信息

mysql-instances:

  - source-id: “mysql-01”

    block-allow-list:  ”ba-rule1”

block-allow-list:

  ba-rule1:

do-dbs: [“testdm”]

任务配置文件分为以下几部分：

    # 全局配置

## 基本信息配置

## 功能配置集

# 实例配置

完整配置文件实例请参考https://docs.pingcap.com/zh/tidb/v6.5/task-configuration-file-full

4. 创建数据迁移任务

# [tiup dmctl –master-addr 127.0.0.1:8261]() start-task testdm-task.yaml

结果如下：

tiup is checking updates for component dmctl …

Starting component `dmctl`: /root/.tiup/components/dmctl/v7.3.0/dmctl/dmctl –master-addr 127.0.0.1:8261 start-task testdm-task.yaml

{

    ”result”: true,

    ”msg”: “”,

    ”sources”: [

        {

            ”result”: true,

            ”msg”: “”,

            ”source”: “mysql-01”,

            ”worker”: “dm-192.168.80.201-8262”

        }

    ],

    ”checkResult”: “pre-check is passed. “

}

5. 任务相关

（1）查询状态

query-status

示例：

# tiup dmctl –master-addr 127.0.0.1:8261 [query-status]() [testdm]()

（2）暂停任务

pause-task [-s “mysql-replica-01”] task-name

示例：

# tiup dmctl –master-addr 127.0.0.1:8261 pause-task  testdm

（3）恢复任务

resume-task [-s “mysql-replica-01”] task-name

示例：

# tiup dmctl –master-addr 127.0.0.1:8261 resume-task testdm

（4）停止任务

stop-task [-s “mysql-replica-01”] task-name

示例：

# tiup dmctl –master-addr 127.0.0.1:8261 stop-task testdm

6. 非常规数据迁移

（1）分库分表数据迁移

（2）上下游列数量不一致

（3）增量数据校验、迁移

三、Dumpling 数据导出工具

使用数据导出工具 [Dumpling]()，你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份。

1. 安装 Dumpling

[tidb\@localhost] #cd  /home/tidb_install/tidb-enterprise-server-v6.5.2-linux-amd64

[tidb\@localhost] #tar -zxvf dumpling-v6.5.2-linux-amd64.tar.gz

会解压出一个 dumpling 文件

2. 导出数据

导出某库到本地文件夹语句如下：

[tidb\@localhost]#tiup dumpling  -uroot  -P13390  -h21.72.124.42  -o /home/dump -B P6ODS

参数解释：

-u 导出数据库的用户名

-P 导出数据库的端口号

-h 导出数据库的 IP 地址

-o 要导入的文件夹，需有相应权限

-B 导出的数据库名称 schema

3.Dumpling 主要选项表

四、TiDB Lightning 数据导入工具

TiDB Lightning 是用于从静态文件导入 TB 级数据到 TiDB 集群的工具，常用于 TiDB 集群的初始化数据导入。

1. 安装部署

下载 TiDB Lightning 安装包

解压 Lightning 压缩包即可获得 tidb-lightning 可执行文件。

tar -zxvf tidb-lightning-${version}-linux-amd64.tar.gz

chmod +x tidb-lightning

2. 导入前准备

（1）检查目标数据库

| | | | | || – | ————————— | —————————————— | —————————————————— | ——————————————————– ||   | 特性 | 作用域 | 所需权限 | 备注 || 必需 | 基本功能 | 目标 table | CREATE,SELECT,INSERT,UPDATE,DELETE,DROP,ALTER | DROP 仅 tidb-lightning-ctl 在执行 checkpoint-destroy-all 时需要 || | | 目标 database | CREATE |   || 必需 | Logical Import Mode | information_schema.columns | SELECT |   || | Physical Import Mode | mysql.tidb | SELECT |   || | | - | SUPER |   || | | - | RESTRICTED_VARIABLES_ADMIN,RESTRICTED_TABLES_ADMIN | 当目标 TiDB 开启 SEM || 推荐 | 冲突检测，max-error | lightning.task-info-schema-name 配置的 schema | SELECT,INSERT,UPDATE,DELETE,CREATE,DROP | 如不需要，该值必须设为 ”” || 可选 | 并行导入 | lightning.meta-schema-name 配置的 schema | SELECT,INSERT,UPDATE,DELETE,CREATE,DROP | 如不需要，该值必须设为 ”” || 可选 | checkpoint.driver = “mysql” | checkpoint.schema 设置 | SELECT,INSERT,UPDATE,DELETE,CREATE,DROP | 使用数据库而非文件形式存放 checkpoint 信息时需要 |

（2）目标数据库所需空间

目标 TiKV 集群必须有足够空间接收新导入的数据。除了标准硬件配置以外，目标 TiKV 集群的总存储空间必须大于 数据源大小 × 副本数量 × 2。例如集群默认使用 3 副本，那么总存储空间需为数据源大小的 6 倍以上。公式中的 2 倍可能难以理解，其依据是以下因素的估算空间占用：

索引会占据额外的空间

RocksDB 的空间放大效应

目前无法精确计算 Dumpling 从 MySQL 导出的数据大小，但你可以用下面 SQL 语句统计信息表的 data_length 字段估算数据量：

统计所有 schema 大小，单位 MiB，注意修改 ${schema_name}

SELECT table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length, SUM(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = “${schema_name}” GROUP BY table_schema;

统计最大单表，单位 MiB，注意修改 ${schema_name}

SELECT table_name, table_schema, SUM(data_length)/1024/1024 AS data_length, SUM(index_length)/1024/1024 AS index_length, SUM(data_length+index_length)/1024/1024 AS sum FROM information_schema.tables WHERE table_schema = “${schema_name}” GROUP BY table_name,table_schema ORDER BY sum  DESC LIMIT 5;

3. 数据源

TiDB Lightning 支持从多种类型的文件导入数据到 TiDB 集群。

通过以下配置为 TiDB Lightning 指定数据文件所在位置。

[mydumper]

# 本地源数据目录或 S3 等外部存储 URL

data-source-dir = “/data/my_database”

TiDB Lightning 运行时将查找 data-source-dir 中所有符合命令规则的文件。

数据源命名规则如下：

$d{b}_{n}ame.${table_name}-schema.sql

${db_name}-schema-create.sql

$d{b}_{n}ame.${table_name}.${csv|sql|parquet}

$d{b}_{n}ame.${table_name}.001.${csv|sql|parquet}

$d{b}_{n}ame.${table_name}.${csv|sql|parquet}.{compress}

CSV 格式的数据

CSV 格式可在 tidb-lightning.toml 文件中 [mydumper.csv] 下配置。大部分设置项在 MySQL [LOAD DATA] 语句中都有对应的项目。

SQL 格式的数据

TiDB Lightning 在处理 SQL 文件时，由于无法对单个文件进行快速分割，因此无法通过增加并发提高单个文件的导入速度。鉴于此，导出数据为 SQL 文件时应尽量避免单个 SQL 文件过大，通常单文件在 256MiB 左右可以达到最佳性能。

4. 导入模式

（1）Physical Import Mode

Physical Import Mode 不经过 SQL 接口，而是直接将数据以键值对的形式插入 TiKV 节点，是一种高效、快速的导入模式。使用 Physical Import Mode 时，单个 Lightning 实例可导入的数据量为 10 TiB

Physical Import Mode 对应的后端模式为 local。

使用限制：

▪TiDB Lightning 不支持导入数据到已有业务写入的数据表；

▪请勿直接使用 Physical Import Mode 向已经投入生产的 TiDB 集群导入数据，这将对在线业务产生严重影响；

▪不应同时启动多个 TiDB Lightning 实例向同一 TiDB 集群导入数据，而应考虑使用并行导入特性。

[▪]() 不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。

▪导入数据的过程中，请勿在目标表进行 DDL 和 DML 操作，否则会导致导入失败或数据不一致。

▪单个 TiDB Lightning 进程导入单表不应超过 10 TB。

（2）[Logical Import Mode]()

在 Logical Import Mode 下，TiDB Lightning 先将数据编码成 SQL，然后直接运行这些 SQL 语句进行数据导入。对于已有数据、对外提供服务的 TiDB 集群，推荐使用 Logical Import Mode 导入数据。Logical Import Mode 的行为与正常执行 SQL 并无差异，可保证 ACID。

Logical Import Mode 对应的后端模式为 tidb。

使用限制：

▪不可同时使用 Physical Import Mode 和 Logical Import Mode 导入同一 TiDB 集群。

5. 配置文件

[（1）]()使用 Physical Import Mode 的配置文件示例如下：

[lightning]

# 日志

level = “info”

file = “tidb-lightning.log”

max-size = 128 # MB

max-days = 28

max-backups = 14

# 启动之前检查集群是否满足最低需求。

check-requirements = true

[mydumper]

# 本地源数据目录或外部存储 URL

data-source-dir = “/data/my_database”

[tikv-importer]

# 导入模式配置，设为 local 即使用 Physical Import Mode

backend = “local”

# 冲突数据处理方式

duplicate-resolution = ‘remove’

# 本地进行 KV 排序的路径。

sorted-kv-dir = “./some-dir”

# 限制 TiDB Lightning 向每个 TiKV 节点写入的带宽大小，默认为 0，表示不限制。

# store-write-bwlimit = “128MiB”

[tidb]

# 目标集群的信息。tidb-server 的地址，填一个即可。

host = “172.16.31.1”

port = 4000

user = “root”

# 设置连接 TiDB 的密码，可为明文或 Base64 编码。

password = “”

# 必须配置。表结构信息从 TiDB 的“status-port”获取。

status-port = 10080

# 必须配置。pd-server 的地址，填一个即可。

pd-addr = “172.16.31.4:2379”

# tidb-lightning 引用了 TiDB 库，并生成产生一些日志。

# 设置 TiDB 库的日志等级。

log-level = “error”

# 注意：

# 1. Checksum 对比失败通常表示导入异常（数据丢失或数据不一致），因此建议总是开启 Checksum。

# 2. 考虑到与旧版本的兼容性，依然可以在本配置项设置 `true` 和 `false` 两个布尔值，其效果与 `required` 和 `off` 相同。

checksum = “required”

# 配置是否在 CHECKSUM 结束后对所有表逐个执行 `ANALYZE TABLE <table>` 操作。

# 此配置的可选配置项与 `checksum` 相同，但默认值为 “optional”。

analyze = “optional”

（2）使用 Logical Import Mode 的配置文件示例如下：

[lightning]

# 日志

level = “info”

file = “tidb-lightning.log”

max-size = 128 # MB

max-days = 28

max-backups = 14

# 启动之前检查集群是否满足最低需求。

check-requirements = true

[mydumper]

[# 本地源数据目录或外部存储 URL]()

data-source-dir = “/data/my_database”

[tikv-importer]

# 导入模式配置，设为 tidb 即使用 Logical Import Mode

backend = “tidb”

# Logical Import Mode 插入重复数据时执行的操作。

# - replace：新数据替代已有数据

# - ignore：保留已有数据，忽略新数据

# - error：中止导入并报错

on-duplicate = “replace”

[tidb]

# 目标集群的信息。tidb-server 的地址，填一个即可。

host = “172.16.31.1”

port = 4000

user = “root”

# 设置连接 TiDB 的密码，可为明文或 Base64 编码。

password = “”

# tidb-lightning 引用了 TiDB 库，并生成产生一些日志。

# 设置 TiDB 库的日志等级。

log-level = “error”

6. 其他功能

（1）断点续传

[checkpoint]

# 启用断点续传。

# 导入时，TiDB Lightning 会记录当前进度。

# 若 TiDB Lightning 或其他组件异常退出，在重启时可以避免重复再导入已完成的数据。

enable = true

# 存储断点的方式

#  - file：存放在本地文件系统（要求 v2.1.1 或以上）

#  - mysql：存放在兼容 MySQL 的数据库服务器

driver = “file”

# 存储断点的架构名称（数据库名称）

# 仅在 driver = “mysql” 时生效

# schema = “tidb_lightning_checkpoint”

# 断点的存放位置

# 若 driver = “file”，此参数为断点信息存放的文件路径。

# 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb`

# 若 driver = “mysql”，此参数为数据库连接参数 (DSN)，格式为“用户: 密码 @tcp(地址: 端口)/”。

# 默认会重用 [tidb] 设置目标数据库来存储断点。

# 为避免加重目标集群的压力，建议另外使用一个兼容 MySQL 的数据库服务器。

# dsn = “/tmp/tidb_lightning_checkpoint.pb”

# 导入成功后是否保留断点。默认为删除。

# 保留断点可用于调试，但有可能泄漏数据源的元数据。

# keep-after-success = false

（2）断点续传的控制

--checkpoint-error-destroy 

该命令会让失败的表从头开始整个导入过程.

示例：tidb-lightning-ctl –checkpoint-error-destroy=’`schema`.`table`‘

      tidb-lightning-ctl –checkpoint-error-destroy=all

--checkpoint-error-ignore

这条命令会清除出错状态

示例：tidb-lightning-ctl –checkpoint-error-ignore=’`schema`.`table`‘

tidb-lightning-ctl –checkpoint-error-ignore=all

--checkpoint-remove

无论是否有出错，把表的断点清除。

示例：tidb-lightning-ctl –checkpoint-remove=’`schema`.`table`‘

tidb-lightning-ctl –checkpoint-remove=all

--checkpoint-dump

将所有断点备份到传入的文件夹，主要用于技术支持。此选项仅于 driver = “mysql” 时有效。

示例：tidb-lightning-ctl –checkpoint-dump=output/directory

（3）并行导入

通过支持同步启动多个实例，并行导入不同的单表或多表的不同数据，使 TiDB Lightning 具备水平扩展的能力，可大大降低导入大量数据所需的时间。

注意

▪并行导入只支持初始化 TiDB 的空表，不支持导入数据到已有业务写入的数据表，否则可能会导致数据不一致的情况。

▪并行导入一般用于 Physical Import 模式，需要设置 incremental-import = true

▪并行导入一般用于 Physical Import 模式；虽然也能用于 Logical Import 模式，但是一般不会带来明显的性能提升。

使用 TiDB Lightning 并行导入需要设置 incremental-import = true。TiDB Lightning 在启动时，会在下游 TiDB 中注册元信息，并自动检测是否有其他实例向目标集群导入数据。如果有，则自动进入并行导入模式。

使用限制

TiDB Lightning 在运行时，需要独占部分资源，因此如果需要在单台机器上面部署多个 TiDB Lightning 实例 (不建议生产环境使用) 或多台机器共享磁盘存储时，需要注意如下使用限制：

每个 TiDB Lightning 实例的 tikv-importer.sorted-kv-dir 必须设置为不同的路径。多个实例共享相同的路径会导致非预期的行为，可能导致导入失败或数据出错。

每个 TiDB Lightning 的 checkpoint 需要分开存储。checkpoint 的详细配置见 TiDB Lightning 断点续传。

如果设置 checkpoint.driver = “file”（默认值），需要确保每个实例设置的 checkpoint 的路径不同。

如果设置 checkpoint.driver = “mysql”，需要为每个实例设置不同的 schema。

每个 TiDB Lightning 的 log 文件应该设置为不同的路径。共享同一个 log 文件将不利于日志的查询和排查问题。

如果开启Web 界面或 Debug API，需要为每个实例的 lightning.status-addr 设置不同地址，否则，TiDB Lightning 进程会由于端口冲突无法启动。

五、TICDC

TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。

1. 部署

在使用 TiUP 部署全新 TiDB 集群时，支持同时部署 TiCDC 组件。你需要在 TiUP 启动 TiDB 集群时的配置文件中加入 TiCDC 相关的部分，以下是一个示例：

cdc_servers:

  - host: 10.0.1.20

    gc-ttl: 86400

    data_dir: “/cdc-data”

  - host: 10.0.1.21

    gc-ttl: 86400

    data_dir: “/cdc-data”

2. 命令

使用 TiUP 可以方便地终止和启动 TiCDC 节点，命令如下：

终止 TiCDC 节点：tiup cluster stop -R cdc

启动 TiCDC 节点：tiup cluster start -R cdc

重启 TiCDC 节点：tiup cluster restart -R cdc

查看 cdc 集群运行状态

tiup ctl:v<CLUSTER_VERSION> cdc capture list –server=http://10.0.10.25:8300

3. 同步任务

使用以下命令来创建同步任务：

cdc cli changefeed create \

    –server=http://10.0.10.25:8300 \

    –sink-uri=“s3://logbucket/storage_test?protocol=canal-json” \

--changefeed-id=“simple-replication-task”

参数解释：

--server：TiCDC 集群中任意一个 TiCDC 服务器的地址。

--changefeed-id：同步任务的 ID。格式需要符合正则表达式 ^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$。如果不指定该 ID，TiCDC 会自动生成一个 UUID（version 4 格式）作为 ID。

--sink-uri：同步任务下游的地址。具体可参考配置 Sink URI。

--start-ts：指定 changefeed 的开始 TSO。TiCDC 集群将从这个 TSO 开始拉取数据。默认为当前时间。

--target-ts：指定 changefeed 的目标 TSO。TiCDC 集群拉取数据直到这个 TSO 停止。默认为空，即 TiCDC 不会自动停止。

--config：指定 changefeed 配置文件

NFS 配置样例如下：

--sink-uri=“file:///my-directory/prefix?protocol=canal-json”

六、TiDB Binlog

1. 组件概念

TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。

TiDB Binlog 支持以下功能场景：

数据同步：同步 TiDB 集群数据到其他数据库

实时备份和恢复：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复

   TiDB Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具：

Pump

Pump 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。

Drainer

Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。

binlogctl 工具

binlogctl 是一个 TiDB Binlog 配套的运维工具，具有如下功能：

获取 TiDB 集群当前的 TSO

查看 Pump/Drainer 状态

修改 Pump/Drainer 状态

暂停 / 下线 Pump/Drainer

2. 安装部署

（1）工具包

TiDB Binlog 安装包位于 TiDB 离线工具包中。解压后使用

pump-v6.5.2-linux-amd64.tar.gz

drainer-v6.5.2-linux-amd64.tar.gz

tar -zxvf pump-v6.5.2-linux-amd64.tar.gz

tar -zxvf drainer-v6.5.2-linux-amd64.tar.gz

（2）使用 TIUP 部署：

在 TIDB 的配置文件中，配置 BINLOG

参考配置如下：

server_configs:

  tidb:

    binlog.enable: true

binlog.ignore-error: true

pump_servers:

  - host: 10.0.1.1

  - host: 10.0.1.2

  - host: 10.0.1.3

drainer_servers:

  - host: 10.0.1.12

    # drainer meta data directory path

    data_dir: “/path/to/save/data”

    config:

      syncer.db-type: “file”

      # directory to save binlog file, default same as data-dir(save checkpoint file) if this is not configured.

      # syncer.to.dir: “/path/to/save/binlog”

详细配置请参考（github 网站访问不稳定，可使用加速工具，如 Watt Toolkit）：

https://github.com/pingcap/docs-cn/blob/master/config-templates/complex-tidb-binlog.yaml

3. 配置使用

Pump/Drainer 的使用

Pump/Drainer 中状态的定义：

online：正常运行中

pausing：暂停中

paused：已暂停

closing：下线中

offline：已下线

第七部分 其他工具部署

一、HAproxy 的安装部署

1. 依赖包和安装包下载

依赖包：epel-release   gcc   systemd-devel

cpp.x86_64 0:4.8.5-44.el7     

glibc-devel.x86_64 0:2.17-326.el7_9   

glibc-headers.x86_64 0:2.17-326.el7_9   

kernel-headers.x86_64 0:3.10.0-1160.71.1.el7   

libmpc.x86_64 0:1.0.1-3.el7   

mpfr.x86_64 0:3.1.1-4.el7            

gcc-4.8.5-44.el7.x86_64.rpm

以上依赖包的附属依赖包太多，所以此处只下载以上依赖包，强制安装

# rpm  -ivh  *.rpm  –force  –nodeps

2.HAproxy 下载

https://github.com/haproxy/haproxy/archive/refs/tags/v2.5.0.zip

此处下载 2.5 版本的 zip 包

安装

解压 zip 包，进入对应文件夹目录，编译，安装，配置

前提 make 和 make cc 可用

# cd haproxy-2.5.0

# make clean

# make -j 8 TARGET=linux-glibc USE_THREAD=1

# make PREFIX=/usr/local/haproxy_v2.5.0 SBINDIR=/usr/local/haproxy_v2.5.0/bin install

# ln -s /usr/local/haproxy_v2.5.0 /usr/local/haproxy

# echo ‘export PATH=/usr/local/haproxy/bin:$PATH’ >> /etc/profile

# source /etc/profile

# which haproxy

/usr/local/haproxy/bin/haproxy

3. 部署

编辑 haproxy.cfg 文件，离线安装在解压包下目录 examples 里不会自动生成 haproxy.cfg 文件，需自行创建。

haproxy.cfg 配置文件按照 TIDB 官方文档配置

注意：以下的全局部署中的 /var/lib/haproxy 文件夹如过启动时报错，需手动创建，按报错提示信息进行处理。

global                                  

   log      127.0.0.1  local1

chroot   [/var/lib/haproxy]()              

   pidfile     /var/run/haproxy.pid          

   maxconn     4096                     

   nbthread    48                        

   user        haproxy                    

   group       haproxy                    

   daemon                              

   stats socket /var/lib/haproxy/stats           

defaults                                   

   log global                               

   retries 2                               

   timeout connect  2s                     

   timeout client 30000s                  

   timeout server 30000s

listen admin_stats                         

   bind 0.0.0.0:8080                      

   mode http                            

   option httplog                          

   maxconn 10                            

   stats refresh 30s                       

   stats uri /haproxy                      

   stats realm HAProxy                     

   stats auth admin:admin

   stats hide-version                      

   stats  admin if TRUE

listen tidb-cluster                        

   bind 0.0.0.0:13390

   mode tcp                               

   balance leastconn                       

server tidb-1 10.9.18.229:4000 check inter 2000 rise 2 fall 3         server tidb-2 10.9.39.208:4000 check inter 2000 rise 2 fall 3

server tidb-3 10.9.64.166:4000 check inter 2000 rise 2 fall 3

具体设置字段解释请参考https://docs.pingcap.com/zh/tidb/v6.5/haproxy-best-practices#haproxy-%E5%9C%A8-tidb-%E4%B8%AD%E7%9A%84%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5

4. 启动

# /usr/local/haproxy/bin/haproxy -f haproxy.cfg

设置开机自启动

~]# cp /root/haproxy-2.5.0/examples/haproxy.init /etc/init.d/haproxy

~]# chmod +x /etc/init.d/haproxy

~]# ln -s /usr/local/haproxy/bin/haproxy /usr/sbin/

~]# chkconfig –add haproxy

~]# chkconfig haproxy on

~]# systemctl enable haproxy

5. 手动启动

~]# systemctl restart haproxy

~]# systemctl status haproxy

~]# systemctl start haproxy

~]# systemctl stop haproxy

6. 配置负载

（1）配置 tidb 文件

TiDB 侧配置文件加入 proxy 协议

需要配置使用 PROXY 协议连接 TiDB，配置后单节点 tidb 将无法直接登录

[tidb\@tidb1]# tiup cluster edit-config tidb

在 server_configs>>tidb 中加入如下内容

   server_configs:

     tidb:

      proxy-protocol.networks:21.72.124.42

其中，21.72.124.42 为 HAproxy 安装地址。

配置完成后，重启 tidb 节点，检测是否生效

（2）重启 tidb 节点

重启：

tiup cluster restart tidb -R tidb 或者

tiup cluster restart tidb -N 21.72.124.38:4000,21.72.124.45:4000

其中，-R 代表需要重启的角色，-N 代表需要重启的节点

（3）检验负载均衡

检测是否生效：

[tidb\@tidb2 tidb]# mysql -uroot -[h]()21.72.124.42 -P 13390 -e “select @@hostname;”

+————+

| @@hostname |

+————+

| tidb2      |

+————+

[tidb\@tidb2 tidb]# mysql -uroot -h21.72.124.42 -P 13390 -e “select @@hostname;”

+————+

| @@hostname |

+————+

| tidb3      |

+————+

前提是修改各 tidb 节点的 hostname

使用 root 登录各 tidb 节点,

# hostnamectl set-hostname tidb1

第八部分 QA

一、DM 安装时导致 grafan 等组件失效

1.【复现路径】

主控机上安装了 tidb 的 alertmanager\grafana\prometheus 组件，运行正常，页面运行正常，今天，在主控机上安装 DM 时，配置安装文件时将 DM 的 alertmanager\grafana\prometheus 组件和 tidb 的 IP:PORT 写成一样的了，安装 DM 完成后发现不对，查询 tidb 集群的上述组件状态正常，于是使用 tiup dm destory dm 删除了 dm，再次查询 TIDB 的组件，已经 Down 了。

2.【遇到的问题：问题现象及影响】

组件 Down 了以后，尝试 tiup start tidb -R grafana 和 tiup satrt tidb -N ip:port, 均无法启动起来，报错如下：

Error: Failed to start alertmanger:failed to start :21.72.124.43 alertmanager-9093,service,please check the instance’s log(/tidb-deploy/alertmanager-9093/log) for more detail,:excutor.ssh.execute_failed:Failed to execute command over SSH for ‘tidb\@21.72.124.43:22’ {ssh_stderr:Failed to start alertmanger-9093.server: Unit not found.,ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin /usr/bin/sudo -H bash -c “systemctl deamon-reload && systemctl start alertmanager-9093.service”},cause:Process exited with status 5

有业务和数据在跑，所以我没法删除 TIDB 集群重建，也没办法停 TIDB 其他模块。

3.【问题处理过程】

考虑到数据库正在运行，且其他模块正常运行，想尝试重新安装 down 掉的组件，安装时提示端口已被占用，于是，准备先下线 Down 掉的组件再重新安装，成功恢复了组件和页面状态。

组件 ID

grafana 组件       21.72.124.43:3000

altermanager 组件  21.72.124.43:9093

prometheus 组件    21.72.124.43:9090

下线处理：

# tiup cluster scale-in tidb -N 21.72.124.43:3000

# tiup cluster scale-in tidb -N 21.72.124.43:9093

# tiup cluster scale-in tidb -N 21.72.124.43:9090

观察状态

# tiup cluster display tidb

编辑 yaml 文件

vim  grafana-scaleout.yaml

monitoring_servers:

  - host: 21.72.124.43

grafana_servers:

  - host: 21.72.124.43

alertmanager_servers:

  - host: 21.72.124.43

重新安装上线

# tiup cluster scale-out tidb grafana-scaleout.yaml

检查状态 & 登录 grafana 和 Dashboard 页面

# tiup cluster display tidb

状态正常，页面正常（需等待一分钟左右刷新数据）

4.【处理过程错误】

重新安装上线 scale-out 时，报错，根据报错提示显示，ssh 互信失败，需重新配置互信，再执行扩容，一切正常

PS:DM 安装过程中，执行的语句里有用户名密码，估计在安装中使上述三个组件模块的互信失效。

可能不需要下线重装组件，只需重新配置互信后，start 一下可能就会正常，此方法暂未测试。

二、TiKV 节点下线速度满

1.【复现路径】

  由于业务原因，需重新分配数据盘目录，操作思路：4 个 TiKV 节点每两个下线，重新写好配置文件，重新上线。

2.【遇到的问题：问题现象及影响】

   同时下线 2 个 KV 节点

   # tiup cluster scale-in tidb –node 21.72.124.40:20160

   # tiup cluster scale-in tidb –node 21.72.124.50:20160

命令开始执行后，观察上述节点日志和 pd、tidb 日志，发现 GC 在给 PD 节点任务后，两个 KV 节点均未马上有日志产生，约 10 分钟后，KV 日志报错，大概意思为要执行数据迁移到其他节点，但未连接到 PD 节点，使用命令 tiup cluster display tidb 观察，两 KV 节点一直处于 OFFLINE 状态，前台面板观察 TIKV storge 状态也未发生变化，此状态持续约 2 小时

3.【问题处理过程】

思路：是否因为同时执行了 2 个节点下线任务，导致 GC 任务繁重，决定先恢复其中一个 TIKV 节点，然后修改 GC 检查时间，等待下线。

   以下为操作流程：

1. 处于 offline 状态的节点未成为 tombstone 前可以通过以下命令终止其下线过程 (需在 PD 所在节点执行)，使 tikv 重新成为 UP 状态，不适用已经删除 tikv 数据目录或宕机的情况，部分情况该 tikv 可能需要重启。

终止下线：

curl -X  POST http://pd_ip:pd_port/pd/api/v1/store/{store_id}/state\?state=Up

2. 通过 pd-ctl config set 命令可以增大 leader-schedule-limit、replica-schedule-limit、region-schedule-limit 等参数增加 leader/region 的调度速度，加快下线过程，上述命令是用于控制 PD 侧调度命令的产生速度，实际的执行还收 tikv 侧的消费速度限制，通过 pd-ctl store limit <store_id> <limit> 增加消费速度。

3. 再次观察下线过程

调整完的下线任务只剩一个节点，观察 KV 日志和 PD 日志，开始正常跑下线流程了，大约 5 分钟，下线完成，继续下线其他节点，约 2-5 分钟不等。

4.【总结】

(1) 系统部署时对于单机多 tikv 的情况一定要打上 label 标签，保障同一服务器上不同的 tikv 实例在 isolation-level 具有相同的 label，避免将相同 region 的多个副本调度到同一服务器，从而因服务器故障造成多副本丢失。

(2) 缩容 tikv 时应尽量提前进行 leader/region 转移，使缩容过程更加可控。

(3) 缩容时、store 处于 offline 状态时禁止使用 –force 参数，仅对宕机无法修复、数据目录被删除的场景使用。

(4) 缩容多个 tikv 时要尽量一个一个的进行处理，避免一次下线多个时出现问题，尤其是同一服务器上的多个 tikv。

(5) 缩容时要保障其他的 tikv 节点有足够的磁盘空间接收转移的 region。

(6) 如果允许尽量使用高版本数据量。

(7) 做完多副本失败恢复后要检查数据是否一致。

(8) 注意使用 tikv-ctl 等工具时要不同的版本会有不一样的参数，如 –db 或 –data-dir。