共计 4760 个字符，预计需要花费 12 分钟才能阅读完成。
摘要： 针对数据同步状态查看办法，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 单位显示。
点击关注，第一工夫理解华为云陈腐技术~
