はじめに

Patroniは、Pythonを使用した高可用HA PostgreSQLソリューションのテンプレートです。 Patroniは、Composeのプロジェクト Governor _のフォークとして誕生しました。たくさんの新機能が含まれています。

追加の背景情報については、以下を参照してください。

開発状況

Patroniは積極的に開発中であり、貢献を受け入れています。詳細については、以下の Contributing セクションを参照してください。

新しいリリース情報 here をレポートします。

技術要件/インストール

さまざまなプラットフォームでのPatroniのインストールとアップグレードに関するガイダンスについては、 here にアクセスしてください。

PostgreSQLノードの数の計画

Patroni / PostgreSQLノードはDCSノードから分離されているためPatroniが独自にRAFTを実装する場合を除き、したがって、ノードの最小数に関する要件はありません。 1つのプライマリと1つのスタンバイで構成されるクラスターを実行するのは全く問題ありません。スタンバイノードは後で追加できます。

2-node clusters プライマリ+スタンバイは一般的で、高可用性を備えた自動フェイルオーバーを提供します。フェールオーバー中、障害が発生したノードが再参加するまで、一時的に冗長性がなくなることに注意してください。

DCS requirements 適切なコンセンサスとフォールトトレランスを実現するために、DCS etcd、ZooKeeper、Consulは DCS requirements で実行する必要があります。単一のDCSクラスターは、さまざまな名前空間/スコープの組み合わせを使用して、数百または数千のPatroniクラスターの情報を保存できます。

実行と構成

次のセクションでは、Patroniリポジトリがhttps://github.com/patroni/patroniからクローン化されたものであることを前提としています。つまり、サンプル構成ファイル`postgres0.yml`および`postgres1.yml`が必要です。 pipでPatroniをインストールした場合、gitリポジトリからこれらのファイルを取得し、以下の`./patroni.py`を`patroni`コマンドに置き換えることができます。

開始するには、さまざまな端末から次のことを行います。

> etcd --data-dir=data/etcd --enable-v2=true
> ./patroni.py postgres0.yml
> ./patroni.py postgres1.yml

高可用性クラスターが起動すると表示されます。 YAMLファイルのさまざまな設定をテストして、クラスターの動作がどのように変化するかを確認します。いくつかのコンポーネントをkillして、システムがどのように動作するかを確認します。

postgres*.yml ファイルを追加して、さらに大規模なクラスターを作成します。

Patroniは、 HAProxy _構成を提供し、クラスターのリーダーに接続するための単一のエンドポイントをアプリケーションに提供します。構成するには、次を実行します。

> haproxy -f haproxy.cfg

> psql --host 127.0.0.1 --port 5000 postgres

YAML構成

etcd、consul、およびZooKeeperの設定に関する包括的な情報については、 here にアクセスしてください。例については、 here _を参照してください。

環境設定

環境変数を介した設定のオーバーライドに関する包括的な情報については、 here にアクセスしてください。

レプリケーションの選択

PatroniはPostgresのストリーミングレプリケーションを使用します。これはデフォルトで非同期です。 Patroniの非同期レプリケーション構成では、 maximum_lag_on_failover 設定が可能です。この設定により、フォロワーがリーダーの特定のバイト数を超えて後ろにある場合、フェイルオーバーが発生しないことが保証されます。この設定は、ビジネス要件に基づいて増加または減少する必要があります。同期レプリケーションを使用して、耐久性を向上させることもできます。詳細については、 maximum_lag_on_failover を参照してください。

アプリケーションはスーパーユーザーを使用しないでください

アプリケーションから接続する場合、常に非スーパーユーザーを使用します。 Patroniが正常に機能するには、データベースへのアクセスが必要です。アプリケーションからスーパーユーザーを使用することにより、スーパーユーザー用に予約された接続を含む接続プール全体を superuser_reserved_connections 設定で使用できる場合があります。接続プールがいっぱいであるためにPatroniがプライマリにアクセスできない場合、動作は望ましくありません。

HAソリューションのテスト

HAソリューションのテストは、多くの変数を含む時間のかかるプロセスです。これは、クロスプラットフォームアプリケーションを考慮すると特に当てはまります。この作業を行うには、訓練されたシステム管理者またはコンサルタントが必要です。これは、ドキュメントで詳しく説明できるものではありません。

そうは言っても、ここに必ずテストする必要があるインフラストラクチャの一部を示します。

  • ネットワーク システムの前面のネットワークおよびNIC [物理または仮想]自分自身

  • ディスクIO

  • ファイル制限Linuxではnofile

  • RAM。 oomkillerをオフにしている場合でも、RAMが利用できないことにより問題が発生する可能性があります。

  • CPU

  • 仮想化競合ハイパーバイザーのオーバーコミット

  • cgroupの制限上記に関連する可能性が高い

  • postgresプロセスの kill -9 postmasterを除きます。これは、セグメンテーション違反の適切なシミュレーションです。

やってはいけないことの1つは、ポストマスタープロセスで kill -9 を実行することです。これは、そうすることは実際のシナリオを模倣したものではないためです。インフラストラクチャが安全でなく、攻撃者が kill -9 を実行する可能性が懸念されている場合、いくらHAプロセスを行ってもそれは修正されません。攻撃者は単にプロセスを再度強制終了するか、別の方法で混乱を引き起こします。