在synchronous_standby_names='*'时gs_probackup备份失败的问题

【标题描述】:
搭建主备，设置synchronous_standby_names='*'。在备机无法连接时，gs_probackup从主库备份失败。

【测试版本：】
2023-1-11 master分支

【预置条件】:

【操作步骤】(请填写详细的操作步骤):
使用gs_probackup工具执行全量备份

【预期输出】:
备份成功

【实际输出】:

```
lchch@lchch:~/h2/xxxx/data$ gs_probackup backup --instance testBackUp -b FULL --stream --temp-slot -h 127.0.0.1 --password=123qweQWE -B /home/lchch/bug/bk_dir
INFO: Backup start, gs_probackup version: 2.4.2, instance: testBackUp, backup ID: ROB9MT, backup mode: FULL, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1
LOG: Backup destination is initialized
LOG: This openGauss instance was initialized with data block checksums. Data block corruption will be detected
LOG: Database backup start
LOG: started streaming WAL at A/3F000000 (timeline 1)
[2023-01-11 15:47:17]: check identify system success                                                
[2023-01-11 15:47:17]: send START_REPLICATION A/3F000000 success                                    
INFO: Cannot parse path "base"
[2023-01-11 15:47:17]: keepalive message is received                                                
INFO: PGDATA size: 1151MB
INFO: Start transferring data files
[2023-01-11 15:47:17]: keepalive message is received                                                
LOG: Creating page header map "/home/lchch/bug/bk_dir/backups/testBackUp/ROB9MT/page_header_map"
[2023-01-11 15:47:20]: keepalive message is received                                                
[2023-01-11 15:47:23]: keepalive message is received                                                
[2023-01-11 15:47:23]: keepalive message is received                                                
INFO: Data files are transferred, time elapsed: 6s
[2023-01-11 15:47:26]: keepalive message is received                                                
.......大量重复log                                           
[2023-01-11 15:49:23]: keepalive message is received                                                
[2023-01-11 15:49:23]: keepalive message is received                                                
ERROR: query failed: wait 127.0.0.1:10020 timeout expired
query was: SELECT pg_catalog.pg_create_restore_point($1)
WARNING: backup in progress, stop backup
ERROR: query failed: no connection to the server
query was: SET client_min_messages = warning;
ERROR: query failed: no connection to the server
query was: SET datestyle = 'ISO, DMY';
WARNING: query failed: no connection to the server
query was: SELECT pg_catalog.txid_snapshot_xmax(pg_catalog.txid_current_snapshot()), current_timestamp(0)::timestamptz, pg_catalog.pg_stop_backup() as lsn
ERROR: Failed to send pg_stop_backup query
ERROR: pg_stop backup() failed
WARNING: Backup ROB9MT is running, setting its status to ERROR
lchch@lchch:~/h2/xxxx/data$
```

【原因分析】:
1.在设置synchronous_standby_names='*'的情况下，gs_probackup工具连接数据库的stream线程被数据库认为是一个同步备，需要去参与日志一致性确认。在备机停掉时，当前只有gs_probackup工具的stream线程被认为是活跃的同步备。

2.gs_probackup程序没有实时向数据库反馈自己收到的wal位点，因此gs_probackup工具的stream线程不具备同步备的反馈功能。

3.gs_probackup工具在备份结束时，需要向数据库发送select pg_create_restore_point()命令，这个命令会写wal日志，这个命令由于无法完成wal的同步等待，因此会hung。

4.这个命令2min超时后，备份失败。

【解决方案】:

如下代码可以使gs_probackup具备向数据库返回wal位点的功能，可以解决备份失败的问题，
但有一些需求问题，比如gs_probackup是否应该被认为是一个同步备。

```
Author: movead <lchch1990@sina.cn>
Date:   Wed Jan 11 10:31:29 2023 +0800

fix #63106375 modify gs_probackup it will feedback wal lsn to master after write to wal file

diff --git a/src/bin/pg_basebackup/receivelog.cpp b/src/bin/pg_basebackup/receivelog.cpp
index c3accc749..6c315b7e9 100644
--- a/src/bin/pg_basebackup/receivelog.cpp
+++ b/src/bin/pg_basebackup/receivelog.cpp
@@ -494,7 +494,7 @@ static int DoWALWrite(const char* wal_buf, int len, XLogRecPtr& block_pos, const
             suspendHeartBeatTimer();
             return DO_WAL_DATA_WRITE_ERROR;
         }
-
+        lastFlushPosition = block_pos;
         /* Write was successful, advance our position */
         bytes_written += bytes_to_write;
         bytes_left -= bytes_to_write;
@@ -586,14 +586,12 @@ bool ReceiveXlogStream(PGconn* conn, XLogRecPtr startpos, uint32 timeline, const
          * so that the master can remove WAL.
          */
 
-        reportFlushPosition = true;
         ss_c = snprintf_s(slotcmd, MAXPGPATH, MAXPGPATH - 1, "SLOT \"%s\" ", replication_slot);
         securec_check_ss_c(ss_c, "", "");
     } else {
-        reportFlushPosition = false;
         slotcmd[0] = 0;
     }
-
+    reportFlushPosition = true;
     if (sysidentifier != NULL) {
         /* Validate system identifier and timeline hasn't changed */
         res = PQexec(conn, "IDENTIFY_SYSTEM");
```

openGauss/openGauss-server

内容风险标识

评论 (6)

openGauss/openGauss-server .gitee-modal { width: 500px !important; }

内容风险标识