本文主要介绍PolarDB-X中DN（数据节点）备库重搭的背景，以及polardbx-operator上是如何实现DN备库重搭的。
背景
在一个一主多从的高可用系统中，往往存在一个主节点负责对外提供服务，另外一个或者多个备节点，向主节点实时同步数据，当主节点发生异常时，会有一个备节点立马切换为主节点，继续对外提供服务，此时对业务来说，仅仅是发生一次连接闪断，重试便能恢复。备节点越多，则这个系统变得完全不可服务的几率就越小，因此我们需要有足够多的备节点来保证高可用性，当备节点发生异常时，我们需要及时进行重建，上述重建操作，我们称之为备库重搭。 一个完整的PolarDB-X实例，由计算节点、存储节点、元数据节点、日志节点组成，其中计算节点和日志节点为无状态部署，当迁移节点的时候不需要迁移数据，只需要给配置、给资源便能正常拉起，而存储节点和元数据服务节点是有状态部署，当备节点不可用时，我们需要迁移数据来恢复节点（在本文我们统称为DN备库重搭）。 存储节点和元数据服务节点是XDB实例(基于mysql进行了改造和升级)，其架构如下图所示：
一个XDB实例，由leader、follower、logger节点构成，三个节点通过xpaxos协议通信并实现多数派决策，形成了一个paxos group，三个节点均会在本地持久化consensus log，另外Leader和Follower还存有mysql数据文件（回放consensus log所得），当Follower升级为Leader时，可以利用mysql数据文件对外提供服务。 当Follower和Logger节点由于软件bug、宿主机宕机、数据文件损坏等原因无法继续正常参与paxos通信的时候，我们需要对其发起重搭操作。
方案设计
关键问题
- Follower和Logger节点重搭有什么区别？
follower相比logger节点需要恢复mysql数据文件，恢复的时候需要从leader节点拷贝数据文件。
- 如何对Follower节点重搭？
一次类似mysql的备份恢复流程，追平增量数据，加入到paxos group中开始正常运行。
- 如何对Logger节点重搭？
从leader节点获取当前的一致性位点，写入logger节点的元数据，加入到paxos group中开始正常运行。
- 如何减少重搭对用户业务的影响？
Follower重搭的时候，可能需要从Leader节点上复制大量的数据，复制过程需要减少大锁的使用以免阻塞用户业务操作，另外需要对拷贝速度的进行控制，以免占用过多cpu、内存、网络带宽、磁盘io等资源，对正常业务所需的资源产生争抢。
- 本机备库重搭和跨机备库重搭？
顾名思义，本机备库重搭的意思是follower节点在原来的宿主机上进行重建，跨机备库重搭则表示follower节点不在原来的宿主机上进行重建。运维任务可以根据实际需求在下发备库重搭任务时候指定是否跨机重搭，比如机器资源不足的时候，而原宿主机仍然健康，则可以选择本机备库重搭，反之本机不健康且机器资源充足，则建议选择跨机重搭。
Follower重搭
对Follower重搭时候，首先确定一个目标的主机，在这个host上恢复出一个follower节点来，在跨机重搭的时候，我们可以通过创建一个配置和原Follower Pod一样的临时pod，由k8s调度器将pod调度到合适的主机上，来确定目标主机。确定Leader Pod、目标主机，我们便可以利用DN专用的备份工具发起一次流式备份，让备份集直接落盘到目标主机上。
备份完成后，发起RecoverJob，恢复任务的Pod的挂载目录包括Follower的数据目录和备份集目录，使用备份工具发起恢复任务，主要为回放redo日志，并把数据文件从备份集目录移动到Follower的数据目录。相比普通MySQL的恢复流程，我们的DN还需要做一次刷新三节点元数据的操作，主要告诉当前节点自己是Follower还是Logger，还有其他节点的地址信息。
之后便是重新拉起Follower，让Follower追平leader上的consensus log，我们便得到一个恢复成功的Follower节点。
Logger重搭
对Logger重搭的时候，因为Logger不需要存数据文件，所以我们不再需要在Leader做一次备份，可直接从Leader获取当前的consensus log的位点，在一个刚刚初始化好的节点上，刷元数据，即告诉这个节点：自己的角色、consensus log位点、其他节点的地址信息。其他的实现流程上，比如临时pod、恢复Job的创建，节点拉起等，则和Follower重搭类似。
应用案例
备库重搭主要作用包含：恢复节点和迁移节点，我们可以利用这两个特性做很多事情。在实际的运维中，备库重搭我愿称之为运维神器。在polardbx-operator中，我们无需关心follower节点还是logger节点，只需要在配置文件中指定pod的名称（参考备库重搭），polardbx-operator会去识别节点类型进行相应的任务，以下讲解我们将不再区分Follower和Logger节点的备库重搭。
案例一 节点故障恢复
导致节点故障的原因有很多，我们只需要判断是否为宿主机故障导致的节点故障，这决定了我们是采用本机重搭还是跨机重搭
案例二 节点迁移
表面上备库重搭是一种恢复备库的手段，然而它所具备的节点迁移能力，可以在非故障场景下也发挥出很大的作用，比如旧主机下线，我们可通过指定主机重搭的方式，把节点迁移到新主机上。如果遇到需要迁移的节点是主节点，则通过主动HA切换将主节点切换为备节点，再利用备库重搭进行迁移。接下来，我们通过一个典型例子，讲解如何利用备库重搭，手工地将一个机房的xdb实例，在保证用户业务不中断的情况下，将该xdb实例迁移到另外一个机房。 初始状态下，一个xdb实例的leader、follower和logger节点分别分布在可用区1（一般情况下可以认为是一个机房）里的主机1、主机2和主机3上。我们需要把整个xdb实例迁移到可用区2去，那么我们如何通过备库重搭来实现节点的迁移呢？
首先，我们可以通过备库重搭中指定主机重搭的方式，将follower节点和logger节点分别迁移到可用区2里的主机2和主机3上，如下图所示：
接下来，做一次主动HA切换，将Leader角色切换到可用区2的主机2上，接着在使用指定节点跨机备库重搭，将可用区1的主机1上的follower节点迁移到可用区2的主机1上，如下图所示：
结尾
本文我们首先讲解了什么是备库重搭，之后讲解了polardbx-operator如何实现对DN的备库重搭，最后通过两个案例描述了备库重搭的实际运用。希望读者有所启发，利用备库两个基本的功能：节点恢复和迁移，在真实场景中解决问题。
作者：不俗
本文为阿里云原创内容，未经允许不得转载。