摘要：针对数据同步状态查看办法，GaussDB(DWS)提供了丰盛的零碎函数、视图、工具等能够直观地对同步进度进行跟踪，尤其是为不便定位人员应用，gs_ctl工具已汇合了大部分相干零碎函数的调用，可做到在任何工夫，从未启动、启动、重建到运行时的要害信息显示。
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所示。具体参数、返回值定义请参考相应版本的产品文档手册。
2.2 零碎函数
总结波及数据同步的零碎函数如表2所示。具体参数、返回值定义请参考相应版本的产品文档手册。
2.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单位显示。
点击关注，第一工夫理解华为云陈腐技术~