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