スタンドアロンをPatroniクラスターに変換する

このセクションでは、スタンドアロンPostgreSQLインスタンスをPatroniクラスターに変換するプロセスについて説明します。

既存のPostgreSQLインスタンスを使用せずにPatroniクラスターをデプロイするには、代わりに Running and Configuring を参照してください。

手順

既存のPostgresクラスターをPatroni管理クラスターに変換する手順の概要を以下に示します。この手順では、既存のクラスターの一部であるすべてのノードが現在稼働中であり、移行の進行中にPostgres構成を変更するつもりは「ない」ことを前提としています。手順:

1. Patroni構成の authentication セクションの説明に従って、Postgresユーザーを作成します。以下のコードブロックにユーザーを作成するためのサンプルSQLコマンドがあり、環境に応じてユーザー名とパスワードを置き換える必要があります。関連するユーザーがすでに存在する場合は、この手順をスキップできます。

   -- Patroni superuser
   -- Replace PATRONI_SUPERUSER_USERNAME and PATRONI_SUPERUSER_PASSWORD accordingly
   CREATE USER PATRONI_SUPERUSER_USERNAME WITH SUPERUSER ENCRYPTED PASSWORD 'PATRONI_SUPERUSER_PASSWORD';
   
   -- Patroni replication user
   -- Replace PATRONI_REPLICATION_USERNAME and PATRONI_REPLICATION_PASSWORD accordingly
   CREATE USER PATRONI_REPLICATION_USERNAME WITH REPLICATION ENCRYPTED PASSWORD 'PATRONI_REPLICATION_PASSWORD';
   
   -- Patroni rewind user, if you intend to enable use_pg_rewind in your Patroni configuration
   -- Replace PATRONI_REWIND_USERNAME and PATRONI_REWIND_PASSWORD accordingly
   CREATE USER PATRONI_REWIND_USERNAME WITH ENCRYPTED PASSWORD 'PATRONI_REWIND_PASSWORD';
   GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO PATRONI_REWIND_USERNAME;
   GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO PATRONI_REWIND_USERNAME;
   GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO PATRONI_REWIND_USERNAME;
   GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO PATRONI_REWIND_USERNAME;
   

2. すべてのPostgresノードで次の手順を実行します。次のノードに進む前に、1つのノードですべての手順を実行してください。プライマリノードから始めて、各スタンバイノードに進みます。

   1. systemdを介してPostgresを実行している場合は、Postgressystemdユニットを無効にします。これは、PatroniがPostgresデーモンの起動と停止を管理するときに実行されます。

   2. PatroniのYAML構成ファイルを作成します。これには Patroni configuration generation and validation tooling を使用できます。

      • Note (specific for the primary node): クラスターメンバー間のレプリケーションに使用されているレプリケーションスロットがある場合は、 use_slots を有効にし、 slots 構成項目を使用して既存のレプリケーションスロットを永続的なスロットとして構成することをお勧めします。 use_slots が有効になっている場合、Patroniはメンバー間のレプリケーション用にレプリケーションスロットを自動的に作成し、認識しないレプリケーションスロットを削除することに注意してください。ここで永久スロットを使用するという考えは、Patroniへの移行の進行中に既存のスロットを維持できるようにすることです。詳細については、 Note (specific for the primary node): を参照してください。

   3. patroni systemdサービスユニットを使用してPatroniを起動します。Postgresがすでに実行されていることを自動的に検出し、インスタンスの監視を開始します。

3. Postgresの「起動手順」をPatroniに引き渡します。これを行うには、 patronictl restart cluster-name member-name コマンドを使用してクラスターメンバーを再起動する必要があります。ダウンタイムを最小限に抑えるために、このステップを次のように分割することをお勧めします。

   1. スタンバイノードを即時に再起動します。

   2. メンテナンス時間枠内でのプライマリノードのスケジュールされた再起動。

4. ステップ 1.2. で永続スロットを構成した場合は、Patroniによって作成されたスロットの restart_lsn が、対応するメンバーの元のスロットの restart_lsn に追いつくことができたら、 1.2. コマンドを使用して永続スロットを slots 構成から削除する必要があります。 slots 構成からスロットを削除すると、元のスロットが不要になったときにPatroniがクラスターから元のスロットを削除できるようになります。以下に、いくつかのスロットの restart_lsn を確認するクエリの例を示しますので、それらを比較できます。

   -- Assume original_slot_for_member_x is the name of the slot in your original
   -- cluster for replicating changes to member X, and slot_for_member_x is the
   -- slot created by Patroni for that purpose. You need restart_lsn of
   -- slot_for_member_x to be >= restart_lsn of original_slot_for_member_x
   SELECT slot_name,
          restart_lsn
   FROM pg_replication_slots
   WHERE slot_name IN (
       'original_slot_for_member_x',
       'slot_for_member_x'
   )
   

PostgreSQLバージョンのメジャーアップグレード

現時点でメジャーアップグレードを実行できる唯一の方法は次のとおりです。

1. ストップ・パトローニ

2. PostgreSQLバイナリをアップグレードし、プライマリノードで pg_upgrade を実行します。

3. patroni.ymlを更新する

4. DCSから初期化キーを削除するか、DCSから完全なクラスター状態を消去します。2番目の方法は、 patronictl remove cluster-name を実行することで実現できます。これは、pg_upgradeが実際に新しいPostgreSQLシステム識別子を持つ新しいデータベースを作成するinitdbを実行するために必要です。

5. 前の手順でクラスターの状態を消去した場合は、古いデータディレクトリからpatroni.dynamic.jsonを新しいデータディレクトリにコピーするとよいでしょう。これは、以前に設定したいくつかのPostgreSQLパラメータを保持するのに役立ちます。

6. プライマリノードでPatroniを起動します。

7. PostgreSQLバイナリをアップグレードし、patroni.ymlを更新し、スタンバイノードのdata_dirを消去します。

8. スタンバイノードでPatroniを起動し、レプリケーションが完了するまで待ちます。

スタンバイノードでのpg_upgradeの実行は、PostgreSQLではサポートされていません。何をしようとしているのかわかっている場合は、スタンバイノードでdata_dirをワイプする代わりに、https://www.postgresql.org/docs/current/pgupgrade.htmlで説明されているrsync手順を試すことができます。ただし、最も安全な方法は、Patroniにデータを複製させることです。

よくある質問

• Patroniの起動中に、PatroniはPostgreSQLポートにバインドできないというメッセージを出します。

  postgresql.conf の listen_addresses と port 、および patroni.yml の postgresql.listen を確認する必要があります。 pg_hba.conf はそのようなアクセスを許可する必要があることを忘れないでください。

• Patroniにノードの再起動を要求すると、PostgreSQLはエラーメッセージ could not open configuration file /"/etc/postgresql/10/main/pg_hba.conf/": No such file or directory を表示します。

  これは、PostgreSQL構成の管理方法に応じてさまざまな意味を持ちます。postgresql.config_dir`を指定した場合、Patroniは新しいクラスターをブートストラップするときにのみ ``pg_hba.conf` セクションの設定に基づいて pg_hba.conf を生成します。このシナリオでは、 PGDATA は空ではなかったため、ブートストラップは発生しませんでした。このファイルは事前に存在しておく必要があります。