点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！
接上篇《TiDB运维文档（上）》，我们今天讲一下TIDB数据库的日常运维。
版本升级
1.1 升级 TiUP 或更新 TiUP 离线镜像
1.2 检查当前集群的健康状况
tiup cluster check <cluster-name>
执行结束后，最后会输出 region status 检查结果。
如果结果为 "All regions are healthy"，则说明当前集群中所有 region 均为健康状态，可以继续执行升级；
如果结果为 "Regions are not fully healthy: m miss-peer, n pending-peer" 并提示 "Please fix unhealthy regions before other operations."，则说明当前集群中有 region 处在异常状态，应先排除相应异常状态，并再次检查结果为 "All regions are healthy" 后再继续升级。
1.3 升级 TiDB 集群
tiup cluster upgrade <cluster-name> <version>
tiup cluster upgrade <cluster-name> v5.1.2
注意：
a) 滚动升级会逐个升级所有的组件。升级 TiKV 期间，会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 5 分钟（300 秒），超时后会直接停止该实例。 b) 如果不希望驱逐 leader，而希望快速升级集群至新版本，可以在上述命令中指定 --force，该方式会造成性能抖动，不会造成数据损失。 c) 如果希望保持性能稳定，则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例，可以指定 --transfer-timeout 为一个更大的值，如 --transfer-timeout 3600，单位为秒。
扩缩容
2.1 扩容 TiDB/PD/TiKV 节点
2.1.1 在 scale-out.yaml 文件添加扩容拓扑配置
TiDB 配置文件参考：
tidb_servers:
- host: 10.0.1.5
ssh_port: 22
port: 4000
status_port: 10080
deploy_dir: data/deploy/install/deploy/tidb-4000
log_dir: data/deploy/install/log/tidb-4000
TiKV 配置文件参考：
tikv_servers:
- host: 10.0.1.5
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: data/deploy/install/deploy/tikv-20160
data_dir: data/deploy/install/data/tikv-20160
log_dir: data/deploy/install/log/tikv-20160
PD 配置文件参考：
pd_servers:
- host: 10.0.1.5
ssh_port: 22
name: pd-1
client_port: 2379
peer_port: 2380
deploy_dir: data/deploy/install/deploy/pd-2379
data_dir: /data/deploy/install/data/pd-2379
log_dir: /data/deploy/install/log/pd-2379
2.1.2 执行扩容命令
tiup cluster scale-out <cluster-name> scale-out.yaml
2.2 扩容 TiFlash 节点
2.2.1 添加节点信息到 scale-out.yaml 文件
tiflash_servers:
- host: 10.0.1.4
2.2.2 运行扩容命令
tiup cluster scaltiup cluster scale-out <cluster-name>
scale-out.yamle-out <cluster-name> scale-out.yaml
2.3 扩容 TiCDC 节点
2.3.1 添加节点信息到 scale-out.yaml 文件
cdc_servers:
- host: 10.0.1.3
- host: 10.0.1.4
2.3.2 运行扩容命令
tiup cluster scale-out <cluster-name> scale-out.yaml
2.4 缩容 TiDB/PD/TiKV 节点
2.4.1 查看节点 ID 信息
tiup cluster display <cluster-name>
2.4.2 执行缩容操作
tiup cluster scale-in <cluster-name> --node 10.0.1.5:20160
2.4.3 检查集群状态
tiup cluster display <cluster-name>
2.5.1 根据 TiFlash 剩余节点数调整数据表的副本数
alter table <db-name>.<table-name> set tiflash replica 0;
2.5.2 执行缩容操作
tiup cluster display <cluster-name>
tiup cluster scale-in <cluster-name> --node 10.0.1.4:9000
2.6 缩容 TiCDC 节点
tiup cluster scale-in <cluster-name> --node 10.0.1.4:8300
备份恢复
3.1 BR备份恢复
备份路径下会生成以下几种类型文件：
SST 文件：存储 TiKV 备份下来的数据信息。 backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值。 backup.lock 文件：用于防止多次备份到同一目录。
1) 推荐部署配置
2) 备份数据
i) 备份全库
br backup full \
--pd "${PDIP}:2379" \
--storage "local:///tmp/backup" \
--ratelimit 128 \
--log-file backupfull.log
ii) 备份单库
br backup db \
--pd "${PDIP}:2379" \
--db test \
--storage "local:///tmp/backup" \
--ratelimit 128 \
--log-file backuptable.log
iii) 备份单表
br backup table \
--pd "${PDIP}:2379" \
--db test \
--table usertable \
--storage "local:///tmp/backup" \
--ratelimit 128 \
--log-file backuptable.log
iv) 使用表库功能过滤备份多表
br backup full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--ratelimit 128 \
--log-file backupfull.log
3) 恢复数据
i) 恢复全部备份数据
br restore full \
--pd "${PDIP}:2379" \
--storage "local:///tmp/backup" \
--ratelimit 128 \
--log-file restorefull.log
ii) 恢复单个数据库的数据
br restore db \
--pd "${PDIP}:2379" \
--db "test" \
--ratelimit 128 \
--storage "local:///tmp/backup" \
--log-file restorefull.log
iii) 恢复单张表的数据
br restore table \
--pd "${PDIP}:2379" \
--db "test" \
--table "usertable" \
--ratelimit 128 \
--storage "local:///tmp/backup" \
--log-file restorefull.log
iv) 使用表库功能过滤恢复数据
br restore full \
--pd "${PDIP}:2379" \
--filter 'db*.tbl*' \
--storage "local:///tmp/backup" \
--log-file restorefull.log
3.2 TiCDC异地库备份
3.3 Dumpling\TiDB Lightning备份恢复
输出文件格式:
metadata：此文件包含导出的起始时间，以及 master binary log 的位置。
Started dump at: 2020-11-10 10:40:19
SHOW MASTER STATUS:
Log: tidb-binlog
Pos: 420747102018863124
Finished dump at: 2020-11-10 10:40:20
{schema}-schema-create.sql：创建 schema 的 SQL 文件。
CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
{schema}.{table}-schema.sql：创建 table 的 SQL 文件。
CREATE TABLE `t1` (
`id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
{schema}.{table}.{0001}.{sql|csv}：数据源文件。
/*!40101 SET NAMES binary*/;
INSERT INTO `t1` VALUES
(1);
1) 备份工具Dumpling
./dumpling \
-u root \
-P 4000 \
-h 127.0.0.1 \
--filetype sql \
-o /tmp/test \
-t 8 \
-r 200000 \
-F 256MiB \
--filetype:导出文件类型，sql|csv。 -o:用于选择存储导出文件的目录。 -t:用于指定导出的线程数。增加线程数会增加 Dumpling 并发度提高导出速度，但也会加大数据库内存消耗，因此不宜设置过大。 -r:用于指定单个文件的最大行数，指定该参数后 Dumpling 会开启表内并发加速导出，同时减少内存使用。 -F:选项用于指定单个文件的最大大小（单位为 MiB，可接受类似 5GiB 或 8KB 的输入）。 --filter:表库过滤。
参数列表：
2) 恢复工具Tidb Lightning
tidb-lightning --config cfg.toml --backend tidb -tidb-
host 127.0.0.1 -tidb-user root --tidb-password passwd -
tidb-port 4000 -d /home/tidb/bakfile/9
Local-backend 工作原理：
TiDB Lightning 整体工作原理如下：
i) 在导入数据之前，tidb-lightning 会自动将 TiKV 集群切换为“导入模式” (import mode)，优化写入效率并停止自动压缩。 ii) tidb-lightning 会在目标数据库建立架构和表，并获取其元数据。 iii) 每张表都会被分割为多个连续的区块，这样来自大表 (200 GB+) 的数据就可以用增量方式并行导入。 iv) tidb-lightning 会为每一个区块准备一个“引擎文件 (engine file)”来处理键值对。tidb-lightning 会并发读取 SQL dump，将数据源转换成与 TiDB 相同编码的键值对，然后将这些键值对排序写入本地临时存储文件中。 v) 当一个引擎文件数据写入完毕时，tidb-lightning 便开始对目标 TiKV 集群数据进行分裂和调度，然后导入数据到 TiKV 集群。 vi) 引擎文件包含两种：数据引擎与索引引擎，各自又对应两种键值对：行数据和次级索引。通常行数据在数据源里是完全有序的，而次级索引是无序的。因此，数据引擎文件在对应区块写入完成后会被立即上传，而所有的索引引擎文件只有在整张表所有区块编码完成后才会执行导入。 vii) 整张表相关联的所有引擎文件完成导入后，tidb-lightning 会对比本地数据源及下游集群的校验和 (checksum)，确保导入的数据无损，然后让 TiDB 分析 (ANALYZE) 这些新增的数据，以优化日后的操作。同时，tidb-lightning 调整 AUTO_INCREMENT 值防止之后新增数据时发生冲突。 viii) 表的自增 ID 是通过行数的上界估计值得到的，与表的数据文件总大小成正比。因此，最后的自增 ID 通常比实际行数大得多。这属于正常现象，因为在 TiDB 中自增 ID 不一定是连续分配的。 viiii) 在所有步骤完毕后，tidb-lightning 自动将 TiKV 切换回“普通模式” (normal mode)，此后 TiDB 集群可以正常对外提供服务。
参数列表：
backend各模式区别：
误操作恢复
4.1 误drop库
1) 确认删除时间
2) 确认数据的有效性
3) 备份数据
dumpling -h 172.21.xx.xx -P 4000 -uroot -p xxx -t 32 -F 64MiB -B xxx_ods --snapshot "2020-11-17 08:26:35" -o ./da
4) 恢复数据
myloader -h 172.21.xx.xx -u root -P 4000 -t 32 -d ./da -p xxx
1) 确认操作时间
2) 将数据写入到临时表
FLASHBACK TABLE xxx_comment TO xxx_comment_bak_20201117;
drop table xxx_comment ;
rename table xxx_comment_bak_20201117 to xxx_comment;
insert into xxx_comment select * from xxx_comment_bak_20201117;
1) 确认操作时间
2) 恢复表
RECOVER TABLE xxx_comment ;
4.4 误 delete、update表
1) 确认操作时间
2) 确认数据的有效性
3) 备份数据
dumpling -h 172.21.xx.xx -P 4000 -uroot -p xxx -t 32 -F
64MiB -B xxx_ods -T xxx_ods.xxx_comment --snapshot "2020-
11-17 09:55:00" -o ./da
4) 恢复数据
myloader -h 172.21.xx.xx -u root -P 4001 -t 32 -d ./da -p xxx
中控机异常恢复
5.1 中控有备份
1) 中控备份
2) 恢复方法
i) 把 tiup.tar.gz 拷贝到目标机器home目录。 ii) 在目标机器 home 目录下执行 tar xzvf tiup.tar.gz。 iii) 添加 .tiup 目录到 PATH 环境变量。
5.2 中控没有备份
恢复方法：
i) 在新的中控机器上，重新部署tiup。 ii) 根据运行的集群组件，重新配置一个集群的拓扑文件。 iii) 执行deploy命令：tiup cluster deploy tidb-xxx ./topology.yaml。 iv) 执行完成之后，不需要start集群，因为集群本身是在运行的，执行display查看一下集群的节点状态即可。
5.3 注意事项
ssh互信
新的中控节点，必须要包括和各个节点网络都是通的，并且ssh也是互通的。 网络互通
无论是通过备份恢复还是重新编写拓扑配置文件在新的节点恢复中控，如果恢复完成后，查看集群的节点状态显示down或N/A的状态，请检查新的中控节点和集群各节点之间的网络是否是通的。
巡检分析(Dashboard)
6.1 集群状态
1) 实例
2) 主机
3) 磁盘
4) 存储拓扑
5) 监控告警
6.2 Sql语句
统计选项
6.3 慢查询
6.4 流量可视化
6.5 集群诊断报告
本文作者：李仕豪(上海新炬中北团队）
本文来源：“IT那活儿”公众号
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
