作者：陈厚强

原文来源：https://tidb.net/blog/ddc1ce25

准备环境

安装介质

1） tikv 5.0.4 release

https://download.pingcap.org/tidb-community-server-v5.0.4-linux-amd64.tar.gz

2） learner-recover.tar.gz

https://github.com/pingcap-inc/learner-recover/releases/download/latest/learner-recover.tar.gz

集群拓扑信息

| IP | role | 虚拟 AZ | label | | -------------- | ---------------------------------- | ------ | ------------- | | 192.168.56.4 | pd+tikv | az1<主> | rock1-host4 | | 192.168.56.6 | pd+tikv | az2<主> | rock2-host6 | | 192.168.56.78 | pd+tikv | az3<主> | rock3-host78 | | 192.168.56.66 | tiup+monitor | | | | 192.168.56.80 | tikv(learner)+(pd灾备切换后） | az4<备> | rock4-host80 | | 192.168.56.130 | tikv(learner)+tiup+（monitor 灾备切换后） | az4<备> | rock4-host130 | | 192.168.56.136 | tikv(learner) | az4<备> | rock4-host136 |

检查切换条件

1. 主集群至少需要有一次 pending-peer-region-count 归 0，否则灾备集群会有 region 空洞无法恢复。保证灾备集群有一次完整的数据同步。

2. 确认灾备集群已经被主集群重建，以及灾备的端口配置

3. 在灾备中控机上销毁旧的灾备集群

4. 拷贝一份灾备中控机上边的 join.yaml ，scale-in 主集群中断连的 TiKV 节点，通过 join.yaml 扩容

5. 规定灾备集群的端口从 20160 开始迭代，每次恢复 join.yaml 里边的端口 +1

6. 灾备切换的配置文件均在灾备中控机上

配置文件准备

markdown 配置文件均在learner-recover/config目录下面

修改 old.yaml 文件

old.yaml内容为主机群配置信息（部署拓扑文件）。

bash cp mata.yaml old.yaml

修改 join.yaml 文件

此文件需要将灾备集群的 learner TiKV 节点的信息复制到这里，结构跟 tiup cluster scale 的拓扑一样，注意这里需要更改端口信息，否则会可能会引起主备集群的服务冲突，导致 TiKV panic。

端口修改避免冲突， join.yaml 里边的tikv端口信息需要每次测试前 +1 。但是数据目录复用，不能更改。

修改 new.yaml 文件

new.yaml文件中配置的是新集群的配置信息，其中不包含tikv部分。目录和端口要跟原主集群的不一致。

同步主集群密钥

如果是第一次测试或者主集群重新部署了，需要拷贝一份主集群的密钥到灾备恢复工具的配置目录。再次进行灾备切换时，此步骤可忽略

scp ~/.tiup/storage/cluster/clusters/<cluster-name>/ssh/id_rsa <local-path>

修改 recover.yaml文件，并把密钥加到里面

``` vi recover.yaml

主集群的拓扑文件路径

old-topology: config/old.yaml

learner 要迁入的新集群拓扑路径，文件内通常不包含 TiKV 节点，可以包含新的 PD, 监控等节点。

new-topology: config/new.yaml

灾备集群中的 TiKV 节点拓扑，里边应该包含灾备集群中的 learner 节点，需要更改端口，但是数据目录应该保持一致，重用数据的同时防止跟旧集群产生冲突。具体的配置可以看 config

join-topology: config/join.yaml

fetcher.sh 拉取的恢复信息文件路径

recover-info-file: config/recover-info.json

灾备集群的 label 。用于标识哪些集群是灾备节点，需要执行恢复操作。

zone-labels:

zone: az4

迁入集群的组建版本

cluster-version: v5.0.4

迁入集群的名字

cluster-name: tidb-backup

tikv-ctl 在每台 learner 节点上的路径，绝对路径

tikv-ctl:

src: /data1/learner-recover/tikv-ctl # 本机上的 tikv-ctl 路径，绝对路径 or 相对路径

dest: /home/tidb/tikv-ctl # 拷贝到远端 host 的 tikv-ctl 路径, 绝对路径

pd-recover 在本机上的路径，绝对路径 or 相对路径

pd-recover-path: /data1/learner-recover/pd-recover

pd server 的配置，用于设置启动的 PD，例如可以加快补副本的速度

pd-ctl-commands:

• config set max-pending-peer-count 512

• config set max-snapshot-count 128

• config set replica-schedule-limit 1024

• config set scheduler-max-waiting-operator 100

• store limit all 800 add-peer

• Store limit all 20000 remove-peer

patch: /data1/tidb-community-server-v5.0.4-linux-amd64/tikv-server.tar.gz # 需要 patch 的 tikv 二进制包

将下面信息添加到文件最后一行

extra-ssh-opts: -i id_rsa ```

拷贝tikv-ctl和pd-recover到灾备中控机

``` tikv-ctl和pd-recover两个文件在tidb v5.0.4的介质包中：

$ cp /data/tidb-community-server-v5.0.4-linux-amd64/tikv-ctl /data/learner-recover/

$ cp /data/tidb-community-server-v5.0.4-linux-amd64/pd-recover /data/learner-recover/ ```

修改rpo.yaml文件

```

可以用 rpo.sh 命令启动脚本，配置文件解析如下：

topology: config/old.yaml # 主集群拓扑文件路径

learner-labels: # 这里可以用 labels 去 match 出灾备集群的 host。

zone: az4

tikv-ctl:

需要加上src和dest的路径：

tikv-ctl 在每台 learner 节点上的路径，绝对路径

src: /data1/learner-recover/tikv-ctl # 本机上的 tikv-ctl 路径，绝对路径 or 相对路径

dest: /root/tikv-ctl # 拷贝到远端 host 的 tikv-ctl 路径, 绝对路径

last-for: 1m # 持续拉取多久的 RPO

history-path: config/history.json # 存放历史的路径

save: config/rpo.json # 存放 RPO 信息的路径 ```

修改info.yaml文件

```

可以用 fetcher.sh 命令启动脚本，配置文件解析如下：

save: config/recover-info.json # 灾备信息存放路径，集群恢复所需

topology: config/old.yaml # 主集群拓扑文件路径

learner-labels:

zone: az4

interval: 1s # go Duration syntax, 多久执行一次拉取

last-for: 1m # 持续多久

timeout: 2s # 请求超时时间

hint:由于 crontab 的最小粒度为分钟级别，可以设置 last-for = 1m, 并且每分钟执行 fetcher.sh 实现更小粒度拉取

```

执行fetcher.sh，该脚本已经放在crontab定时任务中

检查recover-info.json是否是最新的：

/data/learner-recover/learner-recover/config/recover-info.json

检查 config/recover-info.json 是否已经有数据，正常来说应该包含一下数据：

{"storeIDs":[5,6,4],"clusterID":"6994842895216004854","allocID":4294968296}

非灾备节点的 store id 以及集群的 cluster id、alloc id。

检查 config/rpo.json

{"lag":649801723,"safe-time":"2021-09-02T16:37:39.941238343+08:00"}

lag 代表主集群和灾备 learner 节点的同步延迟。由于本身计算和拉取信息有一定耗时，所以实际的 lag 时间要比这个更小。

执行灾备切换

执行recover.sh

耗时：2分钟左右

time sh recover.sh |& tee -a recover.log

脚本执行完成后，日志出现success，再去监控查看region health情况，待miss-peer-region-count降为0，则说明灾备切换补副本完成。

在备机上查看集群状态

灾备中控机上查看集群状态，均为Up，此时灾备切换完成。

总结和思考

• Learner recover特性可以提供rawkv(没有tidb组件的集群)的容灾能力；

• Learner recover特性可以实现同城应急和异地容灾；

• learner副本如果能提供读操作的能力，则会分担主集群的读压力。