スタンドアロンを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を実行している場合、Postgres systemdユニットを無効にします。これは、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/"start up procedure"をPatroniに引き継ぎます。これを行うには、 patronictl restart cluster-name member-name コマンドを使用してクラスターメンバーを再起動する必要があります。ダウンタイムを最小限にするには、この手順を次のように分割することができます。

   1. スタンバイノードの即時再起動。

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

4. ステップ 1.2. で永久スロットを構成した場合、パトロニによって作成されたスロットの 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ポートにバインドできないと訴えます。

  patroni.yml の postgresql.conf と postgresql.listen の listen_addresses と port を確認する必要があります。 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 は空ではなかったため、ブートストラップは発生しませんでした。このファイルは事前に存在する必要があります。