スタンドアロンを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構成ファイルを作成します。

      • Note (specific for the primary node): クラスターメンバー間のレプリケーションに使用されているレプリケーションスロットがある場合は、 use_slots を有効にし、 slots 構成項目を介して既存のレプリケーションスロットを永続的に構成することをお勧めします。Patroniは、 use_slots が有効になっている場合、メンバー間のレプリケーション用のレプリケーションスロットを自動的に作成し、認識しないレプリケーションスロットをドロップすることに注意してください。ここで永続的なスロットを使用するという考えは、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 に追いつくことができたら、 patronictl edit-config cluster-name member-name コマンドを介して 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. Patani.ymlを更新する

4. DCSから初期化キーを削除するか、DCSから完全なクラスター状態をワイプします。2番目は patronictl remove <cluster-name> を実行することで達成できます。pg_upgradeはinitdbを実行し、実際に新しいPostgreSQLシステム識別子で新しいデータベースを作成するためです。

5. 前の手順でクラスターの状態をワイプした場合、パトローニ.dynamic.jsonを古いデータディレクトリから新しいデータディレクトリにコピーすることをお勧めします。以前に設定したいくつかのPostgreSQLパラメーターを保持するのに役立ちます。

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

7. PostgreSQLバイナリをアップグレードし、atoani.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 が空ではなかったため、ブートストラップは発生しませんでした。このファイルは事前に存在している必要があります。