はじめに

こんにちは、PostgreSQLで主に高可用構成を担当している内田です。

PostgreSQL では、GUC(Grand Unified Configuration)パラメータ（以下、サーバーパラメータ）を用いて、使用メモリ量の設定や、接続数の上限設定などを行います。

サーバーパラメータは、postgresql.conf ファイルに記載することで設定されますが、
もうひとつ、postgresql.auto.conf というファイルも存在しています。

今回は、この postgresql.auto.conf が引き起こした問題について見ていきたいと思います。

「そのサーバーパラメータ、もしかして postgresql.auto.conf で上書きされてない？」

postgresql.auto.confとは

postgresql.auto.confは、 PostgreSQL文書 に 以下のように説明されています。

　postgresql.confに加え、PostgreSQLのデータディレクトリには postgresql.auto.confというファイルがあります。
　このファイルは postgresql.conf と同じフォーマットですが、手動ではなく自動で編集されることを意図しています。
　このファイルはALTER SYSTEMコマンドを使った設定値を保存します。


　このファイルはpostgresql.conf が読み込まれるときはいつでも自動的に読み込まれ、同じように設定が反映されます。
　postgresql.auto.confは、postgresql.confの設定を上書きします。


　外部ツールもpostgresql.auto.confを変更するかも知れません。
　ALTER SYSTEMが変更を上書きする可能性があるので、allow_alter_systemがoffに設定されていない限り、
　サーバが稼働中は外部ツールによる変更は推奨されません。
　そのようなツールは、単に新しい設定を最後に追加するか、重複した設定あるいはコメント(ALTER SYSTEMが行います)を
　削除することを選択するかも知れません。

要は、ALTER SYSTEMコマンドで設定したサーバーパラメータの情報が、postgresql.auto.conf に書き込まれるということです。

ここで、注意が必要な点は、以下の2点です。

1. （１）postgresql.auto.conf は、自動で編集されることを意図しているため、手動で編集してはいけない
   
2. （２）postgresql.auto.conf は、postgresql.confの設定よりも優先される (postgresql.confの設定を上書きする)
   

■ （１）については、postgresql.auto.conf は、postgresql.conf と同様にテキストファイルのため、 手動での編集も可能ではあるのですが、 その後で ALTER SYSTEM コマンドやツールなどで postgresql.auto.conf を更新するときに不具合が起こる可能性があるため、 手動での編集はお勧めできない、ということです。

※ postgresql.auto.conf のファイルの先頭にも以下のように「手動で編集してはいけない」とコメントが書かれています。

　# Do not edit this file manually!
　# It will be overwritten by the ALTER SYSTEM command.

また、DBクラスタ構築(initdb)時に作成されるファイルのため、ファイルを削除することもお勧めできません。

■ （２）は、PostgreSQL起動時や設定のリロード(pg_ctl reload)の際には、 先に postgresql.conf の設定を取り込んだ後に postgresql.auto.conf の設定が取り込まれる順番であることを意味します。

そのため、postgresql.conf を修正して PostgreSQLを再起動したにもかかわらず、 postgresql.auto.conf に同じサーバーパラメータの設定情報が記載されていたために 設定が反映されない、という事が起こりえます。

postgresql.auto.confに記述される動作と、確認方法

それでは、注意が必要な点の1点目にあげた、
「（１）postgresql.auto.conf は、自動で編集されることを意図しているため、手動で編集してはいけない」
について、具体的に見ていきましょう。

postgresql.auto.conf の内容は、以下のいずれかの操作で更新されます。

postgresql.auto.conf に書かれている内容は、以下のSQLを実行して確認できます。

　SELECT * FROM pg_file_settings WHERE sourcefile LIKE '%postgresql.auto.conf%';

また、postgresql.auto.conf はテキストファイルなので、 postgresql.conf と同様にテキストエディタ等で直接ファイルの内容を参照することも可能です。

postgresql.auto.confの内容で上書きされる例

続いて、注意が必要な点の2点目にあげた、
「（２）postgresql.auto.conf は、postgresql.confの設定よりも優先される (postgresql.confの設定を上書きする)」
の例を示します。

まず、以下の2点の設定を行い、PostgreSQLを起動します。

① いったんPostgreSQLを起動し、ALTER SYSTEMコマンドで wal_level を logical に設定する

　postgres=# ALTER SYSTEM SET wal_level = logical;

② postgresql.conf の wal_level のコメントを取り除く(明示的に wal_level を replica に設定する)
PostgreSQLを再起動し、SHOWコマンドで実際に設定されている値を確認します。

　postgres=# show wal_level;
　-[ RECORD 1 ]------
　wal_level | logical

postgresql.conf では wal_level = replica を設定していますが、ALTER SYSTEM で設定した値である logical が有効になっていることがわかりますね。

それでは次に、wal_level がどういう順番で設定が反映されたかを見ていきましょう。

　postgres=# select * from pg_file_settings where name='wal_level';
　-[ RECORD 1 ]------------------------------------------
　sourcefile | /var/lib/pgsql/17/data/postgresql.conf
　sourceline | 858
　seqno      | 26
　name       | wal_level
　setting    | replica
　applied    | f
　error      |
　-[ RECORD 2 ]------------------------------------------
　sourcefile | /var/lib/pgsql/17/data/postgresql.auto.conf
　sourceline | 3
　seqno      | 27
　name       | wal_level
　setting    | logical
　applied    | t
　error      |

※ sourcefile はフルパスで表示されます。

pg_file_settings の seqno は、 設定が処理される順序を示しており、同じサーバーパラメータが複数存在する場合、 seqno が大きいほうの設定値が有効になります。

■postgresql.auto.conf が問題となる事例

最後に、 PG-REX において、 ストリーミングレプリケーション構成の高可用化を行う場合に問題となった事例を紹介します。

※ PG-REX とは、PostgreSQL + Pacemaker で同期レプリケーションの高可用構成を提供するソリューションです。
　PG-REX については、PG-REXの概要 も併せて参照頂ければと思います。

▼事象
・pg_basebackup -R コマンドを用いてスタンバイDBを作成したところ、レプリケーション構成で起動しなかった。

　スタンバイDBを pg_basebackup コマンドを使用して作成したときに発生した事象となります。
　※PG-REXの運用補助ツールを使用してスタンバイDBを作成する場合にはこの問題は発生しません。

▼原因
・Pacemaker の pgsqlリソースエージェントが postgresql.conf に設定したストリーミングレプリケーションの設定と、
　pg_basebackup -R コマンドで postgresql.auto.conf に追加されたストリーミングレプリケーションの設定が競合し、
　優先順位の高い postgresql.auto.conf の設定が優先されてしまったため。

▼詳細
Pacemakerで、ストリーミングレプリケーションを用いた構成を構築する場合、Standby機で、pg_basebackupを用いてPrimaryからDBクラスタのコピーを行いますが、このとき

　pg_basebackup -R -h 【PrimaryのIP】 -U 【レプリケーションユーザ】-D 【出力先】 -X none -P

と、-Rオプションをつけてバックアップを取得してしまうと、取得したバックアップ先のpostgresql.auto.confにバックアップ取得元への接続の設定を追加して、standby.signalファイルも作成してくれます。

一方、Primary機側は、Pacemaker経由でPostgreSQLを起動した際に、pgsqlリソースエージェントによって、あらかじめ　postgresql.confにPrimaryへの接続の設定を追加します。
(実際にpostgresql.confに追加されるのは接続情報を記述したファイルを指定した includeサーバーパラメータです)

この状態でStandby機側のPacemakerを起動すると、PostgreSQL側で同期レプリケーションとして動作していたとしても、Pacemaker(pgsqlリソースエージェント)側が同期レプリケーションを認識できてない状態となります。
pcs statusを実行した時、Standby機のNode Attributesは、以下のように表示されますが、PacemakerやPostgreSQLのログにエラー等のメッセージが出ないため、原因の特定、事象の解決に時間がかかることが多くなると考えられます。

　* master-pgsql                      : -INFINITY
　* pgsql-data-status                 : DISCONNECT
　* pgsql-status                      : HS:alone

どこにもエラーが出ていないのに、同期レプリケーションされていないという扱いになっている場合は、postgresql.auto.confの内容を確認するというのを頭の片隅でも残しておいてもらえればと思います。

まとめ

「postgresql.auto.conf の罠」はどうでしたか？

通常は postgresql.auto.conf を意識することはなかなかないと思います。同様に、ALTER SYSTEM 文でパラメータを変更することもあまりないと思います。

今回はたまたま、PG-REX構成を作成するときに、pg_basebackup コマンドを使用してスタンバイを作成した例を挙げましたが、 pg_basebackup の「-R」オプションと PG-REX のストリーミングレプリケーション設定が競合するのは気づきにくいですよね。

そういったことも起こりうるということで、
「ストリーミングレプリケーション構成を作ったのに、なんかうまく動かない」とか、
「postgresql.conf に書いたはずのサーバーパラメータの設定が反映されない」といった場合に postgresql.auto.conf のことを思い出してみるのも必要なことだと思います。

ではでは、また次回の"たのしいぽすぐれ教室"でお会いしましょう！

PostgreSQLのことならNTTテクノクロスにおまかせください！

NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせや、移行に関する対応を受け付けています。
オンプレだけではなく、Azure、AWSなどのクラウド上でのシステムの導入、開発、維持管理のご相談もお待ちしております。

PostgreSQL の定額制チケットサービスはこちら

PostgreSQLへの移行サービスはこちら