はじめに¶

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

Patroniを使用したDockerベースのデプロイメントの例については、現在Zalandoで使用されている Spilo _を参照してください。

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

PostgreSQL HA with Kubernetes and Patroni _、KubeCon2016でのJoshBerkusによる講演（ビデオ）
Feb. 2016 Zalando Tech blog post _

開発状況¶

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

新作情報 here を報告します。

技術要件/インストール¶

Pre-requirements for Mac OS

Macに要件をインストールするには、次を実行します。

brew install postgresql etcd haproxy libyaml python

Psycopg

psycopg2-2.8 _以降、psycopg2のバイナリバージョンはデフォルトではインストールされなくなります。ソースコードからインストールするには、Cコンパイラとpostgres+pythondevパッケージが必要です。pythonの世界では psycopg2 OR psycopg2-binary 依存関係を指定できないためインストール方法を決定する必要があります。

利用可能ないくつかのオプションがあります。

ディストリビューションからパッケージマネージャーを使用する

sudo apt-get install python3-psycopg2  # install psycopg2 module on Debian/Ubuntu
sudo yum install python3-psycopg2      # install psycopg2 on RedHat/Fedora/CentOS

バイナリパッケージからpsycopg2をインストールします

pip install psycopg2-binary

ソースからpsycopg2をインストールする

pip install psycopg2>=2.5.4

psycopg2の代わりにpsycopg3.0を使用してください

pip install psycopg[binary]>=3.0.0

General installation for pip

Patroniはpipでインストールできます：

pip install patroni[dependencies]

ここで、dependenciesは空か、次のうちの1つ以上で構成されます。

etcdまたはetcd3: Etcdを分散構成ストア（DCS）として使用するための`python-etcd`モジュール
Consul: ConsulをDCSとして使用するための`python-consul`モジュール
飼育係: ZookeeperをDCSとして使用するための`kazoo`モジュール
出展者: ExhibitorをDCSとして使用するための`kazoo`モジュール（Zookeeperと同じ依存関係）
クベルネテス: PatroniでKubernetesをDCSとして使用するための`kubernetes`モジュール
raft: PythonRaft実装をDCSとして使用するための`pysyncobj`モジュール
aws: AWSコールバックを使用するには`boto3`

たとえば、PatroniをEtcdの依存関係とともにDCSおよびAWSコールバックとしてインストールするためのコマンドは次のとおりです。

pip install patroni[etcd,aws]

レプリカの作成またはカスタムブートストラップスクリプト（つまりWAL-E）で呼び出す外部ツールは、Patroniとは別にインストールする必要があることに注意してください。

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つは、postmasterプロセスで kill -9 を実行することです。これは、そうすることは実際のシナリオを模倣しないためです。インフラストラクチャが安全でなく、攻撃者が kill -9 を実行する可能性があると懸念している場合、どんな量のHAプロセスでもそれを修正することはできません。攻撃者は、単にプロセスを再度強制終了するか、別の方法でカオスを引き起こします。