【Pgpool-Ⅱ】第６回 計画的切り離し(スイッチオーバー)
~これは、雑魚技術者の勉強記録～
今回は、前回の障害向きなアクションに対し、
計画作業を想定したアクションを実施してみたいと思います。
シリーズ
<第6回の概要>
6-1．切り離しと復帰
計画作業を想定し、手動切り離しと復帰を行います。
6-1．切り離しと復帰
この続きはcodocで購読
おわりに
概要から導入、クライアント設定・基盤設定および運用操作、
と6回にわたりPgpool-IIを見てまいりました。
当企画自体が製品の学習自体を目的としている部分もありますが、
PostgreSQLを取り巻く構成のベストプラクティスに到達し兼ねている点は
引き続き意識したいところです。
結局、使えないのであれば、学習投資する意味が無いではないか、という方向性も無視したくはありません。
実際に世の中で多く採用されている代表的構成ではあり、流行を追って形から入るのも良いかと思います。
両方の観点を捨てたくない想いがあります。
冒頭第１回に記載しましたが、PostgreSQL第5回~第11回の流れをくみ、
PostgreSQLのネイティブレプリケーションの実運用における課題を挙げ、
Pgpool-IIで対処可能としました。
当6回で挙げた課題について、物理的には克服できたはずです。
対して、物理以外の点や新たな課題が発生していると思っており、下記のように挙げます。
・運用性
Pgpool-IIを導入したことで運用パターンが増えてしまった、複雑化したとも言えるでしょう。
全ての障害パターンを明らかにしたわけではありませんが、運用パターンの網羅だけでも骨が折れそうです。
これの克服への対価が、レプリケーション構成のメリットで以てコスパに見合えば問題ありませんが如何でしょうか。
負荷分散の概念を除き単に冗長化の観点では、HA構成も皆無ではない気がしますし、
性能問題でいえば分散処理としてシャーディング構成もあります。
構成検討のベストプラクティス決定は、まだまだ難しい状況にあるように思います。
・Pgpool-II自身の障害対策
あなた自身はどうなのよ・・・ 単一障害点をすり替えているだけなんじゃ・・・
はい、Pgpool-IIやPPサーバーも冗長化する必要があります。
ここで、第1回の機能一覧で網掛けにしていた「Watchdog」機能の活用が有効です。
Pgpool-II同士の死活監視を行うなどができます。
Pgpool-IIを冗長化しますと、また構成が複雑になりますので、
一旦はPgpool-II単独構成のみ紹介といたしました。
次回以降、Watchdog機能を追求し、PostgreSQL＋Pgpool-IIといいますか、
PostgreSQLネイティブレプリケーション構成に関する追求を完了したいと思います。
はやく、バックアップやパフォーマンスチューニングなど別な題材も扱いたいです。
