背景
数据库对于企业来说是至关重要的，但是由于某些原因，会导致数据库的不可用，此时需要数据库自身的恢复能力，快速恢复数据库，恢复业务可用。
数据库大多采用三副本、两地三中心架构，但在极端场景下，需要数据库自恢复能力，不要求数据的一致性，但是要求尽快恢复业务。
恢复工具介绍
对于tidb数据库来说，最重要的组件有tidb、tikv、pd；其中tidb为计算节点，是不存储业务数据的，当出现问题时，可以扩容节点来解决；pd和tikv是会存储数据，当出现问题时，需要通过恢复工具来进行修复。
pd恢复工具为：pd-recover，官方使用手册如下：
https://docs.pingcap.com/zh/tidb/stable/pd-recover#pd-recover-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3
tikv恢复工具为：online unsafe recovery，官方使用手册如下：
https://docs.pingcap.com/zh/tidb/dev/online-unsafe-recovery
灾难恢复场景
tikv灾难恢复
此前写过一篇关于tikv恢复文章，可以参考链接：
https://tidb.net/blog/75f7933e
pd灾难恢复
本文介绍pd最极端场景恢复，pd所有data和deploy目录全部损坏恢复
（一）查看集群状态，tiup cluster display tidb-test
（二）模拟所有PD data、deploy目录损坏
（三）修复PD数据，查找cluster id和alloc-id
参考文档：https://docs.pingcap.com/zh/tidb/dev/pd-recover#pd-recover-%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3
获取cluster id
一般在 PD、TiKV 或 TiDB 的日志中都可以获取 Cluster ID。你可以直接在服务器上查看日志以获取 Cluster ID。
1.从 PD 日志获取 Cluster ID（推荐）
使用以下命令，从 PD 日志中获取 Cluster ID：
cat {{/path/to}}/pd.log | grep "init cluster id"
[INFO] [server.go:212] ["init cluster id"] [cluster-id=6747551640615446306]
2.从 TiDB 日志获取 Cluster ID
使用以下命令，从 TiDB 日志中获取 Cluster ID：
cat {{/path/to}}/tidb.log | grep "init cluster id"
client.go:161: [info] [pd] init cluster id 6747551640615446306
3.从 TiKV 日志获取 Cluster ID
使用以下命令，从 TiKV 日志中获取 Cluster ID：
cat {{/path/to}}/tikv.log | grep "connect to PD cluster"
[INFO] [tikv-server.rs:464] ["connect to PD cluster 6747551640615446306"]
获取已分配 ID alloc-id
在指定已分配 ID 时，需指定一个比当前最大的已分配 ID 更大的值。可以从监控中获取已分配 ID，也可以直接在服务器上查看日志，如果无法确定最大的alloc-id，则可以根据预估设置一个较高的值，如设置100亿，alloc-id是uint64 位，最大可分配id为18446744073709551615。
1. 从监控中获取已分配 ID（推荐）
要从监控中获取已分配的 ID，需要确保你所查看的监控指标是上一任 PD Leader 的指标。可从 PD Dashboard 中 Current ID allocation 面板获取最大的已分配 ID。
2. 从 PD 日志获取已分配 ID
要从 PD 日志中获取分配的 ID，需要确保你所查看的日志是上一任 PD Leader 的日志。运行以下命令获取最大的已分配 ID：
cat {{/path/to}}/pd*.log | grep "idAllocator allocates a new id" | awk -F'=' '{print $2}' | awk -F']' '{print $1}' | sort -r -n | head -n 1
3. 从TiKV日志中获取已分配ID
如无法通过监控和PD日志查看alloc-id，则可以通过查看所有TiKV日志查看最大的region/peer id
cat tikv.log |grep "insert new region" cat tikv.log |grep "notify pd with change peer region"
（四）强制缩容任意两个PD，只保留一个PD
tiup cluster scale-in tidb-test -N pdip:2379,pdip:2379 --force
......
Start pdip success
+ [ Serial ] - UpdateTopology: cluster=tidb-test
{"level":"warn","ts":"2021-10-09T16:35:22.598+0800","logger":"etcd-client","caller":"v3@v3.5.0/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0001b6700/#initially=[ip:2379]","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}
Error: context deadline exceeded
Verbose debug logs has been written to /data/tidb/.tiup/logs/tiup-cluster-debug-2021-10-09-16-35-22.log.
Error: run `/data/tidb/.tiup/components/cluster/v1.5.6/tiup-cluster` (wd:/data/tidb/.tiup/data/SlKYAsl) failed: exit status 1
虽然会有报错，但是还是强制删除两个节点。
（五）根据display信息手动创建 pd deploy目录
cd /data/tidb/tidb-deploy/pd-2379
mkdir bin
mkdir log
mkdir conf
mkdir scripts
（六）恢复PD-server
通过集群安装介质包，解压缩pd-server，并拷贝到bin目录下（注意版本）
cd /home/tidb/tidb-community-server-v5.2.1-linux-amd64
tar -zxvf pd-recover-v5.2.1-linux-amd64.tar.gz
cp pd-server /data/tidb/tidb-deploy/pd-2379/bin/
权限：755
（七）恢复conf
cd /data/tidb/tidb-deploy/pd-2379/conf
vi pd.toml
# WARNING: This file is auto-generated. Do not edit! All your modification will be overwritten!
# You can use 'tiup cluster edit-config' and 'tiup cluster reload' to update the configuration
# All configuration items you want to change can be added to:
# server_configs:
# pd:
# aa.b1.c3: value
# aa.b2.c4: value
[replication]
isolation-level = "rack"
location-labels = ["rack", "host"]
pd.toml的配置可在.tiup下的meta文件查看
cat /home/tidb/.tiup/storage/cluster/clusters/tidb-test/meta.yaml
（八）恢复scripts
注意和上面恢复内容一致，删除--initial-cluster 中已踢掉的两个PD节点信息，其他信息可参考meta文件
cd /data/tidb/tidb-deploy/pd-2379/scripts
vi run_pd.sh
#!/bin/bash
set -e
# WARNING: This file was auto-generated. Do not edit!
# All your edit might be overwritten!
DEPLOY_DIR=/tidb-data1/tidb-deploy/pd-2379
cd "${DEPLOY_DIR}" || exit 1
exec env GODEBUG=madvdontneed=1 bin/pd-server \
--name="pd-1-2379" \
--client-urls="http://0.0.0.0:2379" \
--advertise-client-urls="http://pdip:2379" \
--peer-urls="http://0.0.0.0:2380" \
--advertise-peer-urls="http://pdip:2380" \
--data-dir="/tidb-data1/tidb-data/pd-2379" \
--initial-cluster="pd-1-2379=http://pdip:2380" \
--config=conf/pd.toml \
--log-file="/tidb-data1/tidb-deploy/pd-2379/log/pd.log" 2>> "/tidb-data1/tidb-deploy/pd-2379/log/pd_stderr.log"
权限：755
（九）测试scripts
为防止start pd失败，可先通过./方式测试run_pd.sh脚本配置是否正常，如能启动pd说明正常，其他部分承接上面PD恢复内容
./run_pd.sh
（十）启动新pd集群
启动新pd，并禁用所有pd调度（如果alloc-id是预估的比较大的值）
tiup cluster start tidb-test -N pdip:2379
tiup cluster display tidb-test
tiup ctl:v5.2.1 pd -u http://127.0.0.1:2379 -i
config show
"schedule": {
"enable-cross-table-merge": "true",
"enable-joint-consensus": "true",
"high-space-ratio": 0.7,
"hot-region-cache-hits-threshold": 3,
"hot-region-schedule-limit": 4,
"hot-regions-reserved-days": 7,
"hot-regions-write-interval": "10m0s",
"leader-schedule-limit": 4,
"leader-schedule-policy": "count",
"low-space-ratio": 0.8,
"max-merge-region-keys": 200000,
"max-merge-region-size": 20,
"max-pending-peer-count": 64,
"max-snapshot-count": 64,
"max-store-down-time": "30m0s",
"max-store-preparing-time": "48h0m0s",
"merge-schedule-limit": 8,
"patrol-region-interval": "10ms",
"region-schedule-limit": 2048,
"region-score-formula-version": "v2",
"replica-schedule-limit": 64,
"split-merge-interval": "1h0m0s",
"tolerant-size-ratio": 0
}
}
config set region-schedule-limit 0
config set leader-schedule-limit 0
（十一）PD-Recover
根据上面获取的cluster-id和alloc-id对pd进行恢复，注意：alloc-id值如果小于集群现有已分配的region id/store id，则可能会导致数据被覆盖。
执行pd-recover设置新PD集群的cluster-id与alloc-id
tiup pd-recover -endpoints http://pdip:2379 -cluster-id 7016973815389845033 -alloc-id 6000
Starting component `pd-recover`: /data/tidb/.tiup/components/pd-recover/v5.2.1/pd-recover -endpoints http://pdip:2379 -cluster-id 7016973815389845033 -alloc-id 6000
recover success! please restart the PD cluster
（十二）重启PD集群，并执行扩容
tiup cluster restart tidb-test -N pdip:2379
tiup cluster display tidb-test
tiup cluster scale-out pd.yaml
tiup cluster reload tidb-test -R pd
（十三）恢复PD调度，检查PD label 并重启集群
tiup ctl:v5.2.1 pd -u http://127.0.0.1:2379 -i
config show
"schedule": {
"enable-cross-table-merge": "true",
"enable-joint-consensus": "true",
"high-space-ratio": 0.7,
"hot-region-cache-hits-threshold": 3,
"hot-region-schedule-limit": 4,
"hot-regions-reserved-days": 7,
"hot-regions-write-interval": "10m0s",
"leader-schedule-limit": 0,
"leader-schedule-policy": "count",
"low-space-ratio": 0.8,
"max-merge-region-keys": 200000,
"max-merge-region-size": 20,
"max-pending-peer-count": 64,
"max-snapshot-count": 64,
"max-store-down-time": "30m0s",
"max-store-preparing-time": "48h0m0s",
"merge-schedule-limit": 8,
"patrol-region-interval": "10ms",
"region-schedule-limit": 0,
"region-score-formula-version": "v2",
"replica-schedule-limit": 64,
"split-merge-interval": "1h0m0s",
"tolerant-size-ratio": 0
}
}
config set region-schedule-limit 2048
config set leader-schedule-limit 4
config show
{
"replication": {
"enable-placement-rules": "true",
"enable-placement-rules-cache": "false",
"isolation-level": "",
"location-labels": "rack,host",
"max-replicas": 3,
"strictly-match-label": "false"
},
config set location-labels rack,host
最后重启集群
tiup cluster restart tidb-test
多个组件损坏场景
tidb数据库若出现多个组件同时损坏，需要同时用到pd-recover和online unsafe recovery来进行恢复，下面我对多个组件同时损坏的场景进行总结：
tikv、pd都是3个节点
损坏场景 |
是否无损修复 |
是否有损修复 |
不可修复 |
修复手段 |
|---|---|---|---|---|
pd和tikv同时损坏一个节点 |
是 |
通过扩容节点来修复 |
||
pd损坏一个节点、tikv损坏多数派节点 |
是 |
通过online unsafe recovery进行修复 |
||
pd损坏多数派节点、tikv损坏一个节点 |
是 |
通过pd-recover进行修复 |
||
pd和tikv同时损坏多数派节点 |
是 |
通过online unsafe recovery 和pd-recover进行修复 |
||
pd全部损坏、tikv损坏多数派节点 |
是 |
通过online unsafe recovery 和pd-recover进行修复 |
||
pd损坏多数票节点、tikv全部损坏 |
是 |
无法通过online unsafe recovery修复， 需要备份来进行恢复 |
||
pd和tikv全部损坏 |
是 |
无法通过online unsafe recovery修复， 需要备份来进行恢复 |
总结和思考
1、pd集群只是存储元数据信息，并且是通过tikv心跳上报，故pd集群的所有数据丢失后，整个tidb集群可以通过重建pd集群修复；
2、重建pd集群需要知道pd老集群的cluster-id和alloc-id，日常备份这两个值即可。
3、日常备份是非常重要的，在极端场景需要用到备份数据来进行恢复。