GaussDB(DWS)高可用之备机重建

DWS的多实例在主机故障时，会发生failover，但对于主备机这种分布式架构，必然会有数据同步的时延，这种时延就会产生如下主备机日志分叉的问题

（可以参考该贴日志分叉部分https://bbs.huaweicloud.com/forum/thread-60315-1-1.html）：

对于支持UNDO的数据库来说，可以通过UNDO日志将原主机分叉的部分回退到分叉前的一条wal日志，然后接上新主继续从不分叉的地方开始做wal日志同步，但是对于PG这类不支持UNDO的系统来说，这部分数据需要通过特殊的方式来处理，这种操作叫做增量重建（思路类似于社区的pg_rewind，但略有不同）。

增量重建的基本的原理如下：

分为以下几类数据：

part1、从分叉点开始，原主机自己生成的wal日志对应的数据，这部分通过反解wal日志，记录下wal对应的数据页，并从新主机同步

part2、原主机的数据文件和新主机的数据文件的列表做差异化比较 ，“拉齐”和新主机的数据

以上数据部分同步后，相当于将原主对齐到新主机的一个时间点，并将原主机wal日志重新拉回到同一条wal日志线上。

最后关键的一步，就是原主机作为备角色启动后，需要继续追赶在重建过程中的delta数据（整个重建过程中，新主机仍然在做业务），确保最终的一致性。

再来解答一下之前有个同学咨询的关于拉齐的原则，这里实际是按照物理文件来处理的，处理的方式是基于size，对于size不一样的文件，会做不同的处理，一般原则如下：

（以local作为本地要做build的节点，而remote代表要从远端同步数据的节点为例）

1）对于local_file_size < remote_file_size时，说明对应的表有新增的数据，此时需要将local_file做copy_tail的动作

2）对于local_file_size > remote_file_size时，由于有mvcc的机制，说明远端的表可能做过vacuum，因此对于tuple的位置均发生的变化，此时，需要先将本地的文件全部truncate掉，然后从远端copy完整文件到本地

3）对于从分叉点解析的本地做过modify的页，则单独标记出来，按照页copy的方式，从remote侧进行页copy。