以前のブログ投稿では、Cluster LabsによるPostgreSQL自動フェイルオーバー（PAF）と2ndQuadrantによるReplication Manager（repmgr）の機能について説明しました。このシリーズの最後の投稿では、最後のソリューションであるZalandoのPatroniを確認し、最後に3つすべてを比較して、PostgreSQLホスティングの展開に最適な高可用性フレームワークを決定します。
- PostgreSQLでの高可用性の管理–パートI：PostgreSQLの自動フェイルオーバー
- PostgreSQLでの高可用性の管理–パートII：Replication Manager
PostgreSQLのパトロニ
Patroniは、ComposeのプロジェクトであるGovernorのフォークとして生まれました。これは、PostgreSQLクラスターの高可用性を管理するためのPythonで記述されたオープンソースのツールスイートです。 Patroniは、独自の整合性プロトコルを構築する代わりに、Distributed Configuration Store（DCS）によって提供される整合性モデルをスマートに活用します。また、Zookeeperなどの他のDCSソリューション、Consul、Kubernetesもサポートしています。
Patroniは、ストリーミングレプリケーションを含むPostgreSQLHAクラスターのエンドツーエンドのセットアップを保証します。スタンバイノードを作成するためのさまざまな方法をサポートし、ニーズに合わせてカスタマイズできるテンプレートのように機能します。
この機能豊富なツールは、REST APIを介して、またpatronictlと呼ばれるコマンドラインユーティリティを介してその機能を公開します。ヘルスチェックAPIを使用して負荷分散を処理することにより、HAProxyとの統合をサポートします。
Patroniは、特定のアクションによってトリガーされるスクリプトであるコールバックの助けを借りて、イベント通知もサポートしています。一時停止/再開機能を提供することにより、ユーザーは任意のメンテナンスアクションを実行できます。ウォッチドッグサポート機能により、フレームワークがさらに堅牢になります。
仕組み
最初に、PostgreSQLとPatroniのバイナリをインストールする必要があります。これが完了したら、HADCS構成もセットアップする必要があります。クラスターをブートストラップするために必要なすべての構成をyaml構成ファイルで指定する必要があり、Patroniはこのファイルを初期化に使用します。最初のノードで、Patroniはデータベースを初期化し、DCSからリーダーロックを取得し、ノードがマスターとして実行されていることを確認します。
次のステップは、Patroniが複数のオプションを提供するスタンバイノードを追加することです。デフォルトでは、Patroniはpg_basebackupを使用してスタンバイノードを作成し、スタンバイノードの作成にWAL-E、pgBackRest、Barmanなどのカスタムメソッドもサポートします。 Patroniを使用すると、スタンバイノードを非常に簡単に追加でき、すべてのブートストラップタスクとストリーミングレプリケーションの設定を処理できます。
#PostgreSQLでの高可用性の管理–パートIII：Patroni vs. PAF vs. repmgrClick To Tweetクラスターのセットアップが完了すると、Patroniはクラスターをアクティブに監視し、正常な状態にあることを確認します。マスターノードは、ttl秒ごとにリーダーロックを更新します（デフォルト：30秒）。マスターノードがリーダーロックの更新に失敗すると、Patroniが選出をトリガーし、リーダーロックを取得するノードが新しいマスターとして選出されます。
スプリットブレインシナリオをどのように処理しますか？
分散システムでは、コンセンサスが一貫性を決定する上で重要な役割を果たし、PatroniはDCSを使用してコンセンサスを達成します。リーダーロックを保持しているノードのみがマスターになることができ、リーダーロックはDCSを介して取得されます。マスターノードがリーダーロックを保持していない場合、Patroniによってすぐに降格され、スタンバイとして実行されます。このように、どの時点でも、システムで実行できるマスターは1つだけです。
セットアップ要件はありますか？
- PatroniにはPython2.7以降が必要です。
- DCSとその特定のPythonモジュールをインストールする必要があります。テストの目的で、DCSはPostgreSQLを実行している同じノードにインストールできます。ただし、本番環境では、DCSを別々のノードにインストールする必要があります。
- yaml構成ファイルは、次の高レベルの構成設定を使用して存在する必要があります：
グローバル/ユニバーサル
これには、クラスターで一意である必要があるホストの名前（name）、クラスターの名前（scope）、DCS（名前空間）に構成を格納するためのパスなどの構成が含まれます。ログ
レベル、フォーマット、file_num、file_sizeなどを含むパトロニ固有のログ設定ブートストラップ構成
これは、DCSに書き込まれるクラスターのグローバル構成です。これらの構成パラメーターは、Patroni APIを使用するか、DCSで直接変更できます。ブートストラップ構成には、スタンバイ作成メソッド、initdbパラメーター、初期化後スクリプトなどが含まれます。また、タイムアウト構成、レプリケーションスロットなどのPostgreSQL機能の使用を決定するパラメーターも含まれます。 、同期モードなど。このセクションは、新しいクラスターの初期化後に、特定の構成ストアの// /configに書き込まれます。 PostgreSQL
このセクションには、認証、データのディレクトリパス、バイナリと構成、IPアドレスのリッスンなどのPostgreSQL固有のパラメータが含まれています。REST API
このセクションには、リッスンアドレス、認証、SSLなどのRESTAPIに関連するPatroni固有の構成が含まれています。領事
DCS領事に固有の設定。Etcd
EtcdDCSに固有の設定。出展者
出展者DCSに固有の設定。Kubernetes
KubernetesDCSに固有の設定。ZooKeeper
ZooKeeperDCSに固有の設定。ウォッチドッグ
ウォッチドッグに固有の設定。
パトロニの長所
- Patroniは、クラスターのエンドツーエンドのセットアップを可能にします。
- RESTAPIとHAproxy統合をサポートします。
- 特定のアクションによってトリガーされるコールバックスクリプトを介したイベント通知をサポートします。
- コンセンサスのためにDCSを活用します。
パトロニの短所
- Patroniは、リカバリ構成に不明なノードまたは存在しないノードがあるスタンバイの構成ミスを検出しません。マスター/カスケードスタンバイノードに接続せずにスタンバイが実行されている場合でも、ノードはスレーブとして表示されます。
- ユーザーは、DCSソフトウェアのセットアップ、管理、およびアップグレードを処理する必要があります。
- コンポーネント通信用に複数のポートを開く必要があります：
- PatroniのRESTAPIポート
- DCS用に最低2つのポート
高可用性テストシナリオ
Patroniを使用してPostgreSQLHA管理についていくつかのテストを実施しました。これらのテストはすべて、アプリケーションの実行中にPostgreSQLデータベースにデータを挿入するときに実行されました。このアプリケーションは、接続フェイルオーバー機能を活用したPostgreSQL JavaJDBCDriverを使用して作成されました。
スタンバイサーバーテスト
| Sl。いいえ | テストシナリオ | 観察 |
|---|---|---|
| 1 | PostgreSQLプロセスを強制終了します | PatroniはPostgreSQLプロセスを実行状態に戻しました。
|
| 2 | PostgreSQLプロセスを停止します | PatroniはPostgreSQLプロセスを実行状態に戻しました。
|
| 3 | サーバーを再起動します | 再起動時に起動しないように構成されていない限り、Patroniは再起動後に起動する必要があります。 Patroniが起動すると、PostgreSQLプロセスが開始され、スタンバイ構成がセットアップされました。
|
| 4 | パトロニプロセスを停止します |
したがって、基本的に、Patroniプロセスの状態を監視する必要があります。そうしないと、問題が発生する可能性があります。 |
マスター/プライマリサーバーのテスト
| Sl。いいえ | テストシナリオ | 観察 |
| 1 | PostgreSQLプロセスを強制終了します | Patroniは、PostgreSQLプロセスを実行状態に戻しました。そのノードで実行されているパトロニはプライマリロックを持っていたため、選挙はトリガーされませんでした。
|
| 2 | PostgreSQLプロセスを停止し、ヘルスチェックの有効期限が切れたらすぐに元に戻します | Patroniは、PostgreSQLプロセスを実行状態に戻しました。そのノードで実行されているパトロニはプライマリロックを持っていたため、選挙はトリガーされませんでした。
|
| 3 | サーバーを再起動します | フェイルオーバーが発生し、ロックを取得した後、スタンバイサーバーの1つが新しいマスターとして選出されました。 Patroniが古いマスターで開始されたとき、古いマスターを元に戻し、pg_rewindを実行し、新しいマスターの追跡を開始しました。T
|
| 4 | パトロニプロセスを停止/強制終了 |
上記のように、マスターのPatroniプロセスの状態を監視することは非常に重要です。そうしないと、マルチマスターシナリオが発生し、データが失われる可能性があります。 |
ネットワーク分離テスト
| Sl。いいえ | テストシナリオ | 観察 |
| 1 | ネットワーク-マスターサーバーを他のサーバーから分離します | マスターノードのDCS通信がブロックされました。
|
| 2 | ネットワーク-スタンバイサーバーを他のサーバーから分離します | スタンバイノードのDCS通信がブロックされました。
|
最高のPostgreSQL HAフレームワークは何ですか？
Patroniは、PostgreSQLクラスターのエンドツーエンドのセットアップと監視を実行するため、PostgreSQLデータベース管理者（DBA）にとって貴重なツールです。 DCSとスタンバイの作成を柔軟に選択できることは、エンドユーザーが使いやすい方法を選択できるため、エンドユーザーにとって有利です。
REST API、HaProxy統合、ウォッチドッグサポート、コールバック、およびその機能豊富な管理により、PatroniはPostgreSQLHA管理に最適なソリューションになります。
PostgreSQL HAフレームワークテスト：PAF vs. repmgr vs. Patroni
以下に含まれているのは、PostgreSQL自動フェイルオーバー（PAF）、レプリケーションマネージャー（repmgr）、およびPatroniの3つのフレームワークすべてで実行したすべてのテストの結果の詳細を示す包括的な表です。
スタンバイサーバーテスト
| テストシナリオ | PostgreSQL自動フェイルオーバー（PAF） | レプリケーションマネージャー（repmgr） | Patroni |
|---|---|---|---|
| PostgreSQLプロセスを強制終了します | PacemakerはPostgreSQLプロセスを実行状態に戻しました。
| スタンバイサーバーは失敗としてマークされました。 PostgreSQLプロセスを再開するには、手動による介入が必要でした。
| PatroniはPostgreSQLプロセスを実行状態に戻しました。
|
| PostgreSQLプロセスを停止します | PacemakerはPostgreSQLプロセスを実行状態に戻しました。
| スタンバイサーバーは失敗としてマークされました。 PostgreSQLプロセスを再開するには、手動による介入が必要でした。
| PatroniはPostgreSQLプロセスを実行状態に戻しました。
|
| サーバーを再起動します | スタンバイサーバーは最初にオフラインとしてマークされていました。再起動後にサーバーが起動すると、PacemakerによってPostgreSQLが起動され、サーバーはオンラインとしてマークされました。フェンシングが有効になっている場合、ノードはクラスターに自動的に追加されませんでした。
| スタンバイサーバーは失敗としてマークされました。再起動後にサーバーが起動すると、PostgreSQLが手動で起動され、サーバーに実行中のマークが付けられました。
| 再起動時に起動しないように構成されていない限り、Patroniは再起動後に起動する必要があります。 Patroniが起動すると、PostgreSQLプロセスが開始され、スタンバイ構成がセットアップされました。
|
| フレームワークエージェントプロセスを停止します | エージェント：ペースメーカー
| エージェント：repmgrd
| エージェント：patroni
|
マスター/プライマリサーバーのテスト
| テストシナリオ | PostgreSQL自動フェイルオーバー（PAF） | レプリケーションマネージャー（repmgr） | Patroni |
|---|---|---|---|
| PostgreSQLプロセスを強制終了します | ペースメーカーはPostgreSQLプロセスを実行状態に戻しました。プライマリはしきい値時間内に回復したため、選挙はトリガーされませんでした。
| repmgrdは、すべてのスタンバイサーバーでプライマリサーバー接続のヘルスチェックを一定の間隔で開始しました。すべての再試行が失敗すると、すべてのスタンバイサーバーで選択がトリガーされました。選挙の結果、LSNを最後に受信したスタンバイが昇格しました。選出に失敗したスタンバイサーバーは、新しいマスターノードからの通知を待ち、通知を受信するとそれに従います。postgreSQLプロセスを再開するには、手動による介入が必要でした。
| Patroniは、PostgreSQLプロセスを実行状態に戻しました。そのノードで実行されているパトロニはプライマリロックを持っていたため、選挙はトリガーされませんでした。
|
| PostgreSQLプロセスを停止し、ヘルスチェックの有効期限が切れたらすぐに元に戻します | ペースメーカーはPostgreSQLプロセスを実行状態に戻しました。プライマリはしきい値時間内に回復したため、選挙はトリガーされませんでした。
| repmgrdは、すべてのスタンバイサーバーでプライマリサーバー接続のヘルスチェックを一定の間隔で開始しました。すべての再試行が失敗すると、すべてのスタンバイノードで選択がトリガーされました。ただし、古いマスターが戻ったため、新しく選出されたマスターは既存のスタンバイサーバーに通知しませんでした。クラスターは不確定な状態のままであり、手動による介入が必要でした。
| Patroniは、PostgreSQLプロセスを実行状態に戻しました。そのノードで実行されているパトロニはプライマリロックを持っていたため、選挙はトリガーされませんでした。
|
| サーバーを再起動します | マスターが利用できなかったしきい値時間の後に、Pacemakerによって選挙がトリガーされました。最も適格なスタンバイサーバーが新しいマスターとして昇格されました。再起動後に古いマスターが起動すると、スタンバイとしてクラスターに追加されました。フェンシングが有効になっている場合、ノードはクラスターに自動的に追加されませんでした。
| すべてのスタンバイサーバーでマスター接続のヘルスチェックが失敗したときに、repmgrdが選択を開始しました。適格なスタンバイが昇格されました。このサーバーが戻ってきたとき、クラスターに参加せず、失敗とマークされました。 repmgr node rejoinコマンドを実行して、サーバーをクラスターに戻しました。
| フェイルオーバーが発生し、ロックを取得した後、スタンバイサーバーの1つが新しいマスターとして選出されました。 Patroniが古いマスターで開始されたとき、古いマスターを元に戻し、pg_rewindを実行し、新しいマスターの追跡を開始しました。
|
| フレームワークエージェントプロセスを停止します | エージェント：ペースメーカー
| エージェント：repmgrd
| エージェント：patroni
|
ネットワーク分離テスト
| テストシナリオ | PostgreSQL自動フェイルオーバー（PAF） | レプリケーションマネージャー（repmgr） | Patroni |
|---|---|---|---|
| ネットワークはマスターサーバーを他のサーバーから分離します（スプリットブレインシナリオ） | マスターサーバーでCorosyncトラフィックがブロックされました。
| すべてのサーバーの locationの値は同じです。 repmgr構成の場合：
スタンバイサーバーの場所の値は同じです ただし、プライマリの locationの値は異なります。 repmgr構成の場合：
| マスターノードのDCS通信がブロックされました。
|
| ネットワーク-スタンバイサーバーを他のサーバーから分離します | Corosyncトラフィックがスタンバイサーバーでブロックされました。
|
| スタンバイノードのDCS通信がブロックされました。
|
