openGauss集羣主庫出現流複製延遲告警

問題描述：環境是openGauss 5.0集羣，在一次意外重啓數據庫之後。收到了一個主庫的主從延遲告警，只有從庫才能出現延遲，主庫怎麼會出現了告警延遲

告警信息：

Status: Resolved
Hostname: hkuatxcrecondb01
IP Address: 192.168.163.21
Alert Message: Opengauss: Streaming lag with {#MASTER} is too high (over 10m in 5m)
Replication: lag in seconds: 0s
Date: 2023.11.13
Time: 11:27:27

 

監控腳本：

/etc/zabbix/script/opengauss/sql/gsql.replication.lag.sql

DO LANGUAGE plpgsql $$
DECLARE
        ver integer;
        res text;
BEGIN
        SELECT current_setting('server_version_num') INTO ver;

        IF (ver >= 100000) THEN
                SELECT * INTO res from (
                        SELECT
                                CASE WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()
                                        THEN 0
                                        ELSE COALESCE(EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp())::integer, 0)
                                END
                        ) T;

        ELSE
                SELECT * INTO res from (
                        SELECT
                                CASE WHEN pg_last_xlog_receive_location() = (pg_last_xlog_replay_location()).lsn
                                        THEN 0
                                        ELSE COALESCE(EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp())::integer, 0)
                                END
                        ) T;
        END IF;

        perform set_config('zbx_tmp.repl_lag_res', res, false);
END $$;

select current_setting('zbx_tmp.repl_lag_res');

 

數據庫主備角色狀態正常，複製視圖還是顯示主庫是主庫，從庫是從庫。根據sql查詢到最後的日誌重放時間維持在重啓的時候。

官方文檔：https://www.postgresql.org/docs/9.1/functions-admin.html

在OpenGauss中，pg_last_xact_replay_timestamp()是一個系統函數，用於獲取最後一個事務在流複製過程中被重放的時間戳。它返回一個時間戳，表示最後一個事務在備庫上被應用的時間。

在主庫上，pg_last_xact_replay_timestamp()函數將返回NULL，因爲主庫不會進行事務重放。只有在備庫上進行流複製時，纔會有事務被重放的情況。

當備庫從主庫接收到事務日誌並應用到備庫上時，pg_last_xact_replay_timestamp()函數將返回最後一個事務的應用時間戳。這個時間戳可以用於監控和診斷備庫的複製進度，以及確定備庫是否與主庫保持同步。

請注意，pg_last_xact_replay_timestamp()函數只在備庫上可用，如果在主庫上調用該函數，將返回NULL。

官方文檔中的解釋：
獲取恢復期間重播的最後一個事務的時間戳。這是在主數據庫上生成該事務的提交或中止 WAL 記錄的時間。如果恢復期間沒有重放任何事務，則此函數返回 NULL。否則，如果恢復仍在進行中，這將單調增加。如果恢復已完成，則該值將保持靜態，爲該恢復期間應用的最後一個事務的值。當服務器正常啓動而沒有恢復時，該函數返回 NULL。
很有可能意外的重啓將數據庫認定成爲了一個恢復狀態。但是這種恢復狀態一直會遞增，我沒有等到這種狀態自動消失

 

根據sql查詢監控值：

openGauss=# select COALESCE(EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp())::integer, 0);
 coalesce
----------
    20888
(1 row)

openGauss=# select * from pg_last_xact_replay_timestamp();
-[ RECORD 1 ]-----------------+------------------------------
pg_last_xact_replay_timestamp | 2023-11-13 11:13:11.445842+08

 

解決方案：其實很簡單，手動去重啓，數據庫的pg_last_xact_replay_timestamp時間戳將會被清理掉

gs_om -t status --detail
gs_om -t restart


gsql ((openGauss 5.0.0 build a07d57c3) compiled at 2023-03-29 03:36:31 commit 0 last mr  )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

openGauss=# select COALESCE(EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp())::integer, 0);
 coalesce
----------
        0
(1 row)

openGauss=#
openGauss=# select pg_last_xact_replay_timestamp();
 pg_last_xact_replay_timestamp
-------------------------------

(1 row)

openGauss=#

 

情景再現：

利用磁盤空間滿，可以製造相同情景