ブートストラップ

このセクションでは、新しい PostgreSQL クラスターを作成するために必要なオプションと、その背後にある設計の根拠について説明します。新しいクラスターをブートストラップするには、主に次の 2 つの方法があります。

  • 最初から (initdb )

  • 既存の PostgreSQL クラスターから直接 (pg_basebackup ) または間接的に (recovery )

initdb ブートストラップは、既存の Postgres クラスターから 1 つ以上のデータベースをインポートする可能性も提供します。これは、Kubernetes の外部であっても、Postgres のメジャー バージョンが異なります。この機能の詳細については、 Postgres データベースのインポート セクションを参照してください。

重要

既存のクラスターからのブートストラップにより、**レプリカ クラスター**を作成する可能性が開かれます。これは、継続的に復旧され、ソースと同期され、読み取り専用接続を受け入れる独立した PostgreSQL クラスターです。

警告

CloudNativePG では、postgres ユーザーとデータベースの両方が常に存在する必要があります。ローカル Unix ドメイン ソケットを使用して、クラスターで管理タスクを実行するには、peer 認証を介して postgres ユーザーとして postgres データベースに接続する必要があります。 削除しないでください postgres ユーザーまたは postgres データベース!!!

bootstrap セクション

bootstrap メソッドは、クラスター仕様の bootstrap セクションで定義できます。 CloudNativePG は現在、次のブートストラップ メソッドをサポートしています。

  • initdb : 新しい PostgreSQL クラスターを初期化します (デフォルト)

  • recovery : バックアップ オブジェクト ストアを介して既存のクラスターから復元し、すべての利用可能な WAL ファイルまたは特定の時点までを再生することにより、PostgreSQL クラスターを作成します。

  • pg_basebackup :ストリーミングレプリケーションプロトコル経由で pg_basebackup を使用して、同じメジャー バージョンの既存のクラスターを複製することにより、PostgreSQL クラスターを作成します。Kubernetes の外部からでも、データベースを CloudNativePG に移行する場合に役立ちます。

initdb メソッドとは異なり、recovery と pg_basebackup の両方が別のクラスター (オフラインまたはオンライン) に基づいて新しいクラスターを作成し、レプリカ クラスターの起動に使用できます。どちらも外部クラスターの定義に依存しています。

詳細については。

externalClusters セクション

externalClusters セクションでは、現在のクラスターに関連する 1 つ以上の PostgreSQL クラスターを定義できます。将来的には、このセクションではより複雑なシナリオが可能になりますが、現時点では、物理レプリケーションに基づいてクロスリージョン PostgreSQL クラスターを定義し、さまざまな Kubernetes クラスターまたは従来の VM/ベアメタル環境にまたがることを意図しています。

ブートストラップに関する限り、externalClusters を使用して、pg_basebackup メソッドまたは recovery メソッドのソース PostgreSQL クラスターを定義できます。外部クラスターには以下が必要です。

  • source オプションを介して参照として使用される元のクラスターを識別する名前

  • 以下の少なくとも 1 つ:

  • ストリーミング接続に関する情報 - リカバリオブジェクトストア に関する情報。これは、ソース クラスタのバックアップ ファイル、つまりベース バックアップと WAL アーカイブを含むBarman Cloud 互換オブジェクト ストアです。

注釈

復旧オブジェクト ストアは通常、AWS S3、Azure Blob Storage、またはBarman Cloud によって管理される Google Cloud Storage ソースです。

ストリーミング接続のみが定義されている場合、ソースは pg_basebackup メソッドに使用できます。リカバリ オブジェクト ストアのみが定義されている場合、ソースは recovery メソッドに使用できます。両方が定義されている場合、2 つのブートストラップ方法のいずれかを選択できます。

さらに、pg_basebackup または完全な recovery 時点) の場合、クラスターはレプリカ クラスター モードの対象となります。これは、ストリーミング、PostgreSQL の restore_command を介した WAL シッピング、または 2 つのいずれかを介して、クラスターがソースから継続的に供給されることを意味します。

詳細については。

空のクラスターをブートストラップする (initdb )

initdb ブートストラップ メソッドは、新しい PostgreSQL クラスターを最初から作成するために使用されます。特に指定がない限り、これがデフォルトです。

次の例には、initdb 構成の完全な構造が含まれています。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  superuserSecret:
    name: superuser-secret

  bootstrap:
    initdb:
      database: app
      owner: app
      secret:
        name: app-secret

  storage:
    size: 1Gi

上記のブートストラップの例は次のようになります。

  1. PostgreSQL のネイティブ initdb コマンドを使用して、新しい PGDATA フォルダーを作成します。

  2. superuser-secret という名前のシークレットから postgres スーパーユーザー のパスワードを設定します

  3. app という名前の非特権ユーザーを作成します

  4. app-secret シークレットのパスワードを使用して、後者 (app ) のパスワードを設定します (username が owner の同じ名前と一致することを確認してください)。

  5. app ユーザーが所有する app というデータベースを作成します。

構成パラダイム上の慣習のおかげで、オペレーターはデフォルトのデータベース名 (app ) とデフォルトのアプリケーション ユーザー名 (データベース名と同じ) を選択できるほか、スーパーユーザーとユーザーの両方の安全なパスワードをランダムに生成できます。 PostgreSQL のアプリケーション ユーザー。

または、上記の例で説明したように、パスワードを生成してシークレットとして保存し、PostgreSQL クラスターで使用することもできます。

提供されるシークレットは、 kubernetes.io/basic-auth の仕様に準拠する必要があります。その結果、シークレットの username は、スーパーユーザー シークレットの owner (アプリケーション シークレット用) および postgres の 1 つと一致する必要があります。

以下は、basic-auth シークレットの例です。

apiVersion: v1
data:
  username: YXBw
  password: cGFzc3dvcmQ=
kind: Secret
metadata:
  name: app-secret
type: kubernetes.io/basic-auth

アプリケーション データベースは、アプリケーション データの格納に使用する必要があるデータベースです。アプリケーションは、アプリケーション データベースを所有するユーザーでクラスターに接続する必要があります。

重要

オペレーターの将来の実装では、宣言的な構成方法で追加のユーザーを作成できるようになる可能性があります。

postgres スーパーユーザーと postgres データベースは、クラスターを構成するオペレーターのみが使用することになっています。

データベース名を指定しない場合、オペレーターは慣例に従って処理を進め、app データベースを作成し、それを defaulting webhook を使用してクラスター定義に追加します。データベースを所有するユーザーは、代わりにデータベース名にデフォルト設定されます。

アプリケーション ユーザーは、オペレーターによって内部的に使用されることはありません。代わりに、スーパーユーザーに依存してクラスターを目的の状態に調整します。

重要

今のところ、スーパーユーザー シークレットの名前の変更はクラスターに適用されません。

実際の PostgreSQL データ ディレクトリは、initdb PostgreSQL コマンドの呼び出しによって作成されます。そのコマンドにカスタム オプションを追加する必要がある場合 (つまり、テンプレート データベースに使用される locale を変更したり、データ チェックサムを追加したりする場合)、次のパラメーターを使用できます。

dataChecksums : dataChecksums が true に設定されている場合、CNPG は initdb の -k オプションを呼び出して、データ ページのチェックサムを有効にし、I/O システムによる破損の検出を支援します。

encoding : encoding が値に設定されると、CNPG はそれを initdb の --encoding オプションに渡します。これにより、テンプレート データベースのエンコーディングが選択されます (デフォルト: UTF8 )。

localeCollate : localeCollate が値に設定されると、CNPG はそれを initdb の --lc-collate オプションに渡します。このオプションは、 Locale Support で定義されているように、照合順序 (LC_COLLATE サブカテゴリ) を制御します。

PostgreSQL ドキュメントから (デフォルト: C )。

localeCType : localeCType が値に設定されると、CNPG はそれを initdb の --lc-ctype オプションに渡します。このオプションは、 Locale Support で定義されているように、照合順序 (LC_CTYPE サブカテゴリ) を制御します。

PostgreSQL ドキュメントから (デフォルト: C )。

walSegmentSize : walSegmentSize が値に設定されると、CNPG はそれを initdb の --wal-segsize オプションに渡します (デフォルト: 未設定 - PostgreSQL によって 16 メガバイトとして定義されています)。

注釈

CloudNativePG が initdb ブートストラップ中に実装する 2 つのロケール オプションのみが、LC_COLLATE および LC_TYPE サブカテゴリを参照します。残りのロケール サブカテゴリは、lc_messages 、lc_monetary 、lc_numeric 、および lc_time パラメーターを使用して、PostgreSQL 構成で直接構成できます。

次の例では、データ チェックサムを有効にし、デフォルトのエンコーディングを LATIN1 に設定します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  bootstrap:
    initdb:
      database: app
      owner: app
      dataChecksums: true
      encoding: LATIN1
  storage:
    size: 1Gi

CloudNativePG は、options サブセクションを使用して、initdb 呼び出しの動作をカスタマイズする別の方法をサポートしています。ただし、オペレーターの動作を壊す可能性のあるオプション (--auth や -d など) がある場合、この手法は推奨されておらず、API の将来のバージョンから削除される予定です。

データベースが作成および構成された直後に一度だけ実行されるクエリのカスタム リストを指定することもできます。これらのクエリは、postgres データベースに接続された スーパーユーザー (postgres ) として実行されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  bootstrap:
    initdb:
      database: app
      owner: app
      dataChecksums: true
      localeCollate: en_US
      localeCType: en_US
      postInitSQL:
        - CREATE ROLE angus
        - CREATE ROLE malcolm
  storage:
    size: 1Gi

警告

postInitSQL 、postInitApplicationSQL 、および postInitTemplateSQL オプションは細心の注意を払って使用してください。クエリはスーパーユーザーとして実行され、クラスター全体を混乱させる可能性があります。これらのクエリのいずれかでエラーが発生すると、ブートストラップ フェーズが中断され、クラスターが不完全なままになります。

さらに、データベースの作成および構成後に実行されるSQLスクリプトを含む Secret および/または ConfigMap のリストを指定できます。これらのSQLスクリプトは、initdb セクションで指定されたデータベースに接続された superuser ロール (postgres ) を使用して実行されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  bootstrap:
    initdb:
      database: app
      owner: app
      postInitApplicationSQLRefs:
        secretRefs:
        - name: my-secret
          key: secret.sql
        configMapRefs:
        - name: my-configmap
          key: configmap.sql
  storage:
    size: 1Gi

注釈

secretRefs で参照されているSQLスクリプトは、configMapRefs で参照されているものの前に実行されます。どちらのセクションでも、 SQLスクリプトはリストの順序に従って実行されます。 SQLスクリプト内では、各SQLステートメントは PostgreSQL semantics に従ってサーバー上の単一の exec で実行されます。コメントを含めることはできますが、psql のような内部コマンドは含めることができません。

警告

postInitApplicationSQLRefs で指定された ConfigMaps または Secrets 内にエントリが存在することを確認してください。存在しない場合、ブートストラップは失敗します。これらのSQLファイルにエラーがあると、ブートストラップ フェーズが正常に完了しません。

別のクラスターからのブートストラップ

CloudNativePG は、同じメジャー バージョンの別のクラスターから開始するクラスターのブートストラップを有効にします。この操作は、ストリーミングレプリケーション(pg_basebackup ) を介してソース クラスターに直接接続するか、回復オブジェクト ストア (recovery ) を介して間接的に接続することで発生します。

ソース クラスターは、name で識別される externalClusters セクションで定義する必要があります (元のクラスターと同じ name を使用することをお勧めします)。

重要

デフォルトでは、recovery メソッドは externalClusters セクションのクラスターの name を厳密に使用して、通常はサーバーの名前用に予約されているオブジェクト ストア内のバックアップ データのメイン フォルダーを見つけます。 barmanObjectStore.serverName プロパティで別のものを指定できます (デフォルトでは、外部クラスター定義で name の値に割り当てられます)。

バックアップからのブートストラップ (recovery )

recovery ブートストラップ モードでは、既存のバックアップから新しいクラスターを作成できます。つまり、回復オブジェクト ストアです。

CloudNativePG でこの結果を達成するには、次の 2 つの方法があります。

  • Barman Cloud によって作成され、externalClusters セクションの barmanObjectStore オプションで定義された別のクラスターのバックアップである回復オブジェクト ストアを使用する (推奨)

  • 同じ名前空間で既存の Backup オブジェクトを使用する (バージョン 1.8.0 より前では、これが唯一のオプションでした)。

どちらの回復方法でも、完全な回復 (利用可能な最後の WAL まで) または

ポイントインタイムリカバリ (PITR) までのいずれかが可能です。フル

リカバリを実行する場合、クラスタをレプリカ モードで起動することもできます。また、復元されたクラスターの PostgreSQL 構成 (.spec.postgresql.parameters ) が、物理レプリケーションの観点から、元の構成と互換性があることを確認してください。

注釈

バックアップとリカバリ で、実行中のクラスターのバックアップと復元に関する詳細情報を見つけることができます。

オブジェクト ストアからの復元

Barman Cloud によって作成され、サポートされているオブジェクト ストレージに保存されているバックアップから復元できます。 barmanObjectStore セクションに必要なすべての構成を含め、外部クラスターを定義したら、.spec.recovery.source オプションでそれを参照する必要があります。次の例では、Azure の BLOB コンテナーに回復オブジェクト ストアを定義します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore
spec:
  [...]

  superuserSecret:
    name: superuser-secret

  bootstrap:
    recovery:
      source: clusterBackup

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
        azureCredentials:
          storageAccount:
            name: recovery-object-store-secret
            key: storage_account_name
          storageKey:
            name: recovery-object-store-secret
            key: storage_account_key
        wal:
          maxParallel: 8

重要

デフォルトでは、recovery メソッドは externalClusters セクションのクラスターの name を厳密に使用して、通常はサーバーの名前用に予約されているオブジェクト ストア内のバックアップ データのメイン フォルダーを見つけます。 barmanObjectStore.serverName プロパティで別のものを指定できます (デフォルトでは、外部クラスター定義で name の値に割り当てられます)。

注釈

上記の例では、並列 WAL 復元機能を利用して、必要な WAL ファイルをアーカイブから同時に取得するために最大 8 つのジョブを専用にしています。この機能により、回復時間を大幅に短縮できます。このシナリオを前もって計画し、環境に合わせてこのパラメーターの値を正しく調整してください。それは確かに違いを生みます いつ (場合ではなく) あなたがそれを必要とするでしょう.

Backup オブジェクトからの復元

クラスターを作成する名前空間でバックアップ リソースが既に利用可能な場合は、次の例のように、.spec.bootstrap.recovery.backup.name でその名前を指定できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  superuserSecret:
    name: superuser-secret

  bootstrap:
    recovery:
      backup:
        name: backup-example

  storage:
    size: 1Gi

このブートストラップ方式では、復元する必要があるバックアップへの参照のみを指定できます。

その他の考慮事項

回復オブジェクト ストアまたは既存の Backup リソースから回復するかどうかにかかわらず、次の考慮事項が適用されます。

  • アプリケーション データベース名とアプリケーション データベース ユーザーは、復元中のバックアップから保持されます。これは Kubernetes クラスター自体の通常のメンテナンス アクティビティの一部であるため、オペレーターは現在、基になるシークレットのバックアップを試行していません。

  • superuserSecret を指定しない場合、安全でランダムなパスワードを使用して新しいものが自動的に生成されます。次に、シークレットを使用して、クラスターの postgres ユーザーのパスワードをリセットします。

  • デフォルトでは、リカバリはデフォルトのターゲット タイムラインで利用可能な最新の WAL まで続行されます (11 までの PostgreSQL の場合は current 、バージョン 12 以降の場合は latest )。オプションで recoveryTarget を指定して、ポイント イン タイム リカバリを実行できます ( ポイントインタイムリカバリ (PITR) を参照してください)。

重要

barmanObjectStore.wal.maxParallel オプションを使用して、リカバリ オブジェクト ストアからトランザクション ログを同時にダウンロードすることで、アーカイブからの WAL フェッチを高速化することを検討してください。

ポイントインタイムリカバリ (PITR)

最新のものまですべての WAL を再生する代わりに、基本バックアップを抽出した後、任意の時点で WAL の再生を停止するよう PostgreSQL に要求できます。 PostgreSQL はこの手法を使用して、ポイントインタイム リカバリ (PITR) を実現します。

注釈

PITR は、リカバリ オブジェクト ストアと Backup オブジェクトから利用できます。

オペレーターは、Azure に格納された回復オブジェクトとタイムスタンプ ベースの目標を使用する次の例のように、回復ターゲットが指定されている場合に、この機能が動作するために必要な構成パラメーターを生成します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore-pitr
spec:
  instances: 3

  storage:
    size: 5Gi

  bootstrap:
    recovery:
      source: clusterBackup
      recoveryTarget:
        targetTime: "2020-11-26 15:22:00.00000+00"

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
        azureCredentials:
          storageAccount:
            name: recovery-object-store-secret
            key: storage_account_name
          storageKey:
            name: recovery-object-store-secret
            key: storage_account_key
        wal:
          maxParallel: 8

上記の例では、タイムスタンプの形式で targetTime を指定するだけで済み、復元を開始するベース バックアップの指定について心配する必要がないことに気付いたかもしれません。

backupID オプションは、リカバリ プロセスを開始するベース バックアップを指定できるオプションです。デフォルトでは、この値は空です。

値を ( Barmanバックアップ ID の形式で) 割り当てると、オペレーターはそのバックアップを復旧のベースとして使用します。

重要

そのようなバックアップが存在し、アクセス可能であることを確認する必要があります。

バックアップ ID が指定されていない場合、オペレータは次のようにリカバリのベース バックアップを自動的に検出します。

  • targetTime または targetLSN を使用すると、オペレータはそのターゲットの前に完了した最も近いバックアップを選択します

  • それ以外の場合、オペレータは利用可能な最後のバックアップを時系列で選択します。

使用できる回復目標基準は次のとおりです。

targetTime : RFC 3339 形式で表される、リカバリが進行するまでのタイム スタンプ (正確な停止ポイントは、exclusive オプションの影響も受けます)

targetXID : リカバリが続行されるまでのトランザクション ID (正確な停止ポイントは、exclusive オプションの影響も受けます);トランザクション ID はトランザクションの開始時に順番に割り当てられますが、トランザクションは異なる番号順で完了する可能性があることに注意してください。回復されるトランザクションは、指定されたトランザクションよりも前にコミットされたトランザクションです (オプションで指定されたトランザクションも含まれます)。

targetName : 復旧が進む名前付きの復元ポイント (pg_create_restore_point() で作成)

targetLSN : リカバリが続行されるログ先行書き込みの場所の LSN (正確な停止ポイントは exclusive オプションの影響も受けます)

targetImmediate : 一貫した状態に達したらすぐに、つまりできるだけ早く復旧を終了する必要があります。オンライン バックアップから復元する場合、これはバックアップの作成が終了した時点を意味します。

重要

targetTime または targetLSN のいずれかが指定されている場合、オペレーターは最も近いバックアップを自動的に取得できますが、これは残りのターゲット (targetName 、targetXID 、および targetImmediate ) では不可能です。このような場合、カタログで利用可能な最後のバックアップで問題がない場合を除き、backupID を指定することが重要です。

以下の例では、targetName ベースのリカバリ ターゲットを使用しています。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
  bootstrap:
    recovery:
      source: clusterBackup
      recoveryTarget:
        backupID: 20220616T142236
        targetName: restore_point_1
[...]

各 recoveryTarget 構成で、上記のターゲットから 1 つだけ選択できます。

さらに、targetTLI 強制復旧を特定のタイムラインに指定できます。

デフォルトでは、以前のパラメーターは排他的であると見なされ、回復ターゲットの直前で停止します。 Azure の BLOB コンテナーに依存する次の例のように、回復ターゲットの直後に停止し、exclusive パラメーターを false に設定して、包括的な動作を要求できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore-pitr
spec:
  instances: 3

  storage:
    size: 5Gi

  bootstrap:
    recovery:
      source: clusterBackup
      recoveryTarget:
        backupID: 20220616T142236
        targetName: "maintenance-activity"
        exclusive: false

  externalClusters:
    - name: clusterBackup
      barmanObjectStore:
        destinationPath: https://STORAGEACCOUNTNAME.blob.core.windows.net/CONTAINERNAME/
        azureCredentials:
          storageAccount:
            name: recovery-object-store-secret
            key: storage_account_name
          storageKey:
            name: recovery-object-store-secret
            key: storage_account_key
        wal:
          maxParallel: 8

アプリケーション データベースを構成する

復元されたクラスターの場合、追加の構成を使用して、アプリケーション データベース名と資格情報を構成できます。アプリケーション データベースの資格情報を更新するには、独自のパスワードを生成してシークレットとして保存し、シークレットを使用してデータベースを更新します。または、オペレーターがランダムに安全なパスワードを使用してシークレットを生成できるようにすることもできます。

空のクラスターをブートストラップする (`initdb )<空のクラスターをブートストラップする (initdb )>` を参照してください

シークレットの詳細については、セクションを参照してください。

次の例では、アプリケーション データベース app を所有者 app で構成し、シークレット app-secret を指定します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  bootstrap:
    recovery:
      database: app
      owner: app
      secret:
        name: app-secret
      [...]

上記の構成では、リカバリの完了後に次のことが行われます。

  1. データベース app が存在しない場合、新しいデータベース app が作成されます。

  2. ユーザー app が存在しない場合、新しいユーザー app が作成されます。

  3. ユーザー app がデータベースの所有者でない場合、ユーザー app はデータベース app の所有者として付与されます。

  4. username の値が owner の値と秘密裏に一致する場合、アプリケーション データベースのパスワードは秘密裏に password の値に変更されます。

重要

レプリカ モードが有効になっているレプリカ クラスターの場合、元のクラスターから復元されるため、オペレーターは PostgreSQL インスタンスにデータベースまたはユーザーを作成しません。

ライブ クラスターからのブートストラップ (pg_basebackup )

pg_basebackup ブートストラップ モードでは、有効な ストリーミングレプリケーション 接続を介して、既存の バイナリ互換 PostgreSQL インスタンス (ソース) の正確な物理コピーとして、新しいクラスター (ターゲット) を作成できます。ソース インスタンスは、プライマリ PostgreSQL サーバーまたはスタンバイ PostgreSQL サーバーのいずれかです。

この方法の主な使用例は、Kubernetes の外部または Kubernetes 内 (別のオペレーターなど) からの CloudNativePG への 移行 です。

警告

現在の実装では、クローン作成プロセスが終了すると、元の PostgreSQL インスタンスの スナップショット が作成され、作成されたクラスターがすぐに開始されます。詳細については、以下の 現在の制限事項 を参照してください。

recovery ブートストラップ メソッドの場合と同様に、クローン操作が完了すると、オペレーターはターゲット クラスターの所有権を最初のインスタンスから取得します。これには、CloudNativePG で必要な一部の構成パラメーターのオーバーライド、スーパーユーザー パスワードのリセット、streaming_replica ユーザーの作成、レプリカの管理などが含まれます。結果のクラスターは、ソース インスタンスから完全に独立しています。

重要

ターゲット インスタンスとソース インスタンス間のネットワークの構成は、実際のコンテキストと環境に依存するため、CloudNativePG ドキュメントの範囲を超えています。

pg_basebackup によって透過的に管理されるターゲット インスタンス上のストリーミングレプリケーションクライアントは、次のいずれかの方法でソース インスタンス上で自身を認証できます。

  1. ユーザー名/パスワード認証 経由

  2. TLS client certificate 経由

CloudNativePG によって管理されているか、TLS 認証用に構成されているソースに接続する場合は、後者が推奨されます。ただし、最初のオプションは、一般的に PostgreSQL サーバーに対する認証の最も一般的な形式であり、ソース インスタンスが Kubernetes 以外の従来の環境にある場合は、最も簡単な方法かもしれません。両方のケースについて以下で説明します。

要件

次の要件が pg_basebackup ブートストラップ メソッドに適用されます。

  • ターゲットとソースは同じハードウェア アーキテクチャを持つ必要があります

  • ターゲットとソースの PostgreSQL のメジャー バージョンが同じである必要があります

  • ソースにはテーブルスペースが定義されていてはなりません (以下の

    現在の制限事項 を参照)

  • ソースは、バックアップ用に少なくとも 1 つの walsender と WAL ストリーミング用に 1 つを提供することにより、この 1 回限りの操作のためにターゲットからのアクセスを許可するのに十分な max_wal_senders で構成する必要があります。

  • ターゲット インスタンスがソース インスタンスの PostgreSQL ポートに接続できるように、ソースとターゲット間のネットワークを構成する必要があります。

  • ソースには REPLICATION LOGIN 特権を持つ役割が必要であり、できれば TLS 経由で、pg_hba.conf でこの役割のターゲット インスタンスからの接続を受け入れる必要があります (以下の

  • ターゲットは、REPLICATION LOGIN 権限を持つロールを使用してソース PostgreSQL インスタンスに正常に接続できる必要があります

参考

詳細については、 Planning 、 ライブ クラスターからのブートストラップ (`pg_basebackup )<ライブ クラスターからのブートストラップ (pg_basebackup )>` を参照してください。

および High Availability, Load Balancing, and Replication

PostgreSQL のドキュメントに記載されています。

複製ユーザーについて

要件セクションで説明したように、ソース インスタンスで SUPERUSER 権限、またはできれば REPLICATION 権限のみを持つユーザーが必要です。

ソース データベースが CloudNativePG で作成されている場合、streaming_replica ユーザーを再利用して、クライアント TLS 証明書認証を利用できます (デフォルトでは、streaming_replica で許可されている唯一の接続方法です)。

Kubernetes 以外の場合を含め、他のすべてのケースでは、REPLICATION 権限を持つユーザーが既に存在することを確認するか、以下の手順に従って新しいユーザーを作成してください。

ソース システムの postgres ユーザーとして、次を実行してください。

createuser -P --replication streaming_replica

プロンプトでパスワードを入力し、後で使用できるように保存します。これは、ターゲット インスタンスのシークレットに追加する必要があるためです。

注釈

名前は重要ではありませんが、簡単にするために streaming_replica を使用します。次のセクションの手順を変更する場合は、自由に変更してください。

ユーザー名/パスワード認証

CloudNativePG が pg_basebackup ブートストラップでサポートする最初の認証方法は、ユーザー名とパスワードの照合に基づいています。

手順を開始する前に、次の情報があることを確認してください。

  • ホスト名または IP アドレスと TCP ポートで識別されるソース インスタンスの場所

  • レプリケーション ユーザー名 (簡単にするために streaming_replica )

  • パスワード

ソース PostgreSQL インスタンスの pg_hba.conf ファイルに、次のような行を追加する必要がある場合があります。

#  A more restrictive rule for TLS and IP of origin is recommended

host replication streaming_replica all md5

次のマニフェストは、pg_basebackup ブートストラップ メソッドを使用して target-db という名前の新しい PostgreSQL 15.2 クラスターを作成し、source-db (externalClusters 配列内) として定義された外部 PostgreSQL クラスターのクローンを作成します。ご覧のとおり、source-db 定義は source-db.foo.com ホストを指し、streaming_replica ユーザーとして接続します。このユーザーのパスワードは source-db-replica-user シークレットの password キーに保存されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: target-db
spec:
  instances: 3
  imageName: ghcr.io/cloudnative-pg/postgresql:15.2

  bootstrap:
    pg_basebackup:
      source: source-db

  storage:
    size: 1Gi

  externalClusters:
  - name: source-db
    connectionParameters:
      host: source-db.foo.com
      user: streaming_replica
    password:
      name: source-db-replica-user
      key: password

複製操作が機能するには、同じ PostgreSQL バージョン (この場合は 15.2) を含め、すべての要件を満たす必要があります。

TLS 証明書認証

pg_basebackup ブートストラップを使用して CloudNativePG でサポートされている 2 番目の認証方法は、TLS クライアント証明書に基づいています。これは、セキュリティの観点から推奨されるアプローチです。

次の例では、同じ Kubernetes クラスター内の既存の PostgreSQL クラスター (cluster-example ) を複製します。

注釈

この例は、Kubernetes クラスターの外部に存在するインスタンスをカバーするように簡単に適応させることができます。

マニフェストは、cluster-clone-tls と呼ばれる新しい PostgreSQL 15.2 クラスターを定義します。これは、cluster-example 外部クラスターから pg_basebackup メソッドを使用してブートストラップされます。ホストは同じクラスター内の読み取り/書き込みサービスによって識別されますが、streaming_replica ユーザーは、提供されたキー、証明書、および認証局情報 (それぞれ cluster-example-replication および cluster-example-ca シークレット内) のおかげで認証されます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-clone-tls
spec:
  instances: 3
  imageName: ghcr.io/cloudnative-pg/postgresql:15.2

  bootstrap:
    pg_basebackup:
      source: cluster-example

  storage:
    size: 1Gi

  externalClusters:
  - name: cluster-example
    connectionParameters:
      host: cluster-example-rw.default.svc
      user: streaming_replica
      sslmode: verify-full
    sslKey:
      name: cluster-example-replication
      key: tls.key
    sslCert:
      name: cluster-example-replication
      key: tls.crt
    sslRootCert:
      name: cluster-example-ca
      key: ca.crt
``` #### アプリケーション データベースを構成する

`initdb`  および `recovery`  ブートストラップ メソッドの場合と同様に、ライブ クラスターからブートストラップするクラスターのアプリケーション データベースの構成もサポートしています。新しいクラスターがレプリカ クラスターとして作成された場合 (レプリカ モードが有効になっている場合)、アプリケーション データベースの構成はスキップされます。

次の例では、ライブ クラスターからのブートストラップ後に、提供されたシークレット `app-secret`  のパスワードを使用してアプリケーション データベース `app`  を構成します。

```yaml
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  bootstrap:
    pg_basebackup:
      database: app
      owner: app
      secret:
        name: app-secret
      source: cluster-example

上記の構成では、リカバリの完了後に次のことが行われます。

  1. データベース app が存在しない場合、新しいデータベース app が作成されます。

  2. ユーザー app が存在しない場合、新しいユーザー app が作成されます。

  3. ユーザー app がデータベースの所有者でない場合、ユーザー app はデータベース app の所有者として付与されます。

  4. username の値が owner の値と秘密裏に一致する場合、アプリケーション データベースのパスワードは秘密裏に password の値に変更されます。

重要

レプリカ モードが有効になっているレプリカ クラスターの場合、元のクラスターから復元されるため、オペレーターは PostgreSQL インスタンスにデータベースまたはユーザーを作成しません。

現在の制限事項

表領域のサポートがありません

CloudNativePG には現在、PostgreSQL グローバル オブジェクト、つまりロール、データベース、およびテーブルスペースの完全な宣言型管理は含まれていません。ロールとデータベースはソース インスタンスからターゲット クラスターにコピーされますが、テーブルスペースには、このバージョンの CloudNativePG にはない機能、つまり追加の永続ボリュームの定義と管理が必要です。ベース バックアップとテーブルスペースを処理する場合、PostgreSQL 自体では、ソース インスタンスの正確なマウント ポイントがターゲット インスタンスにも存在する必要があります。この場合、CloudNativePG が管理する Kubernetes のポッドです。このため、テーブルスペースを利用する PostgreSQL インスタンスを CloudNativePG に直接移行することはできません (最初にテーブルスペースをソースから削除するか、組織がこの機能を必要とする場合は EDB に連絡して優先順位を付けてください)。

スナップショット コピー

pg_basebackup メソッドは、ソース インスタンスのスナップショットを PostgreSQL ベース バックアップの形式で取得します。バックアップの開始からバックアップの正しい終了までに書き込まれたすべてのトランザクションは、2 番目の接続を使用してターゲット インスタンスにストリーミングされます (pg_basebackup の --wal-method=stream オプションを参照してください)。

バックアップが完了すると、新しいインスタンスが新しいタイムラインで開始され、ソースから分岐します。このため、Kubernetes のターゲット データベースに移行する前に、ソース データベースへのすべての書き込み操作を停止することをお勧めします。

重要

移行を試みる前に、手順とアプリケーションの両方をテストする必要があります。特に、本番環境でのアプリケーションのダウンタイムを体系的に測定するために、必要に応じて何度でも移行手順を実行することが基本です。サポートが必要な場合は、EDB までお気軽にお問い合わせください。