wal_keep_segmentsはリンク先のマニュアルに書いてある通り、
ストリーミングレプリケーションにおいて、スタンバイサーバが過去のファイルセグメントを取得する必要がある場合に備え、pg_walディレクトリに保持しておくファイルセグメント数の最小値を指定します。
です。デフォルトは0です。0だからpg_walディレクトリの配下に何も生成されないかというとそうではなく、最低min_wal_sizeの設定だけpg_walファイルが生成されます。
例えば以下のようなになります。
[root@erogamescape14 pg_wal]# ls -lh 合計 97M -rw------- 1 postgres postgres 386 5月 30 23:22 2019 0000000A.history -rw------- 1 postgres postgres 431 6月 26 09:06 2019 0000000B.history -rw------- 1 postgres postgres 16M 6月 26 10:00 2019 0000000B00000013000000D7 -rw------- 1 postgres postgres 16M 6月 26 10:02 2019 0000000B00000013000000D8 -rw------- 1 postgres postgres 16M 6月 26 09:06 2019 0000000B00000013000000D9 -rw------- 1 postgres postgres 16M 6月 26 09:07 2019 0000000B00000013000000DA -rw------- 1 postgres postgres 16M 6月 26 09:30 2019 0000000B00000013000000DB -rw------- 1 postgres postgres 16M 6月 26 09:30 2019 0000000B00000013000000DC drwx------ 2 postgres postgres 4.0K 6月 26 09:07 2019 archive_status
ErogameScapeではストリーミングレプリケーションを使用しており、PostgreSQLのマイナーバージョンアップの際にはレプリケーションスロットを使用するのでwal_keep_segmentsは0にしていました。
ところが手順を間違えて、primaryのPostgreSQLにレプリケーションスロットを作る前に、standbyのPostgreSQLを止めてしまい、yum updateしている際に6つのWALファイルが全部新しくなってしまった結果、standbyを組み込もうとした際に「もうWALファイルがありません」的なメッセージがでてしまって、組み込めませんでした…
泣く泣く、pg_basebackupからスタートしました。
ErogameScapeでそんなに更新があるのか?と思うかもしれませんが(私もそう思っていました)、統計用のテーブルは全部のデータをDELETEして、INSERTするので、その統計用のテーブルを作り直す際にWALがたくさん生成されます。
以上から、手順を間違えることも考慮してwal_keep_segmentsを適当に設定しておくことにしました。
HDDは余裕があるので、えいやで50(walファイルは1つ16MBなので、50個で800MB)にしました。
実際、どの程度必要なのか…については、実運用環境で試せるなら、pg_walディレクトリのWALファイルの生成時刻を見ればいいのかな…と思います。
[root@erogamescape14 pg_wal]# ls -lh 合計 257M -rw------- 1 postgres postgres 386 5月 30 23:22 2019 0000000A.history -rw------- 1 postgres postgres 431 6月 26 09:06 2019 0000000B.history -rw------- 1 postgres postgres 16M 6月 26 10:00 2019 0000000B00000013000000D7 -rw------- 1 postgres postgres 16M 6月 26 10:06 2019 0000000B00000013000000D8 -rw------- 1 postgres postgres 16M 6月 26 11:07 2019 0000000B00000013000000D9 -rw------- 1 postgres postgres 16M 6月 26 12:10 2019 0000000B00000013000000DA -rw------- 1 postgres postgres 16M 6月 26 12:30 2019 0000000B00000013000000DB -rw------- 1 postgres postgres 16M 6月 26 12:49 2019 0000000B00000013000000DC -rw------- 1 postgres postgres 16M 6月 26 14:07 2019 0000000B00000013000000DD -rw------- 1 postgres postgres 16M 6月 26 15:30 2019 0000000B00000013000000DE -rw------- 1 postgres postgres 16M 6月 26 15:30 2019 0000000B00000013000000DF -rw------- 1 postgres postgres 16M 6月 26 16:17 2019 0000000B00000013000000E0 -rw------- 1 postgres postgres 16M 6月 26 17:30 2019 0000000B00000013000000E1 -rw------- 1 postgres postgres 16M 6月 26 18:30 2019 0000000B00000013000000E2 -rw------- 1 postgres postgres 16M 6月 26 18:30 2019 0000000B00000013000000E3 -rw------- 1 postgres postgres 16M 6月 26 18:55 2019 0000000B00000013000000E4 -rw------- 1 postgres postgres 16M 6月 26 19:26 2019 0000000B00000013000000E5 -rw------- 1 postgres postgres 16M 6月 26 19:41 2019 0000000B00000013000000E6 drwx------ 2 postgres postgres 4.0K 6月 26 09:07 2019 archive_status
見ると、10時に0000000B00000013000000D7が生成されて、19時41分の時点で0000000B00000013000000Eです。16個あれば9時間持つので、standbyを9時間止めててもwal_keep_segmentsは16だったら、まあ…pg_basebackupなしに組み込めるかなあと想定できます。
