導入¶
Patroniは、Pythonを使用した高可用性(HA)PostgreSQLソリューションのテンプレートです。Patroniは、Composeのプロジェクトである Governor _のフォークとして誕生しました。たくさんの新機能が含まれています。
Patroniを使用したDockerベースのデプロイメントの例については、現在Zalandoで使用されている Spilo _を参照してください。
追加の背景情報については、以下を参照してください。
PostgreSQL HA with Kubernetes and Patroni _、KubeCon2016でのJoshBerkusの講演(ビデオ)
開発状況¶
Patroniは積極的に開発中であり、貢献を受け入れています。詳細については、以下の Contributing セクションを参照してください。
新しいリリース情報 here を報告します。
技術的要件/インストール¶
さまざまなプラットフォームでのPatroniのインストールとアップグレードに関するガイダンスについては、 here にアクセスしてください。
PostgreSQLノードの数の計画¶
Patroni/PostgreSQLノードはDCSノードから分離されているため(Patroniが独自にRAFTを実装する場合を除く)、そのためノードの最小数に関する要件はありません。1つのプライマリと1つのスタンバイで構成されるクラスターを実行してもまったく問題ありません。スタンバイノードは後で追加できます。
実行と構成¶
次のセクションでは、Patroniリポジトリがhttps://github.com/zalando/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ファイルのさまざまな設定をテストして、クラスターの動作がどのように変化するかを確認します。いくつかのコンポーネントを強制終了して、システムがどのように動作するかを確認します。
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)
ラム。oomkillerをオフにしている場合でも、RAMが利用できないと問題が発生する可能性があります。
CPU
仮想化競合(ハイパーバイザーのオーバーコミット)
cgroupの制限(上記に関連する可能性があります)
任意のpostgresプロセスの
kill -9(postmasterを除く)。これはセグメンテーション違反の適切なシミュレーションです。
やってはいけないことの1つは、ポストマスタープロセスで kill -9 を実行することです。これは、そうすることは現実のシナリオを模倣するものではないためです。インフラストラクチャが安全ではなく、攻撃者が kill -9 を実行する可能性があると懸念している場合、HAプロセスをどれだけ実行しても問題は解決されません。攻撃者は単にプロセスを再度強制終了するか、別の方法で混乱を引き起こします。