常见问题解决
日常监控
cluster
show cluster_nodes; #查看节点信息，是否存在down状态
pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898 #检查主备节点是否正常
pcp_node_info -U admin -h 192.168.2.98 -p 9898 #后端节点信息，是否有udb节点下线
ps aux | grep unvdbcluster #进程是否存在
ip a | grep 192.168.2.98 #高可用Ip是否位于领导节点
/data/udb-clus/log/ #日志是否有报错
udb
select client_addr, sync_state from pg_stat_replication; #在主库检查同步状态是否正常
select pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_flush_lsn(),write_lsn)) delay_wal_size,* from pg_stat_replication ; #在主库检查同步延迟是否过大
/data/backup/ #备份数据是否正常
du -sh /data/udb/ud_wal/ #wal目录是否过大
/data/udb/log/ #日志是否有报错
如何正确重启集群
cluster重启
查看主节点和备节点，最好先重启备节点，再重启主节点
以下命令显示主节点是192.168.2.92，备节点是192.168.2.91
[root@clus-91 ~]# pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898
Password:
2 2 YES 192.168.2.92:9999 Linux clus-92 192.168.2.92
192.168.2.92:9999 Linux clus-92 192.168.2.92 9999 9000 4 LEADER 0 MEMBER
192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 7 STANDBY 0 MEMBER
高可用ip位于92节点
[root@clus-92 ~]# ip a| grep 192.168.2.98
inet 192.168.2.98/24 scope global secondary eth0:0
重启备节点，并检查日志是否有异常报错
[root@clus-91 ~]# systemctl restart unvdbcluster
vi /data/udb-clus/log/unvdbcluster-星期.log (修改为实际目录)
二次检查主备节点信息，确保备节点正常，再重启主节点
[root@clus-91 ~]# pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898
Password:
2 2 YES 192.168.2.92:9999 Linux clus-92 192.168.2.92
192.168.2.92:9999 Linux clus-92 192.168.2.92 9999 9000 4 LEADER 0 MEMBER
192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 7 STANDBY 0 MEMBER
重启主节点，并检查日志是否有异常报错
[root@clus-92 ~]# systemctl restart unvdbcluster
vi /data/udb-clus/log/unvdbcluster-星期.log (修改为实际目录)
最后检查主备节点信息
[root@clus-91 ~]# pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898
Password:
2 2 YES 192.168.2.92:9999 Linux clus-92 192.168.2.92
192.168.2.92:9999 Linux clus-92 192.168.2.92 9999 9000 4 LEADER 0 MEMBER
192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 7 STANDBY 0 MEMBER
高可用ip位于92节点
[root@clus-92 ~]# ip a| grep 192.168.2.98
inet 192.168.2.98/24 scope global secondary eth0:0
注:主节点正常重启操作会比较快，不一定满足触发高可用IP转移条件。具体触发规则参考”cluster配置参数详解”章节。
udb数据库重启
检查udb主从信息，最好先重启从库，再重启主库
以下命令显示192.168.2.81为主库，192.168.2.82为从库
[root@clus-92 udb-clus]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 2 0.500000 up up primary primary 0 none none 2022-08-22 17:36:38
192.168.2.82 5678 2 0.500000 up up standby standby 0 none none 2022-08-22 17:36:38
重启从库，并检查日志 /data/udb/log/unvdb-星期.log(以实际日志为准)
[root@udb-82 ~]# systemctl restart unvdb
登录验证
[root@udb-82 ~]# ud_sql
ud_sql (22.4)
Type "help" for help.
unvdb=#
二次检查主从信息，确保从库正常才能重启主库
[root@clus-92 udb-clus]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 2 0.500000 up up primary primary 0 none none 2022-08-22 17:36:38
192.168.2.82 5678 2 0.500000 up up standby standby 0 none none 2022-08-22 17:36:38
重启主库，并检查日志 /data/udb/log/unvdb-星期.log(以实际日志为准)
[root@udb-81 ~]# systemctl restart unvdb
登录验证
[root@udb-81 ~]# ud_sql
ud_sql (22.4)
Type "help" for help.
unvdb=#
最后检查主从信息
[root@clus-92 udb-clus]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 2 0.500000 up up primary primary 0 none none 2022-08-22 17:36:38
192.168.2.82 5678 2 0.500000 up up standby standby 0 none none 2022-08-22 17:36:38
注意: 主库正常重启操作，不一定满足主从切换。切换条件参考”cluster配置参数详解”章节。
如何分析sql报错
sql报错会在日志/data/udb/log/unvdb-星期.log 中记录，主要根据日志报错进行解决。
如何避免脑裂
cluster 采用 Watchdog来协调多个cluster，避免单点故障或脑裂。 Watchdog对其他cluster节点定期检查，以检测cluster的故障。 如果活动节点故障，则备用节点会自动提升为活动状态，并接管高可用虚拟IP。 同时使用arping，可以快速更新arp表。 最后配合 wd_escalation_command 参数，灵活定义命令。 以上多种方式可以很好的避免单点故障或脑裂。
cluster是如何调度sql请求的？
以下语句不会发生负载均衡，只会调度到主库：
SHOW /* NO LOAD BALANCE */ 后面跟的语句 BEGIN ~ END 区间的语句块 SELECT INTO SELECT FOR UPDATE SELECT FOR SHARE SELECT … COPY TO STDOUT EXPLAIN EXPLAIN ANALYZE SELECT…包含写操作
集群故障如何排查和恢复
cluster主备排查恢复
服务启动后，一定会有一个节点被选为领导者，并自动配置高可用IP
检查cluster服务是否启动,如不能启动则根据 /data/udb-clus/log/ 日志提示解决
[root@clus-92 ~]# ps aux | grep unvdbcluster
检查当前主备状态
以下命令显示 主节点是192.168.2.92，192.168.2.91节点关闭
[root@clus-92 ~]# pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898
Password:
2 2 YES 192.168.2.92:9999 Linux clus-92 192.168.2.92
192.168.2.92:9999 Linux clus-92 192.168.2.92 9999 9000 4 LEADER 0 MEMBER
192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 10 SHUTDOWN 0 MEMBER
检查主节点是否分配高可用ip
如没有分配高可用ip,则根据 /data/udb-clus/log/ 日志提示解决
[root@clus-92 ~]# ip a | grep 192.168.2.98
inet 192.168.2.98/24 scope global secondary eth0:0
恢复从节点192.168.2.91
重启服务，根据日志提示解决。
[root@clus-91 ~]# systemctl restart unvdbcluster
最后检查主备状态
[root@clus-92 ~]# pcp_watchdog_info -U admin -h 192.168.2.98 -p 9898
Password:
2 2 YES 192.168.2.92:9999 Linux clus-92 192.168.2.92
192.168.2.92:9999 Linux clus-92 192.168.2.92 9999 9000 4 LEADER 0 MEMBER
192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 7 STANDBY 0 MEMBER
udb主从排查恢复
udb发生故障导致下线后，必须手动加入集群，主要原因是避免主从混乱导致数据不一致。 主要解决思路是： 分清楚主从库—->修补检查数据—->建立同步关系—->验证同步关系及同步延迟—->加入主库—->加入从库—->验证集群节点状态
场景一 从库不在线
此场景一般是从库发生故障下线，手动加入即可。但加入前一定要确认存在/data/udb/standby.signal 文件，以从库身份加入。
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 2 0.500000 up up primary primary 0 none none 2022-09-27 16:09:35
192.168.2.82 5678 3 0.500000 down up standby standby 0 none none 2022-09-27 14:51:09
确认从库状态
[root@udb-82 data]# ud_controldata -D /data/udb/ | grep -i 'database cluster state'
Database cluster state: in archive recovery
再次从主库上确认从库状态
unvdb=# select * from pg_stat_replication;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backe
nd_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_
state | reply_time
-------+----------+---------+------------------+--------------+-----------------+-------------+------------------------------+------
--------+-----------+------------+------------+------------+------------+-----------+-----------+------------+---------------+------
------+-------------------------------
14109 | 16384 | rep | walreceiver | 192.168.2.82 | | 52076 | 2022-09-27 16:10:09.63818+08 |
| streaming | 0/F8000000 | 0/F8000000 | 0/F8000000 | 0/F8000000 | | | | 0 | async
| 2022-09-27 16:13:35.257112+08
(1 row)
检查同步延迟，如果延迟过大，不建议加入集群
unvdb=# select pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_flush_lsn(),write_lsn)) delay_wal_size,* from pg_stat_replication ;
delay_wal_size | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_star
t | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync
_priority | sync_state | reply_time
----------------+-------+----------+---------+------------------+--------------+-----------------+-------------+--------------------
----------+--------------+-----------+------------+------------+------------+------------+-----------+-----------+------------+-----
----------+------------+-------------------------------
0 bytes | 14109 | 16384 | rep | walreceiver | 192.168.2.82 | | 52076 | 2022-09-27 16:10:09
.63818+08 | | streaming | 0/F8000000 | 0/F8000000 | 0/F8000000 | 0/F8000000 | | | |
0 | async | 2022-09-27 16:15:05.361786+08
(1 row)
加入集群
[root@clus-92 ~]# pcp_attach_node -d -U admin -p 9898 -h 192.168.2.98 -n 1
Password:
DEBUG: recv: tos="m", len=8
DEBUG: recv: tos="r", len=21
DEBUG: send: tos="C", len=6
DEBUG: recv: tos="c", len=20
pcp_attach_node -- Command Successful
DEBUG: send: tos="X", len=4
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 2 0.500000 up up primary primary 0 none none 2022-09-27 16:09:35
192.168.2.82 5678 1 0.500000 waiting up standby standby 0 none none 2022-09-27 16:16:41
场景二 原主库不在线
此场景一般是主库发生故障下线，从库自动提升为主库。 此时需要把原主库配置为从库再以从库身份加入。 但加入前一定要确认存在 /data/udb/standby.signal 文件，以从库身份加入。
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 3 0.500000 down down standby unknown 0 none none 2022-09-27 16:19:29
192.168.2.82 5678 1 0.500000 waiting up primary primary 0 none none 2022-09-27 16:19:29
方式一 直接把原主库标记为从库。适用于下线时间较短，无修改数据的情况
[root@udb-81 data]# chown -R udb.udb /data/udb
[root@udb-81 data]# chmod 0700 /data/udb
[root@udb-81 udb]# systemctl restart unvdb
方式二 重新导入数据到从库。适用于下线时间较长，修改数据较多的情况
[root@udb-81 data]# mkdir udb
[root@udb-81 data]# ud_basebackup -D /data/udb -F p --checkpoint=fast -P -h 192.168.2.82 -p 5678 -U rep
Password:
595885/595885 kB (100%), 1/1 tablespace
[root@udb-81 data]# chown -R udb.udb /data/udb
[root@udb-81 data]# chmod 0700 /data/udb
[root@udb-81 udb]# systemctl restart unvdb
确认从库状态
[root@udb-81 data]# ud_controldata -D /data/udb/ | grep -i 'database cluster state'
Database cluster state: in archive recovery
再次从主库上确认从库状态
unvdb=# select * from pg_stat_replication;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | back
end_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync
_state | reply_time
-------+----------+---------+------------------+--------------+-----------------+-------------+-------------------------------+-----
---------+-----------+------------+------------+------------+------------+-----------+-----------+------------+---------------+-----
-------+-------------------------------
23298 | 16384 | rep | walreceiver | 192.168.2.81 | | 36872 | 2022-09-27 16:21:44.218621+08 |
| streaming | 0/F9000000 | 0/F9000000 | 0/F9000000 | 0/F9000000 | | | | 0 | asyn
c | 2022-09-27 16:22:04.430018+08
(1 row)
检查同步延迟，如果延迟过大，不建议加入集群
unvdb=# select pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_flush_lsn(),write_lsn)) delay_wal_size,* from pg_stat_replication ;
delay_wal_size | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_sta
rt | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | syn
c_priority | sync_state | reply_time
----------------+-------+----------+---------+------------------+--------------+-----------------+-------------+--------------------
-----------+--------------+-----------+------------+------------+------------+------------+-----------+-----------+------------+----
-----------+------------+-------------------------------
0 bytes | 23298 | 16384 | rep | walreceiver | 192.168.2.81 | | 36872 | 2022-09-27 16:21:44
.218621+08 | | streaming | 0/F9000000 | 0/F9000000 | 0/F9000000 | 0/F9000000 | | | |
0 | async | 2022-09-27 16:22:14.460488+08
(1 row)
检查状态并加入集群
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 3 0.500000 down up standby standby 0 none none 2022-09-27 16:19:29
192.168.2.82 5678 1 0.500000 waiting up primary primary 0 none none 2022-09-27 16:19:29
[root@clus-92 ~]# pcp_attach_node -d -U admin -p 9898 -h 192.168.2.98 -n 0
Password:
DEBUG: recv: tos="m", len=8
DEBUG: recv: tos="r", len=21
DEBUG: send: tos="C", len=6
DEBUG: recv: tos="c", len=20
pcp_attach_node -- Command Successful
DEBUG: send: tos="X", len=4
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 1 0.500000 waiting up standby standby 0 none none 2022-09-27 16:30:12
192.168.2.82 5678 1 0.500000 waiting up primary primary 0 none none 2022-09-27 16:19:29
场景三 主从库都不在线,业务不可用
此场景一般是主库和从库都发生故障下线，或者从库没恢复时主库又发生故障。有可能还发生了主从切换。 此时一定要先分清楚主库和从库。确认好同步状态，先加入主库，再加入从库。
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 3 0.500000 down down standby unknown 0 none none 2022-09-27 16:31:19
192.168.2.82 5678 3 0.500000 down down standby unknown 0 none none 2022-09-27 16:31:20
检查所有udb主从状态
[root@udb-82 data]# ls /data/udb/standby.signal
ls: cannot access /data/udb/standby.signal: No such file or directory
#说明82没有从库标记，大概率是主库
[root@udb-81 udb]# ls /data/udb/standby.signal
/data/udb/standby.signal
依次启动主库和从库的服务
[root@udb-82 data]# systemctl start unvdb
确认从库状态
[root@udb-81 data]# ud_controldata -D /data/udb/ | grep -i 'database cluster state'
Database cluster state: in archive recovery
再次从主库上确认从库状态
unvdb=# select * from pg_stat_replication;
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | back
end_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync
_state | reply_time
-------+----------+---------+------------------+--------------+-----------------+-------------+-------------------------------+-----
---------+-----------+------------+------------+------------+------------+-----------+-----------+------------+---------------+-----
-------+-------------------------------
23298 | 16384 | rep | walreceiver | 192.168.2.81 | | 36872 | 2022-09-27 16:21:44.218621+08 |
| streaming | 0/F9000000 | 0/F9000000 | 0/F9000000 | 0/F9000000 | | | | 0 | asyn
c | 2022-09-27 16:22:04.430018+08
(1 row)
检查同步延迟，如果延迟过大，不建议加入集群
unvdb=# select pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_flush_lsn(),write_lsn)) delay_wal_size,* from pg_stat_replication ;
delay_wal_size | pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_sta
rt | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | syn
c_priority | sync_state | reply_time
----------------+-------+----------+---------+------------------+--------------+-----------------+-------------+--------------------
-----------+--------------+-----------+------------+------------+------------+------------+-----------+-----------+------------+----
-----------+------------+-------------------------------
0 bytes | 23298 | 16384 | rep | walreceiver | 192.168.2.81 | | 36872 | 2022-09-27 16:21:44
.218621+08 | | streaming | 0/F9000000 | 0/F9000000 | 0/F9000000 | 0/F9000000 | | | |
0 | async | 2022-09-27 16:22:14.460488+08
(1 row)
检查业务数据是否正常
检查状态并加入集群
#检查节点状态，第一行0号为从standby，第二行1号为主primary
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 3 0.500000 down up standby standby 0 none none 2022-09-27 16:31:19
192.168.2.82 5678 3 0.500000 down up standby primary 0 none none 2022-09-27 16:31:20
#先加入主库
[root@clus-92 ~]# pcp_attach_node -d -U admin -p 9898 -h 192.168.2.98 -n 1
Password:
DEBUG: recv: tos="m", len=8
DEBUG: recv: tos="r", len=21
DEBUG: send: tos="C", len=6
DEBUG: recv: tos="c", len=20
pcp_attach_node -- Command Successful
DEBUG: send: tos="X", len=4
#再次检查状态
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 3 0.500000 down up standby standby 0 none none 2022-09-27 16:31:19
192.168.2.82 5678 1 0.500000 waiting up primary primary 0 none none 2022-09-27 16:41:53
#再加入从库
[root@clus-92 ~]# pcp_attach_node -d -U admin -p 9898 -h 192.168.2.98 -n 0
Password:
DEBUG: recv: tos="m", len=8
DEBUG: recv: tos="r", len=21
DEBUG: send: tos="C", len=6
DEBUG: recv: tos="c", len=20
pcp_attach_node -- Command Successful
DEBUG: send: tos="X", len=4
#再次检查状态
[root@clus-92 ~]# pcp_node_info -U admin -h 192.168.2.98 -p 9898
Password:
192.168.2.81 5678 1 0.500000 waiting up standby standby 0 none none 2022-09-27 16:42:03
192.168.2.82 5678 1 0.500000 waiting up primary primary 0 none none 2022-09-27 16:41:53
场景四 多个主库，无从库情况。
此场景一般是主库发生故障下线，从库自动提升为主。但原主库又以主库身份被误操作加入集群。 此时一定要先分清楚主库和从库。确认好同步状态，先加入主库，再加入从库 同时也要确定是否产生数据混乱，必要时进行手动修补数据。
参考 场景三 先分清楚主从库，再建立同步关系，最后依次加入主从库
场景五 多个从库，无主库情况
此场景同场景四相似，但数据混乱的可能性不高。 参考 场景三 先分清楚主从库，再建立同步关系，最后依次加入主从库
当从节点产生严重延迟时，cluster还会不会调度到这个节点
以下配置与延迟检查相关，当延迟大于delay_threshold或检查失败时，不会调度到对应节点。 ##复制延迟检查配置 sr_check_period = 10 #基于流复制的延迟检查间隔秒数 sr_check_user = ‘udb超级用户’ #延迟检查使用的用户名 sr_check_password = ‘超级用户密码’ #延迟检查使用的密码 sr_check_database = ‘unvdb’ #延迟检查使用的数据库 delay_threshold = 1000000 #如果从库延时超过这个字节点，将停止向从库发送查询操作，将所有操作调度到主库。
集群连接失败-后端服务器全部下线
报错:
server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
原因:
后端服务器全部不在线
解决:
1,检查后端节点状态
/data/soft/unvdbcluster/bin/pcp_node_info -U admin -p 9898 -h 高可用IP Password: 192.168.2.81 5678 3 0.500000 down up standby primary 0 none none 2022-09-08 16:10:07 192.168.2.82 5678 3 0.500000 down up standby standby 0 none none 2022-09-08 16:22:38 如上表示所有节点都是down状态，并且2.81是主实例
2，检查2.81主实例状态
在主节点执行 /data/soft/unvdb/bin/ud_controldata -D /data/udb/ Database cluster state: in production #表示当前数据目录是主实例， #Database cluster state: in archive recovery #表示当前数据目录是从实例
3，启动数据库
systemctl start unvdb 如启动失败，分析/data/udb/log/日志
4，检查数据正常
ud_sql 登录数据库，检查数据是否正常。
5，加入群集
pcp_attach_node -d -U admin -p 9898 -h 高可用ip -n 0 #把0号节点加入集群 此时集群可以正常连接，按以上步骤依次加入其它节点即可。
集群连接失败-高可用ip不可用
报错:
could not connect to server: Connection refused Is the server running on host “高可用ip” and accepting TCP/IP connections on port 9999?
原因:
高可用ip不可用，或防火墙拒绝访问
解决:
首先，连接任意一个节点IP，如不正常，尝试重启集群服务systemctl start unvdbcluster，并检查 /data/udbclus/log/ 日志进一步分析原因；如正常则继续； 然后，检查可用节点IP集群高可用IP信息 /data/soft/unvdbcluster/bin/pcp_watchdog_info -U admin -p 9898 -h 可用节点本身IP，非高可用IP Password: 2 2 YES 192.168.2.91:9999 Linux clus-91 192.168.2.91 192.168.2.91:9999 Linux clus-91 192.168.2.91 9999 9000 4 LEADER 0 MEMBER Not_Set 192.168.2.92 9999 9000 0 DEAD 0 MEMBER 此例显示2.91节点是领导者，高可用IP应该位于此节点 最后，重点检查2.91节点，ifconfig 检查是否存在高可用IP，如不存在，尝试重启此节点集群服务systemctl start unvdbcluster；如存在高可用IP则重启检查防火墙配置
canceling statement due to conflict with recovery
报错:
ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed. STATEMENT: select ….
原因:
此类错误通常出现在从库，原因是此查询操作会被负载均衡调度到从库， 但此时从库正在重放主库的wal日志(在主库相关数据的删除修改等写操作)和当前的查询操作冲突
解决方案一:
在报错的sql前添加 /* NO LOAD BALANCE */ ，使sql不使用负载均衡，强制调度到主库。从而避免此类错误发生。
解决方案二:
修改配置文件，适当提高 max_standby_streaming_delay = 30s #当发生冲突时，从库等待wal应用的最长时间。如果冲突语句在此时间段之后仍在运行，则 udb 将取消该语句并发出以下错误消息ERROR: canceling statement due to conflict with recovery max_standby_archive_delay =30s #冲突的查询执行的最大时间，一旦超过此值，查询将被取消。 注意，以上参数可能会增加同步延时。
DEBUG调试
DEBUG 会记录所有sql及watchdog等详细日志，要特别注意日志文件增长会非常快。
vi /data/udb-clus/start.sh
找到$UNVDBMGR -D ... 添加 -d 参数，即可开启debug
systemctl restart unvdbcluster#重启生效