PostgreSQLでの高可用性の管理–パートII：Replication Manager

PostgreSQLをクラウドにデプロイしていて、高可用性を実現するためのオプションを理解したいですか？以前のブログ投稿「PostgreSQLでの高可用性の管理-パートI」では、ClusterLabsによるPostgreSQL自動フェイルオーバー（PAF）の機能について説明しました。パートIIでは、代替のオープンソースツールである2ndQuadrantのReplication Managerを紹介し、続いてパートIIIで3番目の代替ツールであるPatronibyZalandoについて説明します。

PostgreSQLでの高可用性の管理–パートI：PostgreSQLの自動フェイルオーバー
PostgreSQLでの高可用性の管理–パートIII：Patroni

レプリケーションマネージャー（repmgr）

repmgrは、PostgreSQLクラスターのレプリケーションとフェイルオーバーを管理するために2ndQuadrantによって開発されたオープンソースのツールスイートです。 PostgreSQLのレプリケーションをセットアップ、構成、管理、監視するためのツールを提供し、repmgrユーティリティを使用して手動のスイッチオーバーおよびフェイルオーバータスクを実行することもできます。この無料のツールは、PostgreSQLの組み込みストリーミングレプリケーションをサポートおよび強化します。

Replication Managerは、PostgreSQLのレプリケーションとフェイルオーバーを管理するための2つの主要なツールを提供します。

repmgr

さまざまな管理タスクを実行できるコマンドラインインターフェースユーティリティ。
repmgrを使用すると、スタンバイサーバーのセットアップ、スタンバイのプロモート、スイッチオーバーの実行、PostgreSQLクラスターのステータスの監視を行うことができます。
また、ほとんどすべての管理コマンドにドライランオプションを提供します。

repmgrd

これは次のデーモンです：

PostgreSQLクラスターをアクティブに監視し、クラスターの状態に基づいて必要なアクションを実行します。
最も適格なスタンバイを新しいプライマリとして昇格させることにより、プライマリノードがダウンした場合に自動フェイルオーバーを実行します。
レプリケーションのパフォーマンスに関連するデータを監視および保存するオプションを提供します。
登録されたイベントのユーザースクリプトを呼び出して通知を提供します。

仕組み

repmrgは、PostgreSQLクラスターのレプリケーションを管理するだけでなく、レプリケーション用にスタンバイサーバーを設定する機能も備えています。初期インストールに続いて、各サーバーで必要な詳細を含むrepmgr構成ファイル（repmgr.conf）に変更を加える必要があります。サーバーを構成する場合は、repmgr primary/standbyregisterコマンドを使用してサーバーをrepmgrに登録する必要があります。まず、プライマリノードがセットアップされて登録されます。次に、別のPostgreSQLサーバーからPostgreSQLスタンバイノードのクローンを作成するrepmgrstandbycloneコマンドを使用してスタンバイサーバーを作成および構成します。

Replication Managerは、PostgreSQL拡張機能を利用して、クラスターデータベース上に独自のスキーマを作成し、クラスター関連の情報を格納します。拡張機能のインストールとスキーマの作成は、repmgrを使用したプライマリサーバーの登録中に行われます。セットアップが完了すると、repmgrユーティリティを使用して、プロモート、フォロー、スイッチオーバーなどの手動管理操作を実行できます。スイッチオーバー操作の場合、ノード間にパスワードなしのSSHを設定する必要があります。

自動フェイルオーバーは、repmgrdを使用して設定できます。 repmgrdでは、PostgreSQLサーバーの起動時に共有ライブラリ「repmgr」をロードする必要があります。ライブラリ名は、 shared_preload_librariesに記載する必要があります postgresql.confファイルの構成パラメーター。また、repmgrdが機能するには、フェイルオーバー=自動 パラメータはrepmgr.confファイルで設定する必要があります。これらすべてのパラメーターが設定されると、repmgrdデーモンはクラスターのアクティブな監視を開始します。プライマリノードに障害が発生した場合、プライマリノードは複数回再接続を試みます。プライマリへの接続のすべての試行が失敗すると、repmgrdによる新しいプライマリとして、最も適格なスタンバイが選択によって選択されます。

repmgrはイベント通知もサポートしています。事前定義されたイベントのセットがあり、これらのイベントの各発生をrepmgr.eventsテーブルに格納します。 repmgrを使用すると、イベント通知をユーザー定義のプログラムまたはスクリプトに渡すことができます。このプログラムまたはスクリプトは、電子メールの送信やアラートのトリガーなど、さらにアクションを実行できます。これは、 event_notification_commandを設定することによって行われます。 repmgr.confのパラメータ。

スプリットブレインシナリオをどのように処理しますか？

repmgrは、場所を使用してスプリットブレインシナリオに取り組みますパラメータ。各ノードは、配置されているデータセンターに基づいてロケーションパラメータを指定する必要があります。ネットワークが分割された場合、repmgrは、プライマリと同じ場所にあるノードの昇格を保証します。その場所にノードが見つからない場合、どの場所にもノードは昇格しません。

また、クラスター内のサーバーの数が偶数の場合のネットワーク分離も処理します。これは、監視サーバーと呼ばれる追加のノードを使用して行われます。証人サーバーは、多数決でのみ考慮されるノードです。そのサーバーにはPostgreSQLがインストールされないため、レプリケーションで機能する役割はありません。

セットアップ要件はありますか？

repmgrには、専用のデータベースとスーパーユーザー権限を持つユーザーが必要です。ただし、スーパーユーザーにrepmgrユーザーへのアクセスを許可したくない場合は、スーパーユーザーを提供するオプションもあります。
repmgrでPostgreSQLデータディレクトリの外部にある構成ファイルをコピーしたり、スイッチオーバー機能をテストしたりする場合は、両方のサーバー間でパスワードなしのSSH接続も必要になります。 rsyncをインストールする必要があります。
pg_ctl（デフォルトでrepmgrによって使用される）以外のサービスベースのコマンドを使用して開始、停止、リロード、および再起動する場合は、repmgrでそれらを指定できます。構成ファイル（repmgr.conf）。

repmgr構成ファイルに必要な基本構成パラメーターは次のとおりです。

node_id（int） –ノードを識別するゼロより大きい一意の整数。 node_name（文字列） –混乱を避けるために、サーバーのホスト名またはサーバーに明確に関連付けられた別の識別子を使用した、任意の（ただし一意の）文字列をお勧めします。

conninfo（文字列） –conninfo文字列としてのデータベース接続情報。クラスタ内のすべてのサーバーは、この文字列を使用してローカルノードに接続できる必要があります。

data_directory（文字列） –ノードのデータディレクトリ。これは、PostgreSQLインスタンスが実行されておらず、データディレクトリを決定する他の方法がない場合に、repmgrが操作を実行するために必要です。

repmgrの長所

Repmgrは、プライマリノードとスタンバイノードのセットアップとレプリケーションの構成に役立つユーティリティを提供します。
通信に追加のポートを使用しません。スイッチオーバーを実行する場合にのみ、パスワードなしのSSHを構成する必要があります。
登録されたイベントのユーザースクリプトを呼び出して通知を提供します。
プライマリサーバーに障害が発生した場合に自動フェイルオーバーを実行します。

repmgrの短所

repmgrは、リカバリ構成でスタンバイが不明または存在しないノードで誤って構成されているかどうかを検出しません。プライマリ/カスケードスタンバイノードに接続せずに実行されている場合でも、ノードはスタンバイとして表示されます。
PostgreSQLサービスがダウンしているノードから別のノードのステータスを取得できません。したがって、分散制御ソリューションは提供されません。
個々のノードの正常性の回復は処理しません。

#PostgreSQLでの高可用性の管理–パートII：オープンソースのrepmgrツールクリックしてツイート

高可用性テストシナリオ

repmgrを使用して、PostgreSQLの高可用性管理についていくつかのテストを実施しました。これらのテストはすべて、アプリケーションの実行中にPostgreSQLデータベースにデータを挿入しながら実行されました。このアプリケーションは、接続フェイルオーバー機能を活用したPostgreSQL JavaJDBCDriverを使用して作成されました。

スタンバイサーバーテスト

Sl。いいえ	テストシナリオ	観察
1	PostgreSQLプロセスを強制終了します	スタンバイサーバーは失敗としてマークされました。ライターアプリケーションに混乱はありませんでした。 PostgreSQLプロセスを再開するには、手動による介入が必要でした。
2	PostgreSQLプロセスを停止します	スタンバイサーバーは失敗としてマークされました。ライターアプリケーションに混乱はありませんでした。 PostgreSQLプロセスを再開するには、手動による介入が必要でした。
3	サーバーを再起動します	スタンバイサーバーは失敗としてマークされました。再起動後にサーバーが起動すると、PostgreSQLが手動で起動され、サーバーは実行中としてマークされました。ライターアプリケーションに混乱はありませんでした。
4	repmgrdプロセスを停止します	スタンバイサーバーは、自動フェイルオーバー状況の一部にはなりません。 PostgreSQLサービスが実行されていることがわかりました。ライターアプリケーションに混乱はありませんでした。

マスター/プライマリサーバーのテスト

Sl。いいえ	テストシナリオ	観察
1	PostgreSQLプロセスを強制終了します	repmgrdは、すべてのスタンバイサーバーでプライマリサーバー接続のヘルスチェックを一定の間隔で開始しました。すべての再試行が失敗すると、すべてのスタンバイサーバーで選択がトリガーされました。選挙の結果、最新のLSNを受け取ったスタンバイが昇格しました。選出に失敗したスタンバイサーバーは、新しいマスターノードからの通知を待ち、通知を受信するとそれに従います。ライターアプリケーションでダウンタイムが発生しました。 PostgreSQLプロセスを再開するには、手動による介入が必要でした。
2	PostgreSQLプロセスを停止し、ヘルスチェックの有効期限が切れたらすぐに元に戻します	repmgrdは、すべてのスタンバイサーバーでプライマリサーバー接続のヘルスチェックを一定の間隔で開始しました。すべての再試行が失敗すると、すべてのスタンバイノードで選択がトリガーされました。ただし、古いマスターが戻ってきたため、新しく選出されたマスターは既存のスタンバイサーバーに通知しませんでした。クラスターは不確定な状態のままであり、手動による介入が必要でした。
3	サーバーを再起動します	すべてのスタンバイサーバーでマスター接続のヘルスチェックが失敗したときに、repmgrdが選出を開始しました。適格なスタンバイが昇格しました。このサーバーが戻ってきたとき、クラスターに参加せず、失敗とマークされました。 repmgr node rejoinコマンドを実行して、サーバーをクラスターに追加し直しました。ライターアプリケーションでダウンタイムが発生しました。
4	repmgrプロセスを停止します	プライマリサーバーは、自動フェイルオーバー状況の一部にはなりません。 PostgreSQLサービスが実行されていることがわかりました。ライターアプリケーションに混乱はありませんでした。

ネットワーク分離テスト

Sl。いいえ	テストシナリオ	観察
1	ネットワークはプライマリサーバーを他のサーバーから分離します（repmgr構成の場所はすべて同じ値です）	すべてのスタンバイサーバーでマスター接続のヘルスチェックが失敗したときに、repmgrdが選出を開始しました。適格なスタンバイが昇格しましたが、PostgreSQLプロセスはまだ古いマスターノードで実行されていました。マスターとして実行されている2つのノードがありました。ネットワークの分離が修正された後、手動による介入が必要でした。
2	ネットワークはプライマリサーバーを他のサーバーから分離します（スタンバイサーバーの場所の値は同じですが、repmgr構成ではプライマリの場所の値が異なります）	すべてのスタンバイサーバーでマスター接続のヘルスチェックが失敗したときに、repmgrdが選出を開始しました。ただし、スタンバイサーバーの場所がプライマリサーバーとは異なるため、新しいマスターは選出されませんでした。 repmgrdは劣化監視モードになりました。 PostgreSQLはすべてのノードで実行されており、クラスターにはマスターが1つしかありませんでした。

推論

repmgrは、PostgreSQLレプリケーションを設定および監視するためのいくつかのコマンドを提供します。機能が豊富で、データベース管理者（DBA）の作業も容易になります。ただし、リソースを管理しないため、本格的な高可用性管理ツールではありません。リソースが適切な状態にあることを確認するには、手動による介入が必要です。

この投稿では、2ndQuadrantによるReplicationManagerの機能と動作について説明しました。次の投稿では、ZalandoのPatroniを使用した同じ高可用性の側面について説明します。クラウドでの高可用性の自動化を検討しているユーザーは、PostgreSQLonAzureとPostgreSQLonAWSの完全に管理されたソリューションを確認してください。