Bootstrap#

注釈

このセクションで「PostgreSQLクラスター」を参照する場合、特に断りのない限り、同じ概念がPostgreSQLとEDB Postgres Advanced Serverの両方に適用されます。

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

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

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

警告

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

注釈

CloudNativePG™クラスターのEDB Postgres® AIは、 Kubernetes' native `VolumeSnapshot API <cloudnative-pg/cloudnative-pg#2081>`_ のサポートを段階的に導入しています

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

詳細については。

`bootstrap` セクション#

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

initdb 新しいPostgreSQLクラスターを初期化しますデフォルト
recovery 既存のクラスターのベースバックアップから復元し、必要に応じて、使用可能なすべてのWALファイルまたは特定の ポイント・インタイム までを再生することにより、PostgreSQLクラスターを作成します
pg_basebackup ストリーミングレプリケーションプロトコルを介してpg_basebackup を使用して、同じメジャーバージョンの既存のクローンを作成することにより、PostgreSQLクラスターを作成します。この方法は、CloudNativePG™クラスターのEDB Postgres® AIにデータベースを移行する場合に特に役立ちますが、すべての要件を満たすのは難しい場合があります。ライブクラスターからのブートストラップ `pg_basebackup <ライブクラスターからのブートストラップ pg_basebackup>` の警告を必ずご確認ください。

注意深く。

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

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

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

詳細については、

`externalClusters` セクション#

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

データベースのインポート initdb ブートストラップ方法の一部として、論理バックアップとリストアを介して importation of databases 中に利用する外部ソースを指定します。
クロスリージョンレプリケーション 物理レプリケーションを採用するクロスリージョンPostgreSQLクラスターを定義し、個別のKubernetesクラスターまたは従来のVM/ベアメタル環境に拡張できます。
物理ベースバックアップからの復旧 物理ベースバックアップを参照することにより、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つのいずれかを介してソースから継続的にフィードされることを意味します。

詳細については、

パスワードファイル#

externalClusters エントリー内でパスワードが指定されるたびに、CloudNativePG™クラスターのEDB Postgres® AIは PostgreSQL password file

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

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

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

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

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

apiVersion: postgresql.k8s.enterprisedb.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

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

PostgreSQLのネイティブinitdb コマンドを使用して、新しいPGDATA フォルダーを作成します
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

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

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

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

`initdb` にオプションを渡す#

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

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

警告

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

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

組み込みロケール

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

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

データチェックサム

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

エンコーディング

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

icuロケール

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

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

icuルール

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

ロケール

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

ロケールCollate

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

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

ロケールCタイプ

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

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

ロケールプロバイダー

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

walSegmentSize

walSegmentSize が値に設定されている場合、CloudNativePG™クラスターのEDB Postgres® AIは、それをinitdb の--wal-segsize オプションに渡しますデフォルト未設定-16メガバイトとしてPostgreSQLで定義されています。

注釈

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

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

apiVersion: postgresql.k8s.enterprisedb.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™クラスターのEDB Postgres® AIは、 options サブセクションを使用して、initdb 呼び出しの動作をカスタマイズする別の方法をサポートしています。ただし、オペレーターの動作を壊す可能性のあるオプション`--auth` や`-d` などがあることを考えると、このテクニックは非推奨であり、APIの将来のバージョンから削除されます。

初期化後のクエリの実行#

クラスターが作成および構成された直後に、1回実行されるクエリのカスタムリストを指定できます。これらのクエリーは、3つの異なるデータベースに対して スーパーユーザー postgres として、次の特定の順序で実行されます。

postgres データベース postInit セクション
template1 データベース postInitTemplate セクション
アプリケーションデータベース postInitApplication セクション

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

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

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

警告

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

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

apiVersion: postgresql.k8s.enterprisedb.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.k8s.enterprisedb.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 のような内部コマンドは含めることができません。

互換性機能#

EDB Postgres Advanced Serverは、プレーンコミュニティPostgreSQLに多くの互換性機能を追加します。これに関する詳細については、 EDB Postgres Advanced Server を参照してください。

これらの機能は、EPASでのクラスターの作成中に既に有効になっており、コミュニティPostgreSQLイメージではサポートされていません。それらを無効にするには、次の例のように initdb セクションでredwood フラグを使用できます。

apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3
  imageName: <EPAS-based image>

  bootstrap:
    initdb:
      database: app
      owner: app
      redwood: false
  storage:
    size: 1Gi

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

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

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

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

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

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

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

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

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

定期的に(毎日、毎週)再生成する必要があるレポートおよびビジネスインテリジェンスクラスター
定期的な再生毎日、毎週、毎月、匿名化が必要なライブデータを含むテストデータベース
スタンドアロンレプリカクラスターの迅速なスピンアップ
CloudNativePG™クラスタークラスターのEDB Postgres® AIの別の名前空間またはKubernetesクラスターへの物理的移行

警告

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

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

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

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

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

要件#

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

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

High Availability, Load Balancing, and Replication

PostgreSQLドキュメント。

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

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

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

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

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

createuser -P --replication streaming_replica

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

注釈

名前は重要ではありませんが、簡単にするために`streaming_replica` を使用します。以下のセクションの指示を調整する場合、必要に応じて変更してください。

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

pg_basebackup ブートストラップを使用してCloudNativePG™クラスターのEDB Postgres® AIでサポートされている最初の認証方法は、ユーザー名とパスワードの一致に基づいています。

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

ホスト名または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.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
  name: target-db
spec:
  instances: 3
  imageName: docker.enterprisedb.com/k8s/postgresql:18.3-standard-ubi9

  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.3を含むすべての要件を満たす必要があります。

TLS証明書認証#

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

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

注釈

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

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

apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Cluster
metadata:
  name: cluster-clone-tls
spec:
  instances: 3
  imageName: docker.enterprisedb.com/k8s/postgresql:18.3-standard-ubi9

  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 と提供されたシークレットapp-secret に保存されたパスワードを使用してapp データベースを構成します。

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

上記の構成では、次は 復旧が完了した後 にのみ発生します。

app データベースが存在しない場合、作成されます。
app ユーザーが存在しない場合、作成されます。
app ユーザーがapp データベースの所有者でない場合、所有権はapp ユーザーに付与されます。
username 値がシークレットのowner 値と一致する場合、アプリケーションユーザーこの場合はapp ユーザーのパスワードはシークレットのpassword 値に更新されます。

現在の制限#

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

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

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

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

Bootstrap

目次

Bootstrap#

bootstrap セクション#

externalClusters セクション#

パスワードファイル#

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

initdb にオプションを渡す#

初期化後のクエリの実行#

互換性機能#

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

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

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

要件#

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

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

TLS証明書認証#

アプリケーションデータベースの構成#

現在の制限#

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

`bootstrap` セクション#

`externalClusters` セクション#

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

`initdb` にオプションを渡す#

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

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