GaussDB(DWS)实例长期处于catchup问题分析

主、备、从高可用架构

主、备、从数据发送的逻辑图：

图1-DN高可用架构

如图1所示，DN主备实例采用强同步模式，保证主机故障时备机有一份完整数据对外提供服务。当主备从均正常时，数据只发送给备机，从备空闲，从备正常状态下不提供服务，备机down掉之后主机还是提供写服务，将数据备份发送至从备。

主备同步原理

保证主备实例数据强一致性依赖数据同步机制，主要分为日志同步与数据页同步，如图2所示，WalSend与DataSend在主机实例上运行分别负责发送日志文件与数据页发送至备机或从备(在备机故障情况下发送至从备)，WalReceiver与DataReceiver，在备机或从备实例运行负责接收后并有对应线程将其落盘达到数据强一致。

图2-主备实例数据同步框架

日志同步

主机记录XLOG后，会定期写到磁盘上，WalSend线程会读取磁盘上日志，通过TCP网络发送给备机WalReceiver线程，该线程接收后会写到一个内存队列中，WalRecWriter线程定时从队列里取出来写盘，并更新备机写盘LSN，WalReceiver线程回复主机消息时把改值发送给主机。恢复日志线程定期读取磁盘上XLOG对日志进行REDO。

数据页同步

主备数据同步通过XLOG事务日志同步。在大量写事务场景下，会产生大量的XLOG日志，主机需要先将XLOG下盘，然后日志同步进程读取XLOG发送给备机，备机收到XLOG日志后下盘，然后恢复进程读取日志进行REDO。这个过程主备一共有两次写IO和两次读IO请求。

在OLAP场景中，普遍数据量都很大，并且很多场景往往只需要查询某张表中的某一列数据，这样通常采用列式存储格式。不仅有利于性能提升，并且按列存储，数据格式一样，非常利于压缩，节省存储空间。由于按列存储时，如果再按行存储方式去导入一行记录一条日志，那么性能将非常慢，如果没有日志，将无法实现主备同步目的，因此需要探求一种新的数据同步方式。

基于上面两个方面考虑，我们设计了数据复制通道，即数据导入到DN后，组成一个个最小存储单元（行存按页面大小8K为单位，列存按CU大小8K为单位），然后发送给备机，备机接收到后，将数据写盘，并回复主机写盘数据逻辑位置（主机发送时，给每个数据单元设置一个uint64位单调递增的偏移位置，类似于XLOG中的LSN），主机在事务提交前，如果该事务要求写盘数据已经传输给备机那么即可提交。

图3-数据页同步流程

数据复制只有在行存批量导入数据和列存导入数据时触发，如图3所示，数据导入后，存储层将多个数据tuple组成一个个数据最小存储单元，并将其发到发送队列中，DataSend线程将从发送队列中取数据通过TCP网络发送给备机DataReceiver线程，该线程接收数据后会写到一个内存队列中，由DataRecWriter线程从队列中读取并解析出每个数据单元写盘，并更新写盘逻辑偏移位置，在DataReceiver回复主机消息时将该值发送给主机。数据复制过程中数据直接由DataRecWriter写盘，不需要恢复日志线程去恢复数据。

注：主备同步常用视图：

select * from pgxc_get_senders_catchup_time();

主备同步常见问题

场景一：业务慢，集群状态长时间有catchup

【问题描述】

业务变慢，查看集群状态多对实例处于catchup状态

【机制说明】

该场景下catchup原因一般都是由于某些业务在短时间内产生较多xlog文件，主备同步不及时，此时主备同步有排队情况影响事务提交导致业务出现比较卡的现象。

造成该问题主要有带索引导入、频繁delete、频繁truncate、update导致，此时需要解析xlog查看对应操作以及相关业务表。

对于此类问题我们主要任务是通过解析xlog找出对应表让业务侧沟通进行整改。

【问题分析】

进入某一catchup实例路径，使用pg_xlogdump解析其中一个xlog文件: pg_xlogdump $xlog_filename

带索引导入场景：

频繁delete或delete整张表场景：

2、通过解析xlog当中database与表对应OID解析该表所在库以及对应表名，以便业务侧排查

对应库与表OID如上红框所示，连接对应DN通过以下命令查到该表对应数据库、schema与表名

select * from pg_database where oid = xxxx;

select * from pg_class where relfilenode = xxxx;

select * from pg_namespace where oid = xxxx

注：若确定进入库没有问题，对应表在pg_partition或pg_class中都找不到，说明该表被删除或正在创建事务还未提交可执行以下命令后查询（该只读事务在退出当前会话后会自动回滚）：

start transaction read only;

set enable_show_any_tuples = true;

set enable_indexscan = off;

set enable_bitmapscan = off;

【问题结论&&建议】

1、带索引表入库产生大量xlog日志同步不及时导致catchup，影响事务提交引起业务卡。

2、建议入库前删除索引，入库完成后进行索引重建。

3、业务侧尽量避免对单张表进行频繁update、delete、truncate操作。

场景二：集群状态长时间处于catchup状态（超过24小时）

【问题描述】

查看集群状态或查看追赶视图长时间（超过24小时甚至更长时间）有实例处于catchup状态

【问题分析】

问题定界：查看主实例日志是否有锁超时日志，若主实例有相关超时日志说明为此场景，按照问题修复方案整改即可。

【问题修复】

出现该问题是由于catchup与dml语句抢锁导致，主实例锁超时日志会打印抢锁语句，此时kill正在执行的dml语句即可（关注最新锁超时语句即可），继续观察主实例日志确保无锁超时日志说明是正常情况等待catchup结束即可；若kill业务后频繁有所超时日志建议与客户协商停止业务让catchup做完，不然可能会与新进来的业务一直抢锁导致catchup无法结束。

排查步骤如下：

1、确认catchup以及主实例：

cm_ctl query –Cvd|grep Catchup

查询集群实例catchup状态如下：

1 10-x-179-67 6001 /srv/BigData/mppdb/data1/master1 P Primary Normal | 2 10-x-179-95 6002 /srv/BigData/mppdb/data1/slave1 S Standby Catchup|

3  ASG003  3002 /srv/BigData/mppdb/data1/dummyslave1 R Secondary Normal

2  10-x-179-95 6007 /srv/BigData/mppdb/data2/master2     P Primary Normal | 1  10-x-179-67 6008 /srv/BigData/mppdb/data1/slave2      S Standby Catchup |

3  ASG003 3005 /srv/BigData/mppdb/data2/dummyslave2 R Secondary Normal

根据以上结果catchup实例为6002，对应主实例为6001。

2、查看对应主实例日志

使用omm用户登录6001实例所在节点加载环境变量后进入日志目录：

cd $GAUSSLOG/dn_6001

3、在最新日志文件查看catchup线程号：

grep "catchup" postgresql-2021-xxx.log

查看catchup线程启动日志如下：

2020-07-30 11:26:58.666 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG:  catchup process start to search all bcm files.

2020-07-30 11:57:25.874 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG:  catchup process start to search all bcm files.

4、使用catchup线程查看是否有锁超时信息

grep "281454775105184" postgresql-2021-xxx.log

查看catchup线程启动日志如下：

2020-07-30 11:03:34.275 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG:  catchup process start to search all bcm files.

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG:  thread 281454775105184 still waiting for ExclusiveLock on relation 18486641 of database 112877 after 1200000.124 ms

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 YY003 0 [BACKEND] ERROR:  Lock wait timeout: thread 281454775105184 on node dn_6041_6042 waiting for ExclusiveLock on relation 18486641 of database 112877 after 1200000.124 ms

2020-07-30 11:26:57.558 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 YY003 0 [BACKEND] DETAIL:  blocked by hold lock thread 281420014876320, statement

2020-07-30 11:26:58.666 5f20d1aa.3012 [unknown] 281454775105184 [unknown] 0 dn_6001_6002 00000 0 [BACKEND] LOG:  catchup process start to search all bcm files.

如上结果主实例日志最近时间存在Lock wait日志

锁超时日志下一条日志为对应持锁业务如下：

ERROR:  Lock wait timeout: thread 281454775105184 on node dn_6041_6042 waiting for ExclusiveLock on relation xxof database xx after xx ms

DETAIL:  blocked by hold lock thread 281420014876320, statement , hold lockmode RowExclusiveLock.

4、连接CN查看活跃语句视图找出持锁业务：

select * from pgxc_stat_activity where query like '%$table_name%';

5、与客户协商后停掉该业务：

select pg_terminate_backend($pid);---$pid值见第上一步查询结果

6、继续观察主实例日志没有锁超时日志即可说明在正常同步等待即可，若还存在锁超时日志继续排查即可

总结：

1）其他报错场景：

物理文件损坏：

WARNING invalid page in block xxxx

ERROR：remote read failed from xxx

BCM文件残留：

ERROR: could not open file "base/xx/xxx"：No such file or directory

2）此问题触发原理：

拉起catchup线程同步数据页 -> 数据页面加锁 -> 主机datasender读取页面并发送 -> 备机datareceiver接收

拉起catchup线程同步数据页 -> 加锁失败 -> 读取页面失败 -> 备机datareceiver接收

附

GaussDB(DWS)高可用之数据复制

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

GaussDB(DWS)高可用之主备从HA技术

EI企业智能 Gauss AP 数据仓库服务 GaussDB(DWS)

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。