Bootstrap

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

  • スクラッチから initdb

  • 既存のPostgreSQLクラスターから直接pg_basebackup または物理ベースバックアップrecovery を介して間接的に

initdb ブートストラップは、Kubernetesの外部にある場合、またはPostgreSQLの別のメジャーバージョンを実行している場合でも、既存のPostgreSQLクラスターから1つ以上のデータベースをインポートするオプションも提供します。この機能の詳細については、 Importing Postgres databases セクションを参照してください。

注釈

既存のクラスターからのブートストラップにより、**レプリカクラスター**の作成が可能になります。これは、継続的リカバリーのままで、ソースクラスターとの同期を維持し、読み取り専用接続を受け入れる独立したPostgreSQLクラスターです。詳細については、 Replica Cluster section を参照してください。

警告

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

注釈

CloudNativePGは Kubernetes' native `VolumeSnapshot API <https://github.com/cloudnative-pg/cloudnative-pg/issues/2081>`_ のサポートを段階的に導入しています

バックアップおよびリカバリ操作におけるインクリメンタルおよび差分コピーの場合 - 基になるストレージクラスでサポートされている場合。 Recovery from Volume Snapshot objects を参照してください。

詳細については。

bootstrap セクション

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

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

  • recovery 既存のクラスターのベースバックアップから復元し、必要に応じて、使用可能なすべてのWALファイルまたは特定の ポイント・インタイム までを再生することにより、PostgreSQLクラスターを作成します

  • pg_basebackup ストリーミングレプリケーションプロトコルを介してpg_basebackup を使用して、同じメジャーバージョンの既存のクローンを作成することにより、PostgreSQLクラスターを作成します。この方法は、データベースをCloudNativePGに移行する場合に特に役立ちますが、すべての要件を満たすのは難しい場合があります。 ライブクラスターからのブートストラップ `pg_basebackup <ライブクラスターからのブートストラップ pg_basebackup>` の警告を必ずご確認ください。

注意深く。

マニフェストでは1つのブートストラップメソッドのみを指定できます。複数のブートストラップメソッドを定義しようとすると、検証エラーが発生します。

initdb メソッドとは対照的に、 recovery とpg_basebackup は両方とも別のクラスターオフラインまたはオンラインに基づいて新しいクラスターを作成し、レプリカクラスターをスピンアップするために使用できます。どちらも外部クラスターの定義に依存します。詳細については、 replica cluster section を参照してください。

CloudNativePGオペレーターがrecovery に提供する考えられるバックアップ方法とバックアップストレージの組み合わせの量を考えると、各方法のガイダンスについては専用の オブジェクトストアからのリカバリー を参照してください。

注釈

"API reference for the `bootstrap section <Bootstrap>` を参照してください。

詳細については、

externalClusters セクション

クラスターマニフェストのexternalClusters セクションを使用して、1つ以上のPostgreSQLクラスターへのアクセスを ソース として構成できます。主な使用例には次のものが含まれます。

  1. データベースのインポート initdb ブートストラップ方法の一部として、論理バックアップとリストアを介して importation of databases 中に利用する外部ソースを指定します。

  2. クロスリージョンレプリケーション 物理レプリケーションを採用するクロスリージョンPostgreSQLクラスターを定義し、個別のKubernetesクラスターまたは従来のVM/ベアメタル環境に拡張できます。

  3. 物理ベースバックアップからの復旧 物理ベースバックアップを参照することにより、PostgreSQLクラスターを完全にまたは特定のポイントインタイムに復旧します。

注釈

進行中の開発は`externalClusters` の機能を拡張して、将来のリリースでの論理レプリケーションやフォーリンサーバーなどの追加のユースケースに対応します。

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

  • 外部クラスターを識別する名前。 source オプションを介して参照として使用します

  • 次の少なくとも1つ

    • ストリーミング接続に関する情報b_tran_3 リカバリオブジェクトストア に関する情報。これは、以下を含むBarman Cloud互換オブジェクトストアです。

      • WALアーカイブポイントインタイムリカバリーに必要

      • カタログPostgresクラスターの物理ベースバックアップの

注釈

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

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

Content of externalClusters

pg_basebackup

recovery

Only streaming

✓

Only object store

✓

Streaming and object store

✓

✓

さらに、 pg_basebackup または完全なrecovery ポイントインタイムの場合、クラスターはレプリカクラスターモードの資格があります。これは、クラスターがストリーミングを介して、PostgreSQLのrestore_command を介したWALシッピングを介して、または2つのいずれかを介してソースから継続的にフィードされることを意味します。

注釈

"API reference for the `externalClusters section <API Reference>` を参照してください。

詳細については、

パスワードファイル

externalClusters エントリ内でパスワードが指定されるたびに、CloudNativePGは自律的に PostgreSQL password file

その場合、各インスタンスの/controller/external/NAME/pgpass にあります。

このアプローチにより、CloudNativePGは、接続文字列でパスワードを公開せずに、外部サーバーとの接続を安全に確立できます。代わりに、接続はpassfile 接続パラメーターを介して前述のファイルを安全に参照します。

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

initdb ブートストラップ方法は、新しいPostgreSQLクラスターをスクラッチから作成するために使用されます。特に指定しない限り、デフォルトのものです。

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

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

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

  storage:
    size: 1Gi

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

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

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

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

  4. 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

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

注釈

追加のユーザーを作成する必要がある場合は、 Declarative database role management を参照してください。

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

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

initdb にオプションを渡す

PostgreSQLデータディレクトリは、 initdb を使用して初期化されます。

CloudNativePGを使用すると、initdb の動作をカスタマイズ、デフォルトのロケール構成やデータチェックサムなどの設定を変更できます。

警告

PostgreSQLのロケールサポートの進行中の重要な機能強化のため、CloudNativePGは、ロケール関連オプションの`initdb` の直接プロキシとしてのみ機能します。 PostgreSQLドキュメントに従って、正しいオプションが提供されていることを確認し、ブートストラッププロセスが正常に完了したことを確認するのはあなたの責任です。

initdb コマンドにカスタムオプションを含めるには、次のパラメーターを使用できます。

組み込みロケール

builtinLocale が値に設定されている場合、CloudNativePGはそれをinitdb の--builtin-locale オプションに渡します。このオプションは、 Locale Support で定義された組み込みロケールを制御します

PostgreSQLドキュメントからデフォルト空このオプションでは、 localeProvider をbuiltin に設定する必要があることに注意してください。 PostgreSQL 17から利用できます。

データチェックサム

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

エンコーディング

encoding が値に設定されている場合、CloudNativePGはそれをinitdb の--encoding オプションに渡します。これは、テンプレートデータベースデフォルトUTF8 のエンコードを選択します。

icuロケール

icuLocale が値に設定されている場合、CloudNativePGはそれをinitdb の--icu-locale オプションに渡します。このオプションは、 Locale Support で定義されたICUロケールを制御します

PostgreSQLドキュメントからデフォルト空このオプションでは、 localeProvider をicu に設定する必要があることに注意してください。 PostgreSQL 15から利用できます。

icuルール

icuRules が値に設定されている場合、CloudNativePGはそれをinitdb の--icu-rules オプションに渡します。このオプションは、 PostgreSQLドキュメントデフォルト空の Locale Support で定義されたICUロケールを制御します。このオプションでは、 localeProvider をicu に設定する必要があることに注意してください。 PostgreSQL 16から利用できます。

ロケール

locale が値に設定されている場合、CloudNativePGはそれをinitdb の--locale オプションに渡します。このオプションは、PostgreSQLドキュメントの Locale Support で定義されているロケールを制御します。デフォルトでは、localeパラメーターは空です。この場合、LANG などの環境変数はロケールを決定するために使用されます。これらの変数はコンテナイメージごとに異なる場合があり、一貫性のない動作が発生する可能性があることに注意してください。

ロケールCollate

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

PostgreSQLドキュメントデフォルトC より。

ロケールCタイプ

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

PostgreSQLドキュメントデフォルトC より。

ロケールプロバイダー

localeProvider が値に設定されている場合、CloudNativePGはそれをinitdb の--locale-provider オプションに渡します。このオプションは、 PostgreSQLドキュメントの Locale Support デフォルト空、PostgreSQLのlibc を意味しますの Locale Support で定義されたロケールプロバイダーを制御します。 PostgreSQL 15から利用できます。

walSegmentSize

walSegmentSize が値に設定されている場合、CloudNativePGはそれをinitdb の--wal-segsize オプションに渡しますデフォルト設定なし-16メガバイトとしてPostgreSQLで定義されています。

注釈

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回実行されるクエリのカスタムリストを指定できます。これらのクエリーは、3つの異なるデータベースに対して スーパーユーザー postgres として、次の特定の順序で実行されます。

  1. postgres データベース postInit セクション

  2. template1 データベース postInitTemplate セクション

  3. アプリケーションデータベース postInitApplication セクション

CloudNativePGは、これらのセクションごとに、次の順序で実行されるカスタムクエリを指定する2つの方法を提供します。

  • クラスターの定義postInitSQL 、postInitTemplateSQL 、およびpostInitApplicationSQL スタンザ内のSQLクエリーのリストとして

  • シークレットおよび/またはConfigMapのリストとして、それぞれに実行されるSQLスクリプトpostInitSQLRefs 、postInitTemplateSQLRefs 、およびpostInitApplicationSQLRefs スタンザが含まれます。シークレットはConfigMapの前に処理されます。

各リストのオブジェクトはシークエンシャルに処理されます。

警告

クエリーはスーパーユーザーとして実行され、クラスター全体を中断する可能性があるため、 postInit 、postInitTemplate 、および`postInitApplication` オプションを使用する際には細心の注意を払ってください。これらのクエリのエラーはブートストラップフェーズを中断し、クラスターが不完全なままとなり、手動介入が必要になります。

注釈

postInitSQLRefs 、postInitTemplateSQLRefs 、および`postInitApplicationSQLRefs` で指定されたConfigMapsまたはSecrets内のエントリの存在を確認します。それ以外の場合、ブートストラップは失敗します。これらのSQLファイルにエラーがあると、ブートストラップフェーズが正常に完了できません。

次の例では、postInitSQL スタンザの一部として単一のSQLクエリーを実行します。

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 DATABASE angus
  storage:
    size: 1Gi

次の例では、 postInitApplicationSQLRefs を使用して、シークレットと、アプリケーションデータベースの初期化後に実行するクエリーを含むConfigMapを指定します。

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

注釈

SQLスクリプト内では、各SQLステートメントは PostgreSQL semantics に従ってサーバーで1回のexecで実行されます。コメントを含めることはできますが、 psql のような内部コマンドは含めることができません。

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

CloudNativePGは、同じメジャーバージョンの別のバージョンから開始するクラスターのブートストラップを有効にします。この操作は、ストリーミングレプリケーションpg_basebackup を介してソースクラスターに直接接続するか、既存の物理的な ベースバックアップ recovery を介して間接的に実行できます。

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

注釈

デフォルトでは、 recovery メソッドは`externalClusters` セクションのクラスターの`name` を厳密に使用して、通常サーバーの名前に予約されているオブジェクトストア内のバックアップデータのメインフォルダーを見つけます。 Backupプラグインは、別のプラグインを指定する方法を提供します。例、 Barman Cloudプラグインは、 serverName を提供します

デフォルトでは、外部クラスター定義のname の値に割り当てられます。

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

recovery のCloudNativePGオペレーターが提供するさまざまなバックアップ方法とバックアップストレージオプションの組み合わせを考慮して、各方法の詳細なガイダンスについては、専用の オブジェクトストアからのリカバリー を参照してください。

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

pg_basebackup ブートストラップモードでは、有効な ストリーミングレプリケーションを使用して、CloudNativePGによって管理される既存の*バイナリ互換** PostgreSQLインスタンス ソース の正確な物理コピーとして、新しいクラスター ターゲット を作成できます。接続。ソースインスタンスは、プライマリまたはスタンバイのPostgreSQLサーバーのいずれかです。 PostgreSQLの物理レプリケーションの長所と短所が完全に適用されるため、以下の要件セクションを完全に確認することが重要です。

この方法の主な使用例には次のものが含まれます。

  • 定期的に(毎日、毎週)再生成する必要があるレポートおよびビジネスインテリジェンスクラスター

  • 定期的な再生毎日、毎週、毎月、匿名化が必要なライブデータを含むテストデータベース

  • スタンドアロンレプリカクラスターの迅速なスピンアップ

  • CloudNativePGクラスターの別の名前空間またはKubernetesクラスターへの物理的な移行

注釈

すべての 要件 が満たされ、オペレーションが徹底的にテストされていることが完全に確信できない限り、物理的レプリケーションに基づいてこの方法を使用して、Kubernetesの外部の既存のPostgreSQLクラスターをCloudNativePGに移行することは避けてください。 CloudNativePGコミュニティは、このようなユースケースについてこのアプローチを承認しておらず、代わりに論理インポートを使用することをお勧めします。物理レプリケーションのすべての要件がCloudNativePGとシームレスに動作する方法で満たされることは非常にまれです。

警告

現在の実装では、このメソッドはソースPostgreSQLインスタンスのクローンを作成し、それにより*スナップショット*を作成します。クローン作成プロセスが完了すると、新しいクラスターがすぐに起動されます。詳細については、 現在の制限 を参照してください。

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

注釈

ターゲットインスタンスとソースインスタンス間のネットワーク接続の構成は、特定のコンテキストと環境に大きく依存するため、CloudNativePGドキュメントの範囲外です。

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

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

  2. TLS証明書認証

両方の認証方法について以下に詳しく説明します。

要件

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

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

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

  • ターゲットとソースは同じテーブルスペースを持つ必要があります

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

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

  • ソースにはREPLICATION LOGIN 特権を持つロールが必要で、pg_hba.conf でこのロールのターゲットインスタンスからの接続を受け入れる必要があります、できればTLSを介して 下記の レプリケーションユーザーについて を参照してください

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

注釈

詳細については、 Planning 、 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` を使用します。以下のセクションの指示を調整する場合、必要に応じて変更してください。

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

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

次のマニフェストは、 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:18.1-system-trixie

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

TLS証明書認証

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

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

注釈

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

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

  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 ブートストラップ方法の場合と同様に、ライブクラスターからブートストラップするクラスターのアプリケーションデータベースの構成もサポートしています。新しいクラスターがレプリカクラスターとしてレプリカモードが有効化されて作成される場合、アプリケーションデータベースの構成はスキップされます。

注釈

Cluster がリカバリモードである間、カタログを含むデータベースへの変更は許可されません。この制限には、Cluster がプライマリに移行するまで遅延されるロールオーバーライドが含まれます。復旧フェーズでは、ロールはソースクラスターで定義されたとおりに残ります。

次の例では、ライブクラスターからブートストラップに従って、所有者app と提供されたシークレット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 データベースが存在しない場合、作成されます。

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

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

  4. username 値がシークレットのowner 値と一致する場合、アプリケーションユーザーこの場合はapp ユーザーのパスワードはシークレットのpassword 値に更新されます。

現在の制限

スナップショットコピー

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

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

この制限は、ターゲットクラスターがレプリカクラスターとして定義されていない場合にのみ適用されることに注意してください。

注釈

移行を試行する前に、プロシージャとアプリケーションの両方をテストする必要があります。特に、必要なだけ移行手順を実行して、運用中のアプリケーションのダウンタイムを体系的に測定することが重要です。