ブートストラップ¶

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

最初から（initdb ）
既存のPostgreSQLクラスターから、直接（pg_basebackup ）または間接的に（recovery ）

initdb ブートストラップは、Kubernetesの外部であっても、既存のPostgresクラスターから1つ以上のデータベースをインポートし、別のメジャーバージョンのPostgresを使用する可能性も提供します。この機能の詳細については、

Postgresデータベースのインポートセクションを参照してください。

重要

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

警告

CloudNativePGでは、 postgres ユーザーとデータベースの両方が常に存在する必要があります。クラスターで管理タスクを実行するには、ローカルのUnixドメインソケットを使用して、 peer 認証を介して`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クラスターを定義できます。将来的には、このセクションではより複雑なシナリオが可能になりますが、現在、物理レプリケーションに基づいて、さまざまなKubernetesクラスターまたは従来のVM /ベアメタル環境にまたがるクロスリージョンPostgreSQLクラスターを定義することを目的としています。

ブートストラップに関する限り、 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

上記のブートストラップの例は次のことを行います。

PostgreSQLのネイティブinitdb コマンドを使用して、新しいPGDATA フォルダーを作成します
superuser-secret という名前のシークレットからpostgres スーパーユーザーのパスワードを設定します
app という名前の非特権ユーザーを作成します
app-secret シークレットのものを使用して、後者（app ）のパスワードを設定します（username がowner と同じ名前と一致することを確認してください）
app ユーザーが所有するapp というデータベースを作成します。

構成よりも規約のおかげで、オペレーターにデフォルトのデータベース名（app ）とデフォルトのアプリケーションユーザー名（データベース名と同じ）を選択させ、スーパーユーザーと両方の安全なパスワードをランダムに生成できますPostgreSQLのアプリケーションユーザ。

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

指定されたシークレットは、 kubernetes.io/basic-auth の仕様に準拠する必要があります。その結果、シークレットのusername は、スーパーユーザーのowner （アプリケーションシークレットの場合）およびpostgres のいずれかと一致する必要があります。

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

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

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

重要

この演算子の将来の実装では、宣言的な構成で追加のユーザーを作成できるようになるかもしれません。

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

データベース名を指定しない場合、オペレーターは慣例に従って app データベースを作成し、デフォルトのWebhookを使用してクラスター定義に追加します。代わりに、データベースを所有するユーザーはデフォルトでデータベース名を使用します。

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

重要

現在、スーパーユーザーシークレットの名前の変更はクラスターに適用されていません。

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

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

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

localeCollate ： localeCollate に値が設定されている場合、CNPGはそれを initdb の--lc-collate オプションに渡します。このオプションは、PostgreSQLドキュメントの Locale Support で定義されているように、照合順序（LC_COLLATE サブカテゴリ）を制御します（デフォルト： C ）。

localeCType ： localeCType に値が設定されている場合、CNPGはそれをinitdb の--lc-ctype オプションに渡します。このオプションは、PostgreSQLドキュメント（デフォルト：C ）の Locale Support で定義されているように、照合順序（LC_CTYPE サブカテゴリ）を制御します。

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

注釈

initdb ブートストラップ中にCloudNativePGが実装する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の将来のバージョンから削除されます。

データベースが作成および構成された直後に1回実行されるクエリのカスタムリストを指定することもできます。これらのクエリは、 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スクリプトを含むSecretsおよび/またはConfigMapsのリストを指定できます。これらの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スクリプト内では、各SQLステートメントは PostgreSQL semantics に従ってサーバー上の単一のexecで実行されますが、コメントを含めることができます psql 。

警告

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

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

CloudNativePGは、同じメジャーバージョンの別のクラスターからのブートストラップを有効にします。この操作は、ストリーミングレプリケーション（pg_basebackup ）を介して、またはリカバリーオブジェクトストア（recovery ）を介して間接的に接続することにより発生します。

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

重要

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

バックアップからのブートストラップ（`recovery` ）¶

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

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

リカバリオブジェクトストアを使用します。これは、 Barman Cloudによって作成され、externalClusters セクションのbarmanObjectStore オプションを介して定義された別のクラスターのバックアップです（推奨）
同じ名前空間にある既存のBackup オブジェクトを使用します（これはバージョン1.8.0より前に使用可能な唯一のオプションでした）。

どちらの回復方法でも、完全な回復（利用可能な最後のWALまで）または最大で: ポイントインタイムリカバリー（PITR）

が有効になります。完全復旧を実行する場合、クラスターをレプリカモードで起動することもできます。

注釈

実行中のクラスターのバックアップとリカバリの詳細は、バックアップとリカバリーで見つけることができます。

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

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` を厳密に使用して、通常サーバーの名前用に予約されているオブジェクトストア内のバックアップデータのメインフォルダーを見つけます。 backupObjectStore.serverName プロパティで別のものを指定できます（デフォルトでは、外部クラスター定義の`name` の値に割り当てられます）。

注釈

上記の例では、並列WAL復元機能を利用して、最大8つのジョブを専用にアーカイブから必要なWALファイルを同時にフェッチします。この機能により、回復時間が大幅に短縮されます。このシナリオを事前に計画し、環境に合わせてこのパラメーターの値を正しく調整してください。それは確かに違いを生む **いつ**（必要になるか）。

`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 ユーザーのパスワードをリセットするために使用されます。
デフォルトでは、デフォルトのターゲットタイムライン（最大11のPostgreSQLの場合はcurrent 、バージョン12以降の場合）でリカバリが続行されます。オプションで recoveryTarget を指定して、ポイントインタイムリカバリを実行できます（ポイントインタイムリカバリー（PITR）を参照）。

重要

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

ポイントインタイムリカバリー（PITR）¶

最新のWALまでのすべての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-secret でアプリケーションデータベースapp を構成します。

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 の所有者として付与されます。

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

重要

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

ライブクラスターからのブートストラップ（`pg_basebackup` ）¶

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

このメソッドの主なユースケースは、Kubernetes外部またはKubernetes内（別のオペレーターなど）からCloudNativePGへの移行によって表されます。

警告

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

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

重要

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

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

ユーザー名/パスワード認証経由
TLS client certificate 経由

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

要件¶

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

ターゲットとソースは同じハードウェアアーキテクチャである必要があります
ターゲットとソースは同じメジャーPostgreSQLバージョンである必要があります
ソースには表領域を定義しないでください（以下の現在の制限を参照）
ソースは、バックアップ用に少なくとも1つのwalsenderとWALストリーミング用に1つを提供することにより、この1回限りのオペレーションのターゲットからのアクセスを許可するのに十分なmax_wal_senders を構成する必要があります
ターゲットインスタンスがソースインスタンスのPostgreSQLポートに接続できるように、ソースとターゲット間のネットワークを構成する必要があります
ソースはREPLICATION LOGIN 特権を持つロールを持っている必要があり、pg_hba.conf のこのロールのターゲットインスタンスから、できればTLSを介した接続を受け入れる必要があります（以下のレプリケーションユーザーについてを参照）
ターゲットは、REPLICATION LOGIN 権限を持つロールを使用してソースPostgreSQLインスタンスに正常に接続できる必要があります

参考

詳細については、PostgreSQLドキュメントの Planning 、ライブクラスターからのブートストラップ（`pg_basebackup ）<ライブクラスターからのブートストラップ（pg_basebackup ）>` 、および High Availability, Load Balancing, and Replication を参照してください。

レプリケーションユーザーについて¶

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

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

Kubernetesの外部を含む他のすべてのケースについては、 REPLICATION 特権を持つユーザーが既にいることを確認するか、以下の指示に従って新しいユーザーを作成してください。

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

createuser -P --replication streaming_replica

ターゲットインスタンスのシークレットに追加する必要があるため、プロンプトでパスワードを入力して保存します。

注釈

名前は重要ではありませんが、簡単にするために`streaming_replica` を使用します。次のセクションの手順を適用すれば、必要に応じて自由に変更できます。

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

pg_basebackup ブートストラップを使用してCloudNativePGでサポートされている最初の認証方法は、ユーザー名とパスワードのマッチングに基づいています。

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

ホスト名または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

次のマニフェストは、 target-db という新しいPostgreSQL 14.4クラスターを作成し、 pg_basebackup ブートストラップメソッドを使用して、 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:14.4

  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バージョン（この場合は14.4）を含むすべての要件を満たす必要があります。

TLS証明書認証¶

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

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

注釈

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

マニフェストは、 cluster-clone-tls と呼ばれる新しいPostgreSQL 14.4クラスターを定義します。これは、 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:14.4

  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 を構成します。

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 の所有者として付与されます。

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

重要

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

現在の制限¶

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

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

スナップショットコピー¶

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

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

重要

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

CloudNativePGの将来のバージョンでは、別のPostgreSQLインスタンスのレプリカである新しいクラスターを作成することにより、ユーザーがログ先行書き込み（WAL）シッピングを介してPostgreSQLの継続的復旧メカニズムを制御できるようになります。これにより、2つの主なユースケースが開かれます。

CloudNativePGの異なるKubernetesクラスターにわたるレプリケーション
- 0カットオーバー時間* pg_basebackup ブートストラップメソッドを使用したCloudNativePGへの移行

ブートストラップ¶

`bootstrap` セクション¶

`externalClusters` セクション¶

空のクラスターをブートストラップする（`initdb` ）¶

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

バックアップからのブートストラップ（`recovery` ）¶

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

`Backup` オブジェクトからの回復¶

その他の考慮事項¶

ポイントインタイムリカバリー（PITR）¶

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

ライブクラスターからのブートストラップ（`pg_basebackup` ）¶

要件¶

レプリケーションユーザーについて¶

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

TLS証明書認証¶

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

現在の制限¶

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

スナップショットコピー¶

前のトピックへ

次のトピックへ

目次

ブートストラップ¶

bootstrap セクション¶

externalClusters セクション¶

空のクラスターをブートストラップする（initdb ）¶

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

バックアップからのブートストラップ（recovery ）¶

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

Backup オブジェクトからの回復¶

その他の考慮事項¶

ポイントインタイムリカバリー（PITR）¶

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

ライブクラスターからのブートストラップ（pg_basebackup ）¶

要件¶

レプリケーションユーザーについて¶

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

TLS証明書認証¶

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

現在の制限¶

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

スナップショットコピー¶

`bootstrap` セクション¶

`externalClusters` セクション¶

空のクラスターをブートストラップする（`initdb` ）¶

バックアップからのブートストラップ（`recovery` ）¶

`Backup` オブジェクトからの回復¶

ライブクラスターからのブートストラップ（`pg_basebackup` ）¶