レプリケーション開始コマンドを発行する前に、プロバイダーのpg_hba.conf
によってレプリケーション接続が承認されているかどうかをテストしたいのですが、方法がわかりません。 (私は両方のノードでunixシェルとpostgresqlシェルの両方にアクセスできます)
非レプリケーション接続の場合、'Host=$MASTER_IP port=5432 dbname=$DATABASE user=$DBUSER password=$DBPASSWORD'
のようなconnstringを使用してpsql
を接続します
Context:サーバー間のレプリケーションのセットアップを自動化するスクリプトを書いており、サーバーの構成はさまざまなシステム/リポジトリ(レガシーの理由)を通じて管理されています。したがって、各ステップで設定が適切かどうかをテストしたいと思います。
これには _pg_hba_file_rules
_ という非常に便利なビューがあります。
_table pg_hba_file_rules ;
line_number │ type │ database │ user_name │ address │ netmask │ auth_method │ options │ error
─────────────┼───────────┼───────────────┼─────────────┼───────────┼─────────────────────────────────────────┼─────────────┼─────────┼───────
3 │ local │ {all} │ {all} │ │ │ trust │ │
4 │ hostssl │ {all} │ {+users} │ 127.0.0.1 │ 255.255.255.255 │ pam │ │
5 │ Host │ {all} │ {all} │ 127.0.0.1 │ 255.255.255.255 │ md5 │ │
6 │ hostssl │ {all} │ {+users} │ ::1 │ ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff │ pam │ │
7 │ Host │ {all} │ {all} │ ::1 │ ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff │ md5 │ │
8 │ hostssl │ {replication} │ {standby} │ all │ │ md5 │ │
9 │ hostnossl │ {all} │ {all} │ all │ │ reject │ │
_
以前のバージョンの場合、少し面倒でエラーが発生しやすくなります(また、スーパーユーザーでのみ機能します。注を参照してください)。
現在想像できる_pg_hba.conf
_を読み取る唯一の組み込みの方法は、pg_read_file()
を使用することです。
_SELECT pg_read_file('pg_hba.conf');
_
ファイル全体が1行で返され、改行文字が含まれます(OSの好みに応じて、改行文字が含まれます)。
_[...]
# TYPE DATABASE USER ADDRESS METHOD↵
↵
# "local" is for Unix domain socket connections only ↵
local all all md5 ↵
# IPv4 local connections: ↵
Host all all 127.0.0.1/32 md5 ↵
[...]
_
これをさらに好みに応じて処理できます。
注:
documentation は次のことを伝えます。
表9-86に示す関数[pg_read_file()included-me]は、サーバーをホストしているマシン上のファイルへのネイティブアクセスを提供します。データベースクラスターディレクトリおよびlog_directory内のファイルのみにアクセスできます。クラスターディレクトリ内のファイルには相対パスを使用し、ログファイルにはlog_directory構成設定と一致するパスを使用します。これらの関数の使用はスーパーユーザーに制限されています。
レプリケーションを設定しているので、スーパーユーザーについての問題は問題になりません。 _pg_hba.conf
_が上記のディレクトリにない場合は、シンボリックリンクを追加してシステムをだますことができます。
_postgres@Z22309: cd /var/lib/postgresql/9.5/main
postgres@Z22309:~/9.5/main$ ln -s /etc/postgresql/9.5/main/pg_hba.conf pg_hba.conf
_
pg_conf_load_time()
とpg_stat_file()
の結果を比較する必要があります。同時に、最後のリロード以降に行われた変更が正確にわかりません。また、コメントで述べたように、ファイルのロードが成功しなかった場合でもpg_conf_load_time()
は進行し、混乱を招きます。少なくとも、再ロードが成功したかどうかはわかりません。_SELECT pg_conf_load_time() > modification FROM pg_stat_file('pg_hba.conf');
_