2019年06月

wal_keep_segments

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なしに組み込めるかなあと想定できます。

Git関連書籍

ErogameScapeは2001年に作りましたが、2019年6月までGitを使ったことがありませんでした。
※1人で作っているので…なんとかなってました。大きな修正をする場合は、.bakという拡張子にしてファイルを保存してから開始していましたが、軽微な変更の場合はえいやで書き換えていました。

GitとGitを使うためのGUIの1つであるSourceTreeを学んで滅茶苦茶便利だ!と思いました。
以下の2つの書籍を手を動かしながら読みました。
GitとSourceTreeは道具なので、手を動かしながらやらないといまいち理解が深まらないことと、Gitを使うような何かを作っていないと、すぐに忘れちゃう…と思います。

独習Git
リック・ウマリ
翔泳社
2016-02-26

最初に図書館から借りてやりはじめたのですが、2週間では終わらず…、何回か借りるも終わらず、買ってきて一通り終えることが出来ました。
Gitをコマンドラインを使って操作します。
SourceTreeの話は最後の方に少しだけ出来ますが、ほんの少しだけなのでSourceTreeの使い方はこの本では分かりません。
こなすのに相当時間がかかって途中で心が折れそうになりますが、おそらく…必要最低限のGitの操作を学ぶことができます。
各章に課題があるのですが回答はないので、『独習Git』課題の解答およびヒント - Qiitaを参照させて頂きました。ありがたいです。
自分は、この本だけではGitを使う気になれませんでした…
次に買ったわかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉 [単行本(ソフトカバー)]でSourceTreeのことを知ってGitを使う気になりました。
自分はGUIじゃないときついと思いました。



2019年6月11日時点でレビューが45個5つ星のうち4.6で、AmazonのGit関連書籍のとしては堂々の1位です。
独習Gitを一通り読んだ後に、こちらを読んだらGitを具体的にどのように使ったらいいかがすごくよく分かりました。
●CHAPTER 1 Gitって何?
●CHAPTER 2 個人でGitを使ってみよう
●CHAPTER 3 複数人でGitを使ってみよう
●CHAPTER 4 実用Git 〜 こんなときはどうすればいい?
●CHAPTER 5 Gitで広がる世界
という章構成です。CHAPTER 3まではすんなり頭に入ってきたし、違和感もなかったですが、CHAPTER 4から「おやっ?」と思うことがある…説明が足りていないことがある…ので、その場合は独習Gitで同じことをしている章を読み直して、SourceTreeのこの操作は、Gitでコマンドをうつとこうなるんだなと、理解していきました。
この本だけでは足りないですが、1冊目としてはいいかなと思います。
例えばgit resetのことは載っていないです。
「git reset SourceTree」で検索すると著者のページ(SourceTreeのリセットボタンは、git reset全般を指しているわけじゃない | マンガでわかるWebデザイン)がひっかかりますので、ここを読んでなるほどなあと思いましたが、なるほどなあ…と思えるのは、独習Gitを先にこなしていたからなので…2冊目が必要だと思います。
2冊目として独習Gitだと…心が折れる方が続出しそうな気がしますが…他の本を読んでいないので何がかいいか分からないです。


failover_on_backend_error


failover_on_backend_errorをoffにすると、pgpoolがフェイルオーバーの処理をしてくれなくなるので、別の仕組みでフェイルオーバーの仕組みを実装する必要があります。

health_check_max_retreisを有効にするのは、ネットワークが不安定になることがあるので、health_checkのリトライをしたい場合であって、pgpoolのフェイルオーバーは依然として必要だと思いますので、onのままにすることが多いのでは無いかと思います。
※「health_check_max_retreisを有効にする場合は、failover_on_backend_errorを無効にするのが望ましい」理由が分かりませんでした…

あまり考えずにfailover_on_backend_errorをoffに設定したら、以下の事象が発生しサービスが中断しました。
以下pgpoolのログです。
May 31 23:10:44 erogamescape13 pgpool[12780]: [313206-1] 2019-05-31 23:10:44: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:10:44 erogamescape13 pgpool[12780]: [313206-2] 2019-05-31 23:10:44: pid 12780: DETAIL:  timed out. retrying...
May 31 23:10:54 erogamescape13 pgpool[12780]: [313207-1] 2019-05-31 23:10:54: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:10:54 erogamescape13 pgpool[12780]: [313207-2] 2019-05-31 23:10:54: pid 12780: DETAIL:  timed out. retrying...
May 31 23:11:04 erogamescape13 pgpool[12780]: [313208-1] 2019-05-31 23:11:04: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:11:04 erogamescape13 pgpool[12780]: [313208-2] 2019-05-31 23:11:04: pid 12780: DETAIL:  timed out. retrying...
May 31 23:11:14 erogamescape13 pgpool[12780]: [313209-1] 2019-05-31 23:11:14: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:11:14 erogamescape13 pgpool[12780]: [313209-2] 2019-05-31 23:11:14: pid 12780: DETAIL:  timed out. retrying...
May 31 23:11:24 erogamescape13 pgpool[12780]: [313210-1] 2019-05-31 23:11:24: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:11:24 erogamescape13 pgpool[12780]: [313210-2] 2019-05-31 23:11:24: pid 12780: DETAIL:  timed out. retrying...
May 31 23:11:34 erogamescape13 pgpool[12780]: [313211-1] 2019-05-31 23:11:34: pid 12780: LOG:  trying connecting to PostgreSQL server on "192.168.0.14:5432" by INET socket
May 31 23:11:34 erogamescape13 pgpool[12780]: [313211-2] 2019-05-31 23:11:34: pid 12780: DETAIL:  timed out. retrying...
May 31 23:11:37 erogamescape13 pgpool[12780]: [313212-1] 2019-05-31 23:11:37: pid 12780: LOG:  failed to connect to PostgreSQL server on "192.168.0.14:5432", getsockopt() detected error "Connection timed out"
May 31 23:11:37 erogamescape13 pgpool[12780]: [313213-1] 2019-05-31 23:11:37: pid 12780: LOG:  failed to create a backend 0 connection
May 31 23:11:37 erogamescape13 pgpool[12780]: [313213-2] 2019-05-31 23:11:37: pid 12780: DETAIL:  skip this backend because because failover_on_backend_error is off and we are in streaming replication mode and node is standby node
May 31 23:11:37 erogamescape13 pgpool[12780]: [313214-1] 2019-05-31 23:11:37: pid 12780: LOG:  master node 0 is down. Update master node to 1
May 31 23:11:37 erogamescape13 pgpool[12780]: [313215-1] 2019-05-31 23:11:37: pid 12780: LOG:  failback event detected
May 31 23:11:37 erogamescape13 pgpool[12780]: [313215-2] 2019-05-31 23:11:37: pid 12780: DETAIL:  restarting myself
May 31 23:11:38 erogamescape13 pgpool[13944]: [313288-1] 2019-05-31 23:11:38: pid 13944: ERROR:  unable to read message kind
May 31 23:11:38 erogamescape13 pgpool[13944]: [313288-2] 2019-05-31 23:11:38: pid 13944: DETAIL:  kind does not match between master(0) slot[0] (52)
health_check_max_retreisを3に設定していたのに、どうしてconnectingが6回timeoutしているのか分からないのですが、6回timeoutして、failed to create a backend 0 connectionと判定しています。
※ちなみにbackend0のPostgreSQLはprimaryでした。

ここで、backend 0を切り離して、事前に用意したフェイルオーバーのためのスクリプトをpgpoolが起動して、backend 1を昇格させる必要があるのですが、failover_on_backend_errorがoffなので、pgpoolは何もせず(skip this backend because because failover_on_backend_error is off)、でもpgpoolとしては、backend 1がprimaryだと判断して動き始めます(Update master node to 1)。

しかし、実際はbackend 1はstandbyのままなので、kind does not match between master(0) slot[0]となってPostgreSQLに接続出来ず、サービスが中断しました。

記事検索