MENU

【Pgpool-Ⅱ】第1回 Pgpool-II概要

~これは、雑魚技術者の勉強記録~

f:id:g071067:20210323185357j:plain

 本稿ではPgpool-IIを取り扱ってまいります。
Pgpool-IIの学習自体を目的化しており、理解を助ける内容になると思います。

 別途、Pgpool-IIを取り扱う背景としまして、PostgreSQLの第5回~第11回で
レプリケーション構成を取り扱った流れを汲みます。
そこでは、DBが冗長化されたものの、逆にいえばどのように負荷分散するのかや、
レプリケーション構成ならではの役割(マスタ/スレーブ)を考慮した使用が必要
との見解に至りました。
 人間が手動でDBと対話する分には意識的に接続しますが、業務システムとなると
自動で判断するような仕組みが必要と想定されます。
これを担うことができるのがPgpool-IIで、今後の題材としたい旨を謳い
終了した経緯があります。
 →DB構成もそのまま第5回~で構築した同期レプリケーション構成を使用します。

 はたしてうまくいくかどうか。再び新たな課題や気づきにぶつかるかもしれません。
 過程のなかで、いつもどおりですが解説を織り込んでまいります。
決して、PostgreSQL構成のベストプラクティスと謳うものではありません。
一緒に体感し、考えてまいりましょう。

 第1回として、Pgpool-IIとは何? をざっくりと認識を持ちたいと思います。
まずは座学です。

シリーズ

tecsak.hatenablog.com

<第1回の概要>

1-1.概要
 Pgpool-IIのイメージをつかみます。

1-2.機能
 Pgpool-IIの機能を理解します。

1-3.動作モード
 動作モードについて紹介いたします。


1-1.概要

この続きはcodocで購読

1-2.機能

この続きはcodocで購読

1-3.動作モード

この続きはcodocで購読

おわりに

次回より、導入を進めます。

【PostgreSQL】第11回 レプリケーション構成での障害の考察

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 今回は、レプリケーション構成における障害について考えてみたいと思います。

 前回までに登場したオペレーションで障害対応も可能なのですが、
フォーカスポイントとしては構築や計画作業でした。

 ここでは、想定し得る障害と必要なオペレーションの紐づけを行い整理したいと思います。
そして、現実的なDBの使われ方を再現し、障害が発生していくシナリオを実現します。

シリーズ

tecsak.hatenablog.com

<第11回の概要>

11-1.レプリケーション構成における想定障害と必要アクション
 想定される障害、状況および対応事項を整理します。

11-2.実践!非同期モードにおける同期ズレ
 非同期モードにて発生し得る、同期ズレを再現してみました。

11-3.実践!同期モードにおける同期破綻
 同期破綻を再現してみました。


11-1.レプリケーション構成における想定障害と必要アクション

この続きはcodocで購読

11-2.実践!非同期モードにおける同期ズレ

この続きはcodocで購読

11-3.実践!同期モードにおける同期破綻

この続きはcodocで購読

おわりに

いくつか想定される障害はあるものの、必要なアクションや手順に共通部分は多く
これの組み合わせで対応できます。
手順を確立し、障害対応計画へと結びつけて頂けたらと思います。

レプリケーション機能(PostgreSQL本体機能による)については、本稿を以て終了したいと思います。


今後の活動として、以下機能の学習/追求が必要と捉えており、実施したいと思います。
・バックアップ機能の学習
・pgpool-Ⅱの学習

【PostgreSQL】第10回 同期モード切り替え

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 今回は、同期モードを変化させてみたいと思います。

 同期モードは確実な伝播を実現しますが、その反面で何らかの不具合で
スレーブとの同期が図れない場合にDDLや更新SQLに対する返却がなされない様子が
前回の検証でも観察されました。

 これはある意味サービス影響を意味しており、それなら冗長性よりもサービス継続優先で
とりあえず応答するようにしてくれよ、という局面にもなってまいります。

 そこで、同期を解除してマスタ単体で継続させるまでを体験したいと思います。
 復習ですが、(F/Oもそうでしたが)局面をPostgreSQL本体にて独自で判断し、
自動でアクションを起こす機能は存在しません、ということでした。

シリーズ

tecsak.hatenablog.com

<第10回の概要>

10-1.同期モード終了の背景について
 復習になりますが、同期モードについて再認識します。

10-2.同期モード終了手順を考えてみる
 モード切替のコマンド等を紹介いたします。

10-3.実践!同期モード終了
 前回のような事象の再現も取り入れながら、同期モード終了にて解決していく様子を
 シナリオ立てて体験してみましょう


10-1.F/Oとは

この続きはcodocで購読

10-2.F/O手順

この続きはcodocで購読

10-3.実践!F/O

この続きはcodocで購読

おわりに

一旦、設定の証明のような形で動作を確認することができました。 設定するだけ、という見方をすれば簡単なオペレーションかもしれません。

ただ、これまでの検証では、実務と比較すると都合のよい条件ばかりでした。

例えば、同期を解除して再度そのまま同期可能とは限りません。先ほどの検証では、1レコード差からの再同期でしたが、容赦なく挿入/更新処理が行われるシステムでしたら間に合いますでしょうか。

また、挿入処理も一時的に待ち状態となりましたが、いつまで待たせんだよ(怒)・・・と処理期限の無いシステムは存在するのでしょうか。

次回、現実を考慮した使い方/使われ方を検証したいと思います。

【PostgreSQL】第9回 フェイルオーバーについて

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 今回は、フェイルオーバー(F/O)を体験したいと思います。 マスタノードのメンテナンスなどを目的として新たなマスタ役が必要となる際に必要となります。

シリーズ

tecsak.hatenablog.com

<第9回の概要>

9-1.F/Oとは
 PostgreSQLレプリケーション構成におけるフェイルオーバー(F/O)について学んでみます。

9-2.F/O手順
 F/Oのコマンドや確認方法について説明します。

9-3.実践!F/O
 F/Oを行ってみましょう。

9-1.F/Oとは

この続きはcodocで購読

9-2.F/O手順

この続きはcodocで購読

9-3.実践!F/O

この続きはcodocで購読

おわりに

 DBミドルウェアの限りでは、確かにマスタが引継ぎされていました。

 最後は危険な一面も見え、特に同期モードにて応答が無い事象は、考察すべき事項が多い認識です。

ここで、逆にスレーブ側が不調となり、マスタが引き続きマスタとして単独稼働すべき時に、同期モードは更新処理を中心にサービス継続への足かせとなるでしょう。

次回は、同期モードの非同期化について検証したいと思います。

【PostgreSQL】第8回 pg_basebackupを用いたレプリケーション構築

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 今回は、pg_basebackupを用いたレプリケーション構築を行いたいと思います。 PostgreSQLがインストール済であれば、簡単な操作でスレーブノードにデータベースクラスタを構成しレプリケーションもできます。

シリーズ

tecsak.hatenablog.com

<第8回の概要>

8-1.pg_basebackupとは
 pg_basebackupについて学んでみます。

8-2.pg_basebackupの仕様を踏まえたレプリケーション構築手順
 pg_basebackupの仕様を踏まえ、レプリケーション構築に対する手順を考えてみます。

8-3.実践!pg_basebackupによるレプリケーション構築
 考慮手順を踏まえ、実際に行ってみます。

8-1.pg_basebackupとは

この続きはcodocで購読

8-2.pg_basebackupの仕様を踏まえたレプリケーション構築手順

この続きはcodocで購読

8-3.実践!pg_basebackupによるレプリケーション構築

この続きはcodocで購読

おわりに

如何でしたでしょうか? ほぼ1コマンドな感じではないでしょうか。 必要に応じて、スレーブ側の(コピーされてきたマスタの)WALファイルを削除してもかまいません。

レプリケーション実績のあるマスタからのpg_basebackupのため、ユーザー作成やpg_hba.confの工程が不要でした。ノード追加の際には、pg_hba.confに行追加など適宜アレンジ頂きたいです。

別な観点では、スレーブ環境のDB破損に対する復旧手順とも言えます。 マスタ側の破損含め、追って整理したいと思います。

対障害の前に、計画・能動的な作業について整理させてください。例えば、定期メンテナンスに伴い意図的に実施するフェイルオーバーなどが該当し、次回より実践してまいります。

【PostgreSQL】第7回 レプリケーション機能の基本的な検証をしてみよう

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 前回、レプリケーション構成の構築が完了しました。今回は、伝播される様子を観察したいと思います。 単純に、テーブルを作成したりデータを挿入してみて、両ノード (特にスレーブ側) から参照できれば成功です。  小細工はありません。別途考慮すべき点については、障害等の扱いにして別稿で取り上げます。

シリーズ

tecsak.hatenablog.com

<第7回の概要>

7-1.実践:簡単なレプリケーションの検証(参照と更新)
 テーブル作成・データ挿入を行い両ノードからの参照可能を確認します。
 また、スレーブ側は更新不可能な様子も見てみます。

7-2.実践:いじわる~unlogged機能を用いたオブジェクトの作成
 検証が単純ですので、少し捻ってみました。
 アーカイブモード必須、ログシッピングにて実現されている当機能に対し、ログ出力しない形で
 テーブル作成を 行うとどうなるか、検証してみました。

7-1.実践:簡単なレプリケーションの検証(参照と更新)

この続きはcodocで購読

7-2.実践:いじわる~unlogged機能を用いたオブジェクトの作成

この続きはcodocで購読

おわりに

単純な検証作業でしたが、裏ではきっとカシコイ動きをしてくれているのでしょう。 これで、レプリケーション機能の基本的な検証は終了したいと思います。

次回なのですが、 これまで、ノード単位での複製にてレプリケーションを構築しました。PostgreSQLの機能として、データベースクラスタ単位で複製を行う「pg_basebackup」という方法があり、これを検証したいと思います。 ノード障害にてOS単位で破損してしまった、などの場合はノード単位での復旧が必要となりますが、ミドルウェア範囲内で発生した問題の解決や新規スレーブノード追加の場合も、ノード・OSから・・・というのは非効率で、対処機能が用意されております。むしろ、こちらの機能を用いてレプリケーションの構築を行うほうが主流です。

本稿はこれまでとさせていただきます。

【PostgreSQL】第6回 レプリケーション構成の構築

~これは、雑魚技術者の勉強記録~

f:id:g071067:20200613191805p:plain

 今回は、前回の理屈を踏まえレプリケーション構成を構築したいと思います。 既に単独で動作可能なDBが合計2ノード存在する状態ですが、これらが同期連動するよう設定を施してまいります。

シリーズ

tecsak.hatenablog.com

<第6回の概要>

6-1.作業概要
 レプリケーション構成の構築に必要な作業を紹介します。
 単独で動作可能なDBが合計2ノード存在する状態を前提としています。

6-2.レプリケーション用ユーザー作成
 レプリケーションにおける権限属性等を紹介します。

6-3.レプリケーション用設定
 レプリケーションに必要な設定について紹介します。

6-4.実践:ユーザーおよび設定の環境反映
 さあ、構築してみましょう。

6-1.作業概要

この続きはcodocで購読

6-2.レプリケーション用ユーザー作成

この続きはcodocで購読

6-3.レプリケーション用設定

この続きはcodocで購読

6-4.実践:ユーザーおよび設定の環境反映

この続きはcodocで購読

おわりに

 ざっと構築と、設定出力レベルでの確認を行いました。 色々と書きなぐってしまったかもしれませんが、要はユーザーの作成と設定ファイルの編集だけ、と捉えれば単純です。 設定内容も、設計さえ決まれば、決まり文句を打ち込むだけだなあという感覚をお持ち頂けたのではないでしょうか。

 さあ、それでは実際に情報が伝播される様子を観察してみましょう。 本稿はここまでとし、観察は次回に回します。