1 背景概述：

1.1DN高可用架构模型

要理解或描述数据同步的过程机制，需要首先要了解GaussDB(DWS)的DN高可用架构，理解涉及数据同步的各组件的关系、数据类型、数据流向、设计原理和目的。

GaussDB(DWS)的DN高可用架构为主、备、从备架构。即在分布式环境中，完整的集群数据采用分片技术分布在多个DN组上，每组DN承担一个数据分片，包括：一个主DN、一个备DN和一个从备DN。主和备各有一份完整的数据，从备上一般不存储数据，仅在备机故障时做数据的暂存。组件之间关系如图1所示：

图1 DN高可用架构关系图

 主、备、从备高可用架构下，主、备及主、从备之间均会建立流复制通道。流复制又分为日志复制和数据页复制。日志复制用于同步主DN由于WAL机制刷到磁盘上的XLOG，同步到备DN进行回放。数据页复制用于同步批量导入的行存数据、或列存CU文件。需要注意的一点是，从备仅用于存放XLOG和数据，回放（replay）仅发生在备DN上。

1.2 数据同步涵盖范围

       数据同步就是涉及集群中主、备节点以及从备节点之间的日志复制数据的传输、回放，数据页复制数据的传输、追赶，备机重建等过程。GaussDB(DWS)集群高可用实践WAL（Write Ahead Logging）思想，并通过各组件的主备的数据同步、倒换、重建等机制，保证数据库单实例遭遇Crash后，具备故障恢复及自愈的能力，保护数据库中数据的可靠性和完整性，最终实现集群对外业务连续性的过程。

这些主要的过程有：

1.        主备之间的正常流复制

每组DN独立承担一个数据分片，因此要求各个DN主与备必须强同步。为保证DN的主备强同步，数据在主DN操作时产生日志，事务提交时将日志同步给备DN。备机对接收到的XLOG进行回放（replay），将日志转为数据。另外，列存和行存批插场景下，备机正常时，新增（变更）数据会发往备机。使用数据页同步相对于日志同步少了磁盘IO，可以提升同步效率，减小RTO。

2.        备机追赶

为了解决单节点故障后集群写事务可用，DN的高可用设计引入从备这个实例。一旦备DN故障，数据将发送给从备，仍然保证了数据写两份的原则，事务照样可以提交。但主机会对BCM文件里面的标记位置状态位。BCM文件中每一bit位（除预留位外）对应数据文件中每一页（8k）状态。

当备机重新启动的时候，会连接主机做数据页追赶（catchup）。追赶机制分为全量和增量两种。全量catchup机制，不依赖于从备，主机递归扫描本地默认表空间和自定义表空间下的所有BCM文件，然后查看状态位来确认哪些数据文件需要发送给备机。增量catchup机制依赖于从备，主机通知从备遍历其从备上暂存的数据页，将变更的数据页列表发往主机，主机直接按照从备发来的变更列表，将变更数据发往备机。

3.        主备倒换

当主DN故障时，需要对备DN进行failover，failover后备DN升为主DN来接管业务。所以failover时，备DN需要连接从备DN，向从备DN请求数据，以补齐备DN比主DN缺少的数据。failover的过程是备DN独立完成的，不需要和主DN进行交互。

4.        备机重建

重建功能主要目的是单点故障修复，备机重建方式按照实现分为全量重建和增量重建，均和主DN进行交互。全量重建是备机清空数据目录，保留配置文件，向主机发送全量重建请求，主机将自己的数据目录除了配置文件外，全部发给备机，重建后启动备机。增量重建是一种以主DN文件为基准，按照文件块对备DN文件进行校验，如果备DN文件的某个文件块校验不一致，则主机将此文件块发给备DN，写入文件对应的文件块中。与全量重建相比较，拷贝的数据量和WAL日志量都更少，代价更小。

 从以上这些数据同步过程中，我们发现表现在运维上一个明显的特点是，这些过程有可能会时间花费较长，一旦同步过程中出现异常问题，其内部关键过程信息输出对于问题分析定位十分重要。因此，GaussDB(DWS)提供了丰富的系统函数、视图、工具等可以直观地对同步进度进行跟踪，尤其是为方便定位人员使用，gs_ctl工具已集合了大部分相关系统函数的调用，可做到在任何时间，从未启动、启动、重建到运行时的关键信息显示。

2 方法总结  

2.1 系统视图

       总结涉及数据同步的系统视图如表1所示。具体参数、返回值定义请参考相应版本的产品文档手册。

表1 系统视图表

2.2 系统函数

总结涉及数据同步的系统函数如表2所示。具体参数、返回值定义请参考相应版本的产品文档手册。

表2 系统函数表

2.3 常用工具

       总结涉及数据同步的常用工具如表3所示。具体工具说明、参数定义请参考相应版本的产品文档手册中的定义。

表3 常用工具表

3 应用场景

3.1 查看DN实例Redo进度

当DN实例crash发生时，我们可以通过回放XLOG日志中记录的数据变化还原crash前的操作。这个就是所谓的redo/recovery过程。如果需要redo的XLOG比较多，或者遇到某种特殊日志类型，对DN实例进行启动，启动过程时间就会有些长。

DN实例启动过程中，如果期望查看XLOG redo的进度。最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示xlog redo的进度，如图2所示。此外，在DN实例可以接受gsql连接时（启动到最小恢复点之前是拒绝连接的），也可直接在当前DN上执行pg_xlog_replay_completion 函数来获取XLOG redo进度信息。

图2 DN实例启动时XLOG Redo进度查询

启动Redo进度相关信息（Xlog replay info）包括：

•   replay_start：Xlog Redo的起始LSN 。DN实例启动XLOG redo过程时，记录replay_start。

•   replay_current：Xlog Redo的当前replay的LSN。

•   replay_end：DN本地接收到的最大XLOG lsn。

•   replay_percent：Xlog Redo的当前完成的百分比。(replay_current - replay_start)*100 / (replay_end - replay_start)的计算值。

依据replay_current的变化，可以看到XLOG redo的推进。

依据replay_percent和启动开始时间，可以推测DN实例启动到正常状态的所需时间。

3.2 查看备机Failover进度

       当主机发生故障时，我们需要将备机failover成主机，此时备机需要连接从备同步XLOG和数据页文件。如果需要同步的XLOG比较多，或者遇到某种特殊日志类型，或者数据文件比较多时，对备DN实例进行failover，过程时间就会有些长。

备机failover升主过程中，如果期望查看XLOG redo和数据页文件同步的进度。最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示xlog redo的进度和从备数据同步的进度，如图3所示。此外，在DN实例可以接受gsql连接时，也可直接在当前DN上执行pg_data_sync_from_dummy_completion 函数来获取从备数据文件同步的进度信息。

图3 备机Failover进度查询

Failover Redo进度相关信息（Xlog replay info），字段含义同Start Redo，区别在于，备DN在处理failover请求连接从备时候获取最新的replay lsn更新了replay_start。

Failover数据页文件进度相关信息（Data sync from dummy）包括：

•   start_index：数据页文件同步的起始编号。

•   current_index：数据页文件同步的当前编号。

•   total_index：数据页文件同步的最大编号。

•   sync_percent：数据页文件当前完成的百分比。(current_index - start_index) *100/ (total_index - start_index + 1) 的计算值。

依据current_index的变化，可以看到数据页同步的推进。

依据sync_percent和failover开始时间，可以推测DN实例failover到正常状态的所需时间。

3.3 查看备机Catchup进度

       当备机重新启动的时候，会连接主机做数据页追赶（catchup）。如果需要传输的数据页比较多，或者因为业务造成的锁冲突，catchup 时间就会比较长，备DN长时间不能成为Normal状态。

如果期望查看数据页catchup的进度，可以在CN上执行select * from pgxc_get_senders_catchup_time()可进行当前活跃的主备发送线程的追赶信息显示，如图4所示。

图4 集群上catchup进度查询

也可以在相应的主DN上执行select * from pg_get_senders_catchup_time可进行当前活跃的主备发送线程的追赶信息显示。完成后，看到的是刚结束的catchup过程信息，如图5所示。

图5 主DN上catchup进度查询

备机Catchup进度相关信息包括：

•   catchup_type："Incremental"或者"Full"。catchup方式为全量还是增量。

•   catchup_bcm_filename：当前主机正在处理的一个BCM文件名称。

•   catchup_bcm_finished：catchup已操作完成的BCM文件数量。

•   catchup_bcm_total：catchup总共需要操作的BCM文件数量。

•   catchup_percent：catchup已经操作完成的百分。catchup_bcm_finished*100 / catchup_bcm_total 的计算值。

•   catchup_remaining_time：依据已完成的进度，预估剩余完成时间。

依据catchup_bcm_filename和catchup_bcm_finished的变化，可以看到数据页追赶的推进。

依据catchup_percent和catchup_remaining_time，可以推测备DN实例追赶到正常状态的所需时间。

3.4 查看DN实例XLOG空间使用状况

       随着数据库的不断运行，产生的日志文件越来越多，如果因为节点故障或其它原因有可能造成日志文件不断积累而充爆磁盘。为了解此使用信息，最方便的是使用gs_ctl query工具对指定DN实例路径进行状态查询，结果中可以显示该实例的XLOG空间使用信息，截图示例请参见上面其它场景。此外，还提供系统函数 pgxc_stat_xlog_space、pg_stat_xlog_space 对数据库集群或单个实例进行查询，例如使用pgxc_stat_xlog_space可以获取到整个集群的CN、主DN的XLOG空间使用信息，如图6所示。

图6 Xlog空间使用查询

XLOG空间使用信息（Xlog space info）包括：

•   xlog_files：pg_xlog目录下，去除backup、archive_status等子目录，所有识别为xlog文件的数目；

•   xlog_size：pg_xlog目录下，去除backup、archive_status等子目录，所有识别为xlog文件的大小之和，以MB单位显示；

•   other_size：pg_xlog目录下backup、archive_status等子目录文件的大小之和，以MB单位显示。