Bootstrap¶

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

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

重要

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

警告

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

`bootstrap` セクション¶

ブートストラップ*メソッドは、clusterspecification.CloudNativePGの bootstrap セクションで定義できます。現在、次のブートストラップメソッドをサポートしています。
initdb ：空のPostgreSQLクラスターを初期化します（デフォルト）
recovery ：既存のクラスターから復元してPostgreSQLクラスターを作成しますバックアップオブジェクトストア経由で、利用可能なすべてのWALファイルまたは最大で指定された特定の時点
pg_basebackup ：の既存のものを複製してPostgreSQLクラスターを作成しますストリーミングレプリケーションプロトコル経由で pg_basebackup を使用する同じメジャーバージョン- データベースをCloudNativePGに移行する場合に便利です。 Kubernetesの外部から。

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

`externalClusters` セクション¶

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

ブートストラップに関する限り、 externalClusters を使用して、 pg_basebackup methodまたは recovery のいずれかのソースPostgreSQLクラスターを定義できます。外部クラスターには次のものがニーズです。

を介してリファレンスとして使用される、オリジンクラスターを識別する名前 source オプション
次の少なくとも1つ：
ストリーミング接続に関する情報- リカバリオブジェクトストア に関する情報。これは、ソースクラスターのバックアップファイル（つまり、ベースバックアップとWALアーカイブ）を含むBarman Cloud互換のオブジェクトストアです。

注釈

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

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

さらに、 pg_basebackup または完全な recovery point in time）の場合、クラスターはレプリカクラスターモードに適格です。これは、ストリーミング、WALシッピング、PostgreSQLの restore_command 、または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 フォルダーを作成します2。名前付けのシークレットから postgres スーパーユーザのパスワードを設定します。名前付けの非特権ユーザを作成します。 app-secret シークレットのパスワードを使用して、後者（ app ）のパスワードを設定します（ username が owner と同じ名前に一致makeことを確認してください）5。 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

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

重要

演算子の将来の実装により、宣言的な構成で追加のユーザーを作成できるようになる可能性があります。

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

データベース名前を指定しない場合、演算子は慣例に従い、 app データベースを作成し、* defaulting webhook *を使用してクラスター定義に追加します。データベースを所有するユーザは、代わりにデータベース名前になります。

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

重要

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

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

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

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

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

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

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の将来のバージョンから削除されます。

データベースを作成して構成した直後に実行されるクエリのカスタムリストを指定することもできます。これらのクエリは、 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 オプションは細心の注意を払って使用してください。これらのクエリのいずれかでエラーが発生すると、ブートストラップフェーズが中断され、クラスターが不完全になります。

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

CloudNativePGは、同じメジャーバージョンの別のバージョンから開始するクラスターのブートストラップを有効にします。このオペレーションは、ストリーミングレプリケーション（ pg_basebackup ）を介してソースクラスターに直接接続するか、リカバリオブジェクトストア（ recovery ）を介して間接的に接続することで実行できます。

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

重要

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

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

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

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

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

どちらのリカバリ方法も、完全リカバリ（最後に使用可能なWALまで）またはポイントインタイムリカバリ（PITR）までのいずれかを有効にします。完全リカバリを実行する場合、クラスターをレプリカモードで起動することもできます。

注釈

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

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

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復元機能を利用して、アーカイブから必要なWALファイルを同時にフェッチするために最大8つのジョブを割り当てています。この機能により、リカバリ時間を大幅に短縮できます。このシナリオを事前に計画し、環境に合わせてこのパラメータの値を正しく調整してください。確かに違いが生じるのは、必要な場合（そうでない場合）です。

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

クラスターを作成する名前空間でBackupリソースが既に利用可能な場合、次の例のように、ed .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 resourceから回復する場合でも、以下の考慮事項が適用されます。

アプリケーションデータベース名前とアプリケーションデータベースユーザは保持されます復元されるバックアップから。演算子は現在試行していませんこれは通常のメンテナンスのパートであるため、基礎となる秘密をバックアップします Kubernetesクラスタ自分自身のアクティビティ。
superuserSecret を指定しない場合、新しいものが自動的に追加されます安全でランダムパスワードで生成されます。秘密はその後に使用されますクラスターの postgres ユーザのパスワードをリセットします。
デフォルトでは、リカバリは最新まで続行されますデフォルトのターゲットタイムラインで利用可能なWAL（ PostgreSQLの場合は current まで 11、バージョン12以降の場合は latest ）。オプションで recoveryTarget を指定して、特定の時点を実行できますリカバリ（ポイントインタイムリカバリ（PITR）を参照）。

重要

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

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

最新のものまですべてのWALを再生する代わりに、abase バックアップを抽出した後、任意の時点でPostgreSQLにWALの再生を停止するように要求できます。 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 の他に、次の基準を使用してリカバリを停止できます。

targetXID は、リカバリを続行するトランザクションIDを指定します
targetName はリストアポイントを指定します（ pg_create_restore_point で作成されます）リカバリの続行先）
targetLSN は、ログ先行書き込みの場所のLSNを指定しますリカバリが進みます

each 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:
        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

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

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

このメソッドのプライマリ使用例は、Kubernetesの外部またはKubernetes内（別の演算子など）からCloudNativePGへの移行で表されます。

警告

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

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

重要

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

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

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

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

要件¶

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

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

参考

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

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

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

ソースデータベースがCloudNativePGで作成されている場合、 streaming_replica ユーザを再利用し、clientTLS証明書認証（デフォルトでは streaming_replica の唯一の許可された接続メソッド）を利用できます。

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

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

createuser -P --replication streaming_replica

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

注釈

名前は重要ではありませんが、簡単にするために streaming_replica を使用します。次のセクションの手順を適用する場合は、フリーに変更できます。

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

pg_basebackup ブートストラップでCloudNativePGがサポートする最初の認証メソッドは、ユーザー名とパスワードのマッチングに基づいています。

プロシージャをスタートする前に、次の情報があることを確認してください。

ホスト名またはIPアドレスで識別されるソースインスタンスの場所およびTCPポート
レプリケーションユーザー名（簡単にするために streaming_replica ）
パスワード

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

#  A more restrictive rule for TLS and IP of origin is recommended
host replication streaming_replica all md5

次のマニフェストは、 pg_basebackup ブートストラップメソッドを使用して、 source-db （ externalClusters 配列内）として定義された外部PostgreSQLクラスターを複製する、 target-db という新しいPostgreSQL 14.2クラスターを作成します。ご覧のとおり、 source-db definitionは 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.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バージョン（この場合は14.2）を含む、クローンオペレーションが機能するためには、すべての要件を満たす必要があります。

TLS証明書認証¶

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

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

注釈

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

マニフェストは、 cluster-clone-tls という新しいPostgreSQL 14.2クラスターを定義します。これは、 cluster-example externalクラスターから 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.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

現在の制限¶

テーブルスペースのサポートがありません¶

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

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

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

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

重要

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

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

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

Bootstrap¶

`bootstrap` セクション¶

`externalClusters` セクション¶

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

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

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

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

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

追加の考慮事項¶

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

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

要件¶

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

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

TLS証明書認証¶

現在の制限¶

テーブルスペースのサポートがありません¶

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

前のトピックへ

次のトピックへ

目次

Bootstrap¶

bootstrap セクション¶

externalClusters セクション¶

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

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

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

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

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

追加の考慮事項¶

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

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

要件¶

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

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

TLS証明書認証¶

現在の制限¶

テーブルスペースのサポートがありません¶

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

`bootstrap` セクション¶

`externalClusters` セクション¶

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

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

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

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