1    需求介绍

    GaussDB(DWS)的实例在运行过程中难免发生故障，引起实例错误或无法启动，此时就需要进行备机重建工作。备机重建功能主要目的是修复实例单点故障，此外，还可用于集群安装的初始化、集群扩容的元数据同步、节点故障后的温备替换等等场景。本文将介绍备机重建各种方法的实现机制，并结合应用场景分析，以及对新增参数的使用建议，以期获得最佳应用效果。

2    设计方案

2.1 功能分类

    备机重建按照实现方式不同分为：全量重建和增量重建。

    备机重建需要在待修复主机上运行gs_ctl build工具。在备机重建过程中，均需要和主DN建立连接进行数据的交互访问。在gs_ctl工具的命令行参数中通过–b=mode参数，可以指定重建DN备机的模式。目前mode支持的取值包括以下四种：

    full：全量重建，通过获取主备之间全量镜像差异的方式重新同步DN主机的数据目录。

    fullcleanup：全量重建，通过全量镜像的方式重新同步DN主机的数据目录。与full模式区别为：同步前需要清理DN备机的数据目录，保留配置文件。主机将自己的数据目录除了配置文件外，全部发给备机。

    incremental：增量重建，通过解析WAL日志获取主备DN差异的数据进行增量修复备DN。

    auto(不指定-b)：先增量重建，增量重建失败后进行全量重建。

    实际生产环境中，具体使用哪种方式，就需要看需求与应用场景所定。

2.2 应用场景

    备机重建按照功能场景不同分为：DN Build DN、CN build CN、CN Build DN。各Build的应用场景的特点如下：

表1 Build的应用场景

     选择何种修复方式最优，需要理解该模式的工作原理，并根据应用场景合理地设置相关参数。

3    实现过程

3.1 fullcleanup mode:基于推送方式

    fullcleanup mode是一种推送模式，在该模式下，由主机来控制数据流程（我给啥你接啥），在不关心备机损坏程度和范围的情况下，需要主机将自己的数据目录配置文件外的全部数据传送给备机，重建后启动备机。

    其主要工作过程如图1所示：

图1 fullcleanup build工作过程

    fullcleanup mode build的特点很明显，备机将得到彻底重建。但缺点也很明显：主机需要Copy实例上全部的数据和XLOG日志文件，占用较高的网络传输带宽，对运行中的业务有一定影响。备机没有对修复前数据进行原子化管理，过程中一旦失败将无法恢复到原备机。如果全量Build过程中由于偶发网络等原因故障失败，将前功尽弃，再次Build数据需要从头再来。

    所以该方式是最保守的最后选项，是在其它重建方式均无效的时候的一种选择。

3.2 full mode:基于文件校验获取差异的拉取方式

    full mode是一种拉取模式，在该模式下，由备机来控制数据流程（我需要啥拿啥），仅需要补齐主备之间的差异数据。但前提是备机需要知晓自己与主机差异。full mode是直接从文件比较进行切入，主、备机可以同时多线程（并行、并发，提升性能）在各自本地上对数据目录文件进行遍历，获知文件有无、大小、文件校验计算等信息；通过这些信息，不断对计算结果File Map List进行合并筛选，获得最小的差异文件集合，减少数据/文件的拷贝数量。备机既可以仅备份备机的差异文件作为备份集（满足可靠性），又可以仅拉取主机的差异文件来更新（提升性能）；备机可以采用多线程（并发，提升性能）同时从主机拉取文件。

    其主要工作过程如图2所示：

图2 full build工作过程

     full mode build的特点是充分利用备机已有的文件，减少数据同步的数量，可以方便地进行备份和恢复、和并行控制。但需要花费一定时间的本地IO和计算为代价。与fullcleanup mode相比较在无资源瓶颈条件下通常速度更快（可获得数倍的提升），可靠性上更安全，是全量build的首选。

3.3 incremental mode:基于Xlog分析获取差异的拉取方式

    incremental mode是另外一种拉取方式。适用于主备双主等因日志造成的不一致场景。增量重建是一种以主DN文件和备DN的WAL日志为基准，按照多退少补的原则对备DN文件和文件块进行修复。与全量重建相比较，拷贝的粒度、数据量和WAL日志量都更少，代价更小。

    其主要工作过程如图3所示：

图3 incremental build工作过程

     incremental mode build只适用于主备双主等因日志造成的不一致场景。备机数据文件损坏、数据目录丢失等故障通过增量重建的方式无法修复，此时可通过全量重建的方式重新修复备机。

4    思考总结

    随着备机重建功能的性能提升和可靠性的增强，build新增了部分参数，在使用时候值得了解和注意。

4.1 -T THREAD-NUMBER

    适用于拉取方式的full和incremental模式。其功能是在备机侧指定与主机连接个数，用于多线程并发进行计算和与文件拉取。

    通常情况下默认值为4已可获得较好的性能，在资源允许的情况下，建议使用更高的线程数。但需注意的是增大线程数目可以提升Build的性能，缩短其重建时间，但相应的也增加了网络连接、CPU、和网络IO的消耗，在使用时候需要考虑资源状况，合适设置。

4.2 -u

    适用于支持原子化功能的full和incremental模式。其功能是Build过程中将不进行原子化恢复和备份，适合于空间不足或无需备份的需要场景中。

    Incremental build默认是原子化，过程中严格进行原子化恢复和备份，过程中出错可恢复，排除错误后，可再次调用重入。由于Full Build的涉及的数据文件量大，默认无原子化，但会尝试进行原子化恢复，忽略恢复结果成败，仅在备机拉取主机上的文件占其总量20%内进行备份。在使用时最好明确指出需要或者不需要原子化功能。

4.3 -B --backupdir=DIR

    适用于支持原子化功能的full和incremental模式。其功能是Build过程中将从指定的路径下进行备份集的恢复和备份。适合于强高可靠需求场景，在Build成功之前可保持备份的原子化，避免原始备份丢失。

    需要注意的是，用户指定备份集路径的磁盘剩余空间应大于DN实例数据目录大小。且备份路径下保持空白或者是本节点的数据集，无关数据将会造成备份集失效，重新生成的备份集会让原始数据副本有丢失的风险。除pg_rewind_bak路径外，用户指定备份集路径的应与备机实例工作路径隔离。

    想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技~