共计 2807 个字符，预计需要花费 8 分钟才能阅读完成。
本文次要介绍 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 的备库重搭，最初通过两个案例形容了备库重搭的理论使用。心愿读者有所启发，利用备库两个根本的性能：节点复原和迁徙，在实在场景中解决问题。
作者：不俗
原文链接
本文为阿里云原创内容，未经容许不得转载。
