OpenGauss データベース pg_xlog の完全な問題が解決されました

 

記事ディレクトリ

• 問題現象
• 問題を特定する
• 解決
• 要約する

 

問題現象

最近、以前に構築した環境がログインできなくなりました。起動時に次のエラーが報告されます。
[Errno 28] No space left on device

クエリも死んでおり、スペースがないことを示しています。

ディスク使用量を照会します df -h、それは 100% です

当時、環境はアクティブとスタンバイでインストールされていましたが、スタンバイ データベースのサーバーを見てみると、データベースがいつの間にか削除されており、インストール ユーザーがいなくなっていました。

問題を特定する

メイン データベース サーバーをさらに調査した結果、opt ディレクトリの下のスペースが最も疑わしいことがわかりました。

[root@opengauss1 /]# du -lh --max-depth=1

経験によると、data/dn ディレクトリに直行すると、pg_xlog の下に大量のログ ファイルが生成されます。

ファイル数を見ると、1500以上あります。

[root@opengauss1 pg_xlog]# ls -l |wc -l
1591

ただし、pg_xlog は WAL ログであり、直接削除することはできません。別の空き領域の /tmp に新しいディレクトリを作成し、xlog の一部を過去に移動します。

[omm@opengauss1 ~]$ cd /tmp/
[omm@opengauss1 tmp]$ ll
total 0
-rw-r--r-- 1 root root  0 Mar 22 11:40 ck_monitor.lock
drwxr-x--- 2 root root 40 Sep 29 10:00 his-matrixagent_job
-rw-r--r-- 1 root root  0 Mar 22 11:40 monitor.lock
dr-xr-x--- 2 root root 40 May 27  2022 pub
drwx------ 3 root root 60 May  6  2022 systemd-private-ff4a118aad534bfe95b6b390fe984558-chronyd.service-Cy8Q8X
drwx------ 3 root root 60 May  6  2022 systemd-private-ff4a118aad534bfe95b6b390fe984558-systemd-logind.service-KrDeKX
[omm@opengauss1 tmp]$ mkdir xlog_mv_322

pg_xlog ディレクトリに戻り、移行を実行します。

[omm@opengauss1 pg_xlog]$ ls -ltr | head -n 100 | awk '{print "mv "$9 " /tmp/xlog_mv_322/"}' | sh

データベースを再起動してください。スタンバイ データベースが完全に放棄されたため、メイン データベース モデルで再起動するように指定し、-M プライマリ パラメーターを追加することしかできません。

[omm@opengauss1 pg_xlog]$ gs_ctl  start -D /opt/huawei/install/data/dn/ -M primary

メイン ライブラリが正常に起動しました。ログインして、論理レプリケーション スロットを表示します。

[omm@opengauss1 pg_xlog]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 3.0.0 build 02c14696) compiled at 2022-04-01 18:12:19 commit 0 last mr  )
NOTICE : The password has been expired, please change the password.
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
openGauss=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn | dummy_standby
-----------+--------+-----------+--------+----------+--------+------+--------------+-------------+---------------
dn_6002   |        | physical  |      0 |          | f      |      |              | 1/4C6B8F70  | f
(1 row)

失敗した論理レプリケーション スロットを削除する

openGauss=# select * from pg_drop_replication_slot('dn_6002');
WARNING:  replicationSlotMinLSN is InvalidXLogRecPtr!!!
WARNING:  replicationSlotMaxLSN is InvalidXLogRecPtr!!!
pg_drop_replication_slot
--------------------------
(1 row)
openGauss=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn | dummy_standby
-----------+--------+-----------+--------+----------+--------+------+--------------+-------------+---------------
(0 rows)

関連パラメータを表示

openGauss=# show wal_keep_segments;
wal_keep_segments
-------------------
16
(1 row)
openGauss=# show max_size_for_xlog_prune;
max_size_for_xlog_prune
-------------------------
2147483647kB
(1 row)
openGauss=# show enable_xlog_prune;
enable_xlog_prune
-------------------
on
(1 row)
openGauss=# show archive_mode;
archive_mode
--------------
off
(1 row)
openGauss=# \q

総合的に見ると、max_size_for_xlog_prune パラメータの問題は、スタンバイ マシンの切断があり、xlog ログのサイズがこのしきい値よりも大きい場合、ログがリサイクルされることを意味します。ただ、デフォルト値は2048Gと大きすぎますが、私の環境は40Gしかなく、ディスクがバーストしています。

解決

問題がわかっている場合、解決策は max_size_for_xlog_prune を 4G に変更し、DB が冗長ログを自動的にクリーンアップするようにすることです。

[omm@opengauss1 pg_xlog]$ gs_guc reload -D /opt/huawei/install/data/dn/ -c "max_size_for_xlog_prune=4194304"

スペースが解放されたことを確認します。

問題は解決され、メイン ライブラリは再び動作し続けることができます。

要約する

アーカイブまたはストリーミング レプリケーションで例外が発生すると、トランザクション ログが継続的に生成されます. デフォルト値を変更しないと、ディスクが爆発し、DB がハングして再起動できなくなる可能性があります. pg_xlog がいっぱいになったら、最初にいくつかの pg_xlog ログを他の場所にバックアップし、以前のログを削除し、一定量のディスク容量が利用可能になった後にデータベースの起動を試み、次に適切なパラメーター値を設定し、最後に問題を修正します。

{{o.name}}

{{m.name}}