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

PostgreSQLホスティングでの高可用性（HA）の管理は、データベースデプロイメントクラスターが並外れた稼働時間と強力な運用パフォーマンスを維持し、データをアプリケーションで常に利用できるようにするための非常に重要なトピックです。以前のブログ投稿で、ストリーミングレプリケーションを使用してPostgreSQLの高可用性を構成する方法を紹介しました。次に、クライアント側の高可用性を最適に管理する方法を紹介します。

ストリーミングレプリケーションを使用してPostgreSQLデプロイメントクラスターの高可用性（HA）を管理するために利用できるツールは複数あります。これらのソリューションは、自動フェイルオーバー機能を提供し、可用性とシステムステータス、レプリケーション、ユーザー管理、およびPostgresデータベースのユースケースに関するその他の有用な管理タスクを監視します。著名なオープンソースソリューションには、次のものがあります。

1. ClusterLabsによるPostgreSQL自動フェイルオーバー

2. repmgr（2ndQuadrant）によるPostgreSQLクラスターのレプリケーションマネージャー

3. ザランドのパトロニ

各ツールは、高可用性PostgreSQLクラスターを管理する独自の方法を提供します。 HA for PostgreSQLに関する3部構成の一連の投稿では、これら3つのツールのそれぞれの概要、前提条件、および動作とテストの結果を共有します。ここパート1では、ClusterLabsによるPAFソリューションについて詳しく説明します。

• PostgreSQLでの高可用性の管理–パートII：レプリケーションマネージャー
• PostgreSQLでの高可用性の管理–パートIII：Patroni

PostgreSQLデータベースの高可用性を管理する方法

PostgreSQL自動フェイルオーバー（PAF）は、ClusterLabsによるPostgreSQLの高可用性管理ソリューションです。 Postgres同期レプリケーションを使用して、フェイルオーバー操作時にデータが失われないことを保証します。人気のある業界標準のPacemakerおよびCorosyncスタックを利用します。 PacemakerアプリケーションとCorosyncアプリケーションを一緒に使用すると、システム内のPostgreSQLデータベースの障害を検出し、それに応じて行動することができます。

Pacemakerは、多くのリソースを管理できるサービスであり、リソースエージェントの助けを借りて管理します。リソースエージェントは、特定のリソースを処理し、それらがどのように動作するかを処理し、Pacemakerに結果を通知する責任があります。

リソースエージェントの実装は、Open Cluster Framework（OCF）仕様に準拠している必要があります。この仕様は、リソースエージェントの動作と、停止、開始、昇格、降格、Pacemakerとのやり取りなどのメソッドの実装を定義します。

PAFは、Perlで記述されたPostgres用のOCFリソースエージェントです。内部ストリーミングレプリケーションを使用してデータベースクラスターが構築されると、PAFは、データベースの各ノード（マスター、スレーブ、停止、キャッチアップ、ロードバランサーなど）のPostgreSQLインスタンスの現在のステータスをPacemakerに公開できます。

Postgres自動フェイルオーバーの仕組み

PAFは、クラスターのステータスに関してPacemakerと通信し、PostgreSQLデータベースの機能を監視します。障害が発生した場合はPacemakerに通知し、現在のマスターが回復する可能性がない場合は、現在のスタンバイデータベースサーバーの1つ間で選択がトリガーされます。堅牢なPacemakerを導入すると、Postgres自動フェイルオーバーは、すべてのPostgresデータベースのノードで開始、停止、監視、フェイルオーバーなどの管理アクションを実行します。

PostgreSQLでの高可用性の管理-パートI：ClusterLabsによる自動フェイルオーバークリックしてツイート

高可用性（HA）構成のためのPostgreSQL自動フェイルオーバー

• PAFはPostgreSQLバージョン9.3以降をサポートしています。
• PAFは、PostgreSQLマスター/スタンバイの作成またはそのセットアップについては責任を負いません。PAFを使用する前に、ストリーミングレプリケーションを作成してセットアップする必要があります。
• PAFは、PostgreSQLの構成またはセットアップ要件を編集しません。ただし、データベースユーザーは次のようないくつかの前提条件に従う必要があります。
  • スレーブはホットスタンバイとして構成する必要があります。ホットスタンバイスレーブノードは、読み取り専用データベースとしてクエリできます。
  • リカバリテンプレートファイル（デフォルト： /recovery.conf.pcmk）には、以下のパラメータを指定する必要があります：
    • スタンバイモード =オン
    • restorey_target_timeline =「最新」
    • primary_conninfo application_nameパラメータを定義し、Pacemakerのようにローカルノード名に設定する必要があります。
• PAFは、Postgresリソースの管理に関連する複数のパラメーターを公開します。これは、要件に合わせて構成できます。パラメータは次のとおりです。
  • bindir： PostgreSQLバイナリの場所（デフォルト：/ usr / bin）
  • pgdata： インスタンスのPGDATAの場所（デフォルト：/ var / lib / pgsql / data）
  • datadir： postgresql.confファイルからdata_directoryに設定されたディレクトリへのパス
  • pghost： ローカルインスタンスへの接続に使用するソケットディレクトリまたはIPアドレス（デフォルト：/ tmp）
  • pgport： ローカルインスタンスに接続するポート（デフォルト：5432）
  • どのrecovery_template： PGD​​ATA/recovery.confファイルとしてコピーされるローカルテンプレート。このテンプレートファイルはすべてのノードに存在する必要があります（デフォルト：$ PGDATA / restorey.conf.pcmk）
  • start_opts： 起動時にPostgresプロセスに与えられる追加の引数。利用可能なオプションについては、「postgres –help」を参照してください。 postgresql.confファイルがデータディレクトリ（PGDATA）にない場合に便利です。例：-c config_file =/ etc / postgresql / 9.3 / main / postgresql.conf
  • system_user： インスタンスのプロセスのシステム所有者（デフォルト：postgres）
  • maxlag： スタンバイに負のマスタースコアを設定する前に、スタンバイで許可される最大ラグ

Postgres自動フェイルオーバーの長所

• PAFは、PostgreSQLの無料のハンズオン構成とセットアップをユーザーに提供します。
• PAFは、ノードの障害を処理し、マスターがダウンしたときに選択をトリガーできます。
• 定足数の動作はPAFで適用できます。
• リソースの完全な高可用性（HA）データベース管理ソリューションを提供します。これには、ネットワーク分離シナリオの開始、停止、監視、処理が含まれます。
• これは分散ソリューションであり、別のノードから任意のノードを管理できます。

Postgres自動フェイルオーバーの短所

• PAFは、スタンバイノードがリカバリ構成で不明または存在しないノードで誤って構成されているかどうかを検出しません。マスター/カスケードスタンバイノードに接続せずにスタンバイが実行されている場合でも、ノードはスレーブとして表示されます。
• UDPを使用したPacemakerおよびCorosyncコンポーネントの通信用に、追加のポート（デフォルトは5405）を開く必要があります。
• NATベースの構成はサポートしていません。
• pg_rewindはサポートされていません。

PostgreSQLテストシナリオの高可用性

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

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

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

ネットワーク分離テスト

その他のテスト

PAFはPostgreSQLの高可用性のソリューションですか？

Postgres自動フェイルオーバーは、多くのユースケースでPostgreSQLの高可用性（HA）を処理する上でいくつかの利点を提供します。 PAFは、フェールオーバーイベント中にスタンバイをリブートして新しいマスターに接続する代わりに、IPアドレスフェールオーバーを使用します。これは、ユーザーがスタンバイノードを再起動したくないシナリオで有利であることがわかります。また、PAFは手動による介入をほとんど必要とせず、すべてのPostgresデータベースリソースの全体的な状態を管理します。手動による介入が必要な唯一のケースは、ユーザーがpg_rewindの使用を選択できるタイムラインデータの相違の場合です。

パート1では、ClusterLabsによるPostgreSQL自動フェイルオーバー（PAF）の機能と動作について説明し、パート2では説明します。 2ndQuadrantによるReplicationManagerfor PostgreSQLクラスター（repmgr）を使用した同じ高可用性の側面。必ずパート3を確認してください。ここでは、ZalandoによるPatroniについても説明し、3つのオープンソースソリューションすべてを比較して、アプリケーションに最適なものを決定するのに役立てます。

パート1のブログでは、ClusterLabsによるPAFの機能、ベストプラクティス、および動作について説明しました。パート2のブログ投稿では、 2ndQuadrantによるPostgresqlクラスター用レプリケーションマネージャー（repmgr）を使用して、高可用性の側面に関する同じトピックについて説明します。パート3のブログ投稿を確認してください。ここでは、ZalandoによるPatroniについても取り上げ、3つのオープンソースソリューションすべてを比較して、ビジネスアプリケーションに最適なベストプラクティスを決定するのに役立てます。