Tihiroの頭を休めるIT教室

少しだけ頭使って後は根性

第1回PGECons勉強会の振り返り。

概要

PostgreSQL エンタープライズ・コンソーシアム : 2017年11月17日 第1回PGECons勉強会 に参加してきましたので、その振り返りです。が、時間が経つと結構うろ覚えになっていました。細かいところは結構違うかもなのでご注意くださいませ。

ツイッターのまとめはこちら。

togetter.com

会場の様子

アシストさんのセミナールームでの実施でした。セミナールームはパーティションで20-30人収納できるぐらいのスペースに区切れるようで、今回の勉強会ではパーティション3つ分のスペースを利用していました。つまりは60-90人ぐらい収納可能? プロジェクタとスクリーンが前面に3組あって、真ん中のスクリーンで主催のお姉さんが解説されていました。部屋の隅っこでもスクリーンが遠くて見れないってことはないので安心です。

若干、空席がちらほら目立ちましたが、その分ゆったりと座れましたので有難いです。事前の情報では満席御礼的な感じでしたので、余計に。

勉強会、ということで雰囲気は軽く、販促的なものもなく気軽に参加できる雰囲気でした。随時、ツイッターの様子を確認しているようで、ツイッターに呟くことで主催が反応してくれます。つまり、大勢の場で質問とかできない恥ずかしがり屋さんでも、こっそり呟くことで質問とかできちゃうわけであります。

勉強会の内容

主な内容は、ストリーミングレプリケーションのデモを交えながらの解説でした。 だいたいはマニュアル通りな内容でしたので、OSSDBの試験対策としても役に立ちそう、という感じです。

ストリーミングレプリケーションは同期とか非同期とか遅延とかカスケードとか物理とか論理とか、分け分からん状態になりやすいので、改めて整理できたのは良かったです。以下より内容の振り返り。

ストリーミングレプリケーションについて

ストリーミングレプリケーションは物理レプリケーション(対する、論理レプリケーションはPostgreSQL10より実装)

マスタ側のpostgresql.confの設定

  • synchronous_commit
    • 同期レベルの設定
    • 同期レベルを高くすると当然、クライアントへの応答時間は遅くなる。
    • 同期レプリケーション時にスレーブが落ちるとマスタへの更新ができなくなる(スレーブへの更新完了を待ち続ける)。
  • synchronous_standby_names
  • wal_level
    • logicalとかreplicaとかminimal以外であれば大丈夫だったような。
  • max_wal_senders
    • マスタ + スレーブの数を設定する。
    • PostgreSQL10ではデフォルト値が10となっている(バージョンが10だから?)
  • max_replication_slots

マスタ側のpg_hba.confの設定

レプリケーション用の設定を追加。

スレーブ側のpostgresql.confの設定

  • hot_standby
    • スレーブ側で参照を許可するかどうか。
    • offな利点って?
  • hot_standby_feedback
    • WALがスレーブに適用されるまで、マスタ側で保持し続ける仕組み。
    • スレーブに障害が発生しているとか、WALをスレーブに適用できない状態が長く続くと、WALも保持され続ける。

スレーブ側のrecovery.conf

  • standby_mode
    • 自分がスレーブであるという設定
  • primary_conninfo
    • マスタ側の設定
  • recovery_target_timeline
    • 基本はlatestでおk

ストリーミングレプリケーションの状態監視

  • pg_stat_replicationビューで監視する
  • pg_is_in_recovery()を実行した時の戻り値でマスタかスレーブかを確認する
    • t:ならスレーブ
    • f:ならマスタ
  • スレーブに適用されたWALの確認
    • WAL番号を見るんでしたっけ?
    • とりあえず人間の目で見るのは無理っぽい。
    • WALがどこまで適用されているか、っていうのを気にするシチュエーションは?

ストリーミングレプリケーションの復旧

スレーブ側の障害

スレーブの切り離し→pg_basebackup復旧でおK

マスタ側の復旧

スレーブをマスタに昇格(pg_ctl promote)→新マスタ(旧スレーブ)にスレーブを作成(pg_basebackupとrecovery.confの作成)でおK

スプリットブレインについて

スプリットブレイン=複数のマスタが起動してしまうこと。クラスタ化システムの悩みのタネ。

マスタが生きている状態でスレーブの昇格(pg_ctl promote)などを行うと発生? スプリットブレインの紹介はあったけど、具体的にどのような手順で発生するのか等の説明はなかった。

pg_rewindによる復旧

pg_basebackupは時間がかかるので => pg_rewindっていうのもあるヨ!!

でも、正常停止が必要だったりするヨ!! ということで詳しくは勉強会の資料を参照。

遅延レプリケーションについて

この辺りから説明が駆け足になってきた感が。

recovery_min_apply_delayに設定した値分、スレーブ側へのWALの適用を遅延できる。 用途としてはバックアップ的な使い方?

【マスタサーバー→スレーブサーバー1】を同期レプリケーションにしておいて、【スレーブサーバー1→スレーブサーバー2】を遅延レプリケーション(プラスのカスケードレプリケーション)にしておけば良い感じ、とか思ったり。

ロジカルレプリケーションについて

前述の通り、PostgreSQL10で新実装! ということで検証中みたい。今後のお題とされるやも?

ロジカルレプリケーションの詳細は

qiita.com

が良いです。

質疑応答

なんやかんやで質疑応答が一番盛り上がっていた感。運用よりっていうよりは開発よりな質問が多かった印象。 詳しくはツイッターまとめの最後の方を参照ください。

Quorum Commit

雰囲気で。

ロジカルデコーディングについて

これ知らんかったわー。ってことで、この存在を知れたのが一番の収穫かも。

その他

docker-composeが便利そうでした。

まとめ

今回が初参加でしたが、今後もこういう勉強会には参加していきたいものです。