Bootstrap ========= .. raw:: html このセクションでは、新しいPostgreSQLクラスターを作成するために使用可能なオプションと、その背後にある設計理論的根拠について説明します。新しいクラスターをブートストラップするには、主に2つの方法があります。 - スクラッチから ``initdb`` - 既存のPostgreSQLクラスターから直接\ ``pg_basebackup`` または物理ベースバックアップ\ ``recovery`` を介して間接的に ``initdb`` ブートストラップは、Kubernetesの外部にある場合、またはPostgreSQLの別のメジャーバージョンを実行している場合でも、既存のPostgreSQLクラスターから1つ以上のデータベースをインポートするオプションも提供します。この機能の詳細については、 :ref:`Importing Postgres databases ` セクションを参照してください。 .. Note:: 既存のクラスターからのブートストラップにより、**レプリカクラスター**の作成が可能になります。これは、継続的リカバリーのままで、ソースクラスターとの同期を維持し、読み取り専用接続を受け入れる独立したPostgreSQLクラスターです。詳細については、 :ref:`Replica Cluster section ` を参照してください。 　 .. Warning:: CloudNativePGでは、 `postgres` ユーザーとデータベースの両方が常に存在する必要があります。クラスターで管理タスクを実行するには、ローカルのUnixドメインソケットを使用して、 `postgres` ユーザーとして`peer` 認証を介して`postgres` データベースに接続する必要があります。 `postgres` ユーザーまたは`postgres` データベースは**削除しないでください**。 　 .. Note:: CloudNativePGは `Kubernetes' native `VolumeSnapshot` API `_ のサポートを段階的に導入しています バックアップおよびリカバリ操作におけるインクリメンタルおよび差分コピーの場合 - 基になるストレージクラスでサポートされている場合。 :ref:`Recovery from Volume Snapshot objects ` を参照してください。 詳細については。 　 ``bootstrap`` セクション ------------------------ *bootstrap* メソッドは、クラスター仕様の\ ``bootstrap`` セクションで定義できます。 CloudNativePGは現在、次のブートストラップ方法をサポートしています。 - ``initdb`` 新しいPostgreSQLクラスターを初期化しますデフォルト - ``recovery`` 既存のクラスターのベースバックアップから復元し、必要に応じて、使用可能なすべてのWALファイルまたは特定の *ポイント・インタイム* までを再生することにより、PostgreSQLクラスターを作成します - ``pg_basebackup`` ストリーミングレプリケーションプロトコルを介して\ ``pg_basebackup`` を使用して、同じメジャーバージョンの既存のクローンを作成することにより、PostgreSQLクラスターを作成します。この方法は、データベースをCloudNativePGに移行する場合に特に役立ちますが、すべての要件を満たすのは難しい場合があります。 :ref:`ライブクラスターからのブートストラップ `pg_basebackup` <ライブクラスターからのブートストラップ `pg_basebackup`>` の警告を必ずご確認ください。 注意深く。 マニフェストでは1つのブートストラップメソッドのみを指定できます。複数のブートストラップメソッドを定義しようとすると、検証エラーが発生します。 ``initdb`` メソッドとは対照的に、 ``recovery`` と\ ``pg_basebackup`` は両方とも別のクラスターオフラインまたはオンラインに基づいて新しいクラスターを作成し、レプリカクラスターをスピンアップするために使用できます。どちらも外部クラスターの定義に依存します。詳細については、 :ref:`replica cluster section ` を参照してください。 CloudNativePGオペレーターが\ ``recovery`` に提供する考えられるバックアップ方法とバックアップストレージの組み合わせの量を考えると、各方法のガイダンスについては専用の :ref:`オブジェクトストアからのリカバリー <オブジェクトストアからのリカバリー>` を参照してください。 .. Note:: :ref:`"API reference for the `bootstrap` section ` を参照してください。 詳細については、 　 ``externalClusters`` セクション ------------------------------- クラスターマニフェストの\ ``externalClusters`` セクションを使用して、1つ以上のPostgreSQLクラスターへのアクセスを *ソース* として構成できます。主な使用例には次のものが含まれます。 1. **データベースのインポート** ``initdb`` ブートストラップ方法の一部として、論理バックアップとリストアを介して :ref:`importation of databases ` 中に利用する外部ソースを指定します。 2. **クロスリージョンレプリケーション** 物理レプリケーションを採用するクロスリージョンPostgreSQLクラスターを定義し、個別のKubernetesクラスターまたは従来のVM/ベアメタル環境に拡張できます。 3. **物理ベースバックアップからの復旧** 物理ベースバックアップを参照することにより、PostgreSQLクラスターを完全にまたは特定のポイントインタイムに復旧します。 .. Note:: 進行中の開発は`externalClusters` の機能を拡張して、将来のリリースでの論理レプリケーションやフォーリンサーバーなどの追加のユースケースに対応します。 　 ブートストラップに関する限り、 ``externalClusters`` は、 ``pg_basebackup`` メソッドまたは\ ``recovery`` メソッドのソースPostgreSQLクラスターを定義するために使用できます。外部クラスターには以下が必要です。 - 外部クラスターを識別する名前。 ``source`` オプションを介して参照として使用します - 次の少なくとも1つ - ストリーミング接続に関する情報b_tran_3 **リカバリオブジェクトストア** に関する情報。これは、以下を含むBarman Cloud互換オブジェクトストアです。 - WALアーカイブポイントインタイムリカバリーに必要 - カタログPostgresクラスターの物理ベースバックアップの .. Note:: リカバリオブジェクトストアは、通常、 Barman Cloudによって管理されるAWS S3、Azure Blob Storage、またはGoogle Cloud Storageソースです。 ストリーミング接続のみが定義されている場合、ソースは\ ``pg_basebackup`` メソッドに使用できます。リカバリオブジェクトストアのみが定義されている場合、ソースは\ ``recovery`` メソッドに使用できます。両方が定義されている場合、2つのブートストラップ方法のいずれかを選択できます。次の表は、オプションをまとめたものです。 .. csv-table:: :header: Content of externalClusters,pg_basebackup,recovery :widths: 12,25,15 :align: left :class: longtable Only streaming,✓,"" Only object store,"",✓ Streaming and object store,✓,✓ さらに、 ``pg_basebackup`` または完全な\ ``recovery`` ポイントインタイムの場合、クラスターはレプリカクラスターモードの資格があります。これは、クラスターがストリーミングを介して、PostgreSQLの\ ``restore_command`` を介したWALシッピングを介して、または2つのいずれかを介してソースから継続的にフィードされることを意味します。 .. Note:: :ref:`"API reference for the `externalClusters` section ` を参照してください。 詳細については、 　 パスワードファイル ^^^^^^^^^^^^^^^^^^ ``externalClusters`` エントリ内でパスワードが指定されるたびに、CloudNativePGは自律的に `PostgreSQL password file `_ その場合、各インスタンスの\ ``/controller/external/NAME/pgpass`` にあります。 このアプローチにより、CloudNativePGは、接続文字列でパスワードを公開せずに、外部サーバーとの接続を安全に確立できます。代わりに、接続は\ ``passfile`` 接続パラメーターを介して前述のファイルを安全に参照します。 空のクラスターをブートストラップする ``initdb`` ----------------------------------------------- ``initdb`` ブートストラップ方法は、新しいPostgreSQLクラスターをスクラッチから作成するために使用されます。特に指定しない限り、デフォルトのものです。 次の例には、\ ``initdb`` 構成の完全な構造が含まれています。 .. code:: yaml 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`` シークレットの例です。 .. code:: yaml apiVersion: v1 data: username: YXBw password: cGFzc3dvcmQ= kind: Secret metadata: name: app-secret type: kubernetes.io/basic-auth アプリケーションデータベースは、アプリケーションデータを保存するために使用するデータベースです。アプリケーションは、アプリケーションデータベースを所有するユーザーでクラスターに接続する必要があります。 .. Note:: 追加のユーザーを作成する必要がある場合は、 :ref:`Declarative database role management ` を参照してください。 　 データベース名を指定しない場合、オペレーターは慣例に従って\ ``app`` データベースを作成し、 *デフォルトのWebhook* を使用してクラスター定義に追加します。データベースを所有するユーザーは、代わりにデータベース名をデフォルトにします。 アプリケーションユーザーは、オペレーターによって内部的に使用されず、代わりにスーパーユーザーに依存して、クラスターを目的のステータスに調整します。 ``initdb`` にオプションを渡す ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLデータディレクトリは、 `initdb `_ を使用して初期化されます。 CloudNativePGを使用すると、\ ``initdb`` の動作をカスタマイズ、デフォルトのロケール構成やデータチェックサムなどの設定を変更できます。 .. Warning:: 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で定義されています。 .. Note:: `initdb` ブートストラップ中にCloudNativePGが実装する2つの唯一のロケールオプションは、 `LC_COLLATE` および`LC_TYPE` サブカテゴリーを参照します。残りのロケールサブカテゴリは、 `lc_messages` 、`lc_monetary` 、`lc_numeric` 、および`lc_time` パラメーターを使用して、PostgreSQL構成で直接構成できます。 　 次の例は、データのチェックサムを有効にし、デフォルトのエンコードを\ ``LATIN1`` に設定します。 .. code:: yaml 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 .. Warning:: 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の前に処理されます。 各リストのオブジェクトはシークエンシャルに処理されます。 .. Warning:: クエリーはスーパーユーザーとして実行され、クラスター全体を中断する可能性があるため、 `postInit` 、`postInitTemplate` 、および`postInitApplication` オプションを使用する際には細心の注意を払ってください。これらのクエリのエラーはブートストラップフェーズを中断し、クラスターが不完全なままとなり、手動介入が必要になります。 　 .. Note:: `postInitSQLRefs` 、`postInitTemplateSQLRefs` 、および`postInitApplicationSQLRefs` で指定されたConfigMapsまたはSecrets内のエントリの存在を確認します。それ以外の場合、ブートストラップは失敗します。これらのSQLファイルにエラーがあると、ブートストラップフェーズが正常に完了できません。 次の例では、\ ``postInitSQL`` スタンザの一部として単一のSQLクエリーを実行します。 .. code:: yaml 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を指定します。 .. code:: yaml 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 .. Note:: SQLスクリプト内では、各SQLステートメントは `PostgreSQL semantics `_ に従ってサーバーで1回のexecで実行されます。コメントを含めることはできますが、 `psql` のような内部コマンドは含めることができません。 別のクラスターからのブートストラップ ------------------------------------ CloudNativePGは、同じメジャーバージョンの別のバージョンから開始するクラスターのブートストラップを有効にします。この操作は、ストリーミングレプリケーション\ ``pg_basebackup`` を介してソースクラスターに直接接続するか、既存の物理的な *ベースバックアップ* ``recovery`` を介して間接的に実行できます。 ソースクラスターは、 ``name`` で識別される\ ``externalClusters`` セクションで定義する必要があります。オリジンクラスターと同じ\ ``name`` を使用することをお勧めします。 .. Note:: デフォルトでは、 `recovery` メソッドは`externalClusters` セクションのクラスターの`name` を厳密に使用して、通常サーバーの名前に予約されているオブジェクトストア内のバックアップデータのメインフォルダーを見つけます。 Backupプラグインは、別のプラグインを指定する方法を提供します。例、 Barman Cloudプラグインは、 `serverName `_ を提供します デフォルトでは、外部クラスター定義の\ ``name`` の値に割り当てられます。 　 バックアップからのブートストラップ ``recovery`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``recovery`` のCloudNativePGオペレーターが提供するさまざまなバックアップ方法とバックアップストレージオプションの組み合わせを考慮して、各方法の詳細なガイダンスについては、専用の :ref:`オブジェクトストアからのリカバリー <オブジェクトストアからのリカバリー>` を参照してください。 ライブクラスターからのブートストラップ ``pg_basebackup`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pg_basebackup`` ブートストラップモードでは、有効な *ストリーミングレプリケーション*\ を使用して、CloudNativePGによって管理される既存の*バイナリ互換*\* PostgreSQLインスタンス *ソース* の正確な物理コピーとして、新しいクラスター *ターゲット* を作成できます。接続。ソースインスタンスは、プライマリまたはスタンバイのPostgreSQLサーバーのいずれかです。 PostgreSQLの物理レプリケーションの長所と短所が完全に適用されるため、以下の要件セクションを完全に確認することが重要です。 この方法の主な使用例には次のものが含まれます。 - 定期的に(毎日、毎週)再生成する必要があるレポートおよびビジネスインテリジェンスクラスター - 定期的な再生毎日、毎週、毎月、匿名化が必要なライブデータを含むテストデータベース - スタンドアロンレプリカクラスターの迅速なスピンアップ - CloudNativePGクラスターの別の名前空間またはKubernetesクラスターへの物理的な移行 .. Note:: すべての :ref:`要件 <要件>` が満たされ、オペレーションが徹底的にテストされていることが完全に確信できない限り、物理的レプリケーションに基づいてこの方法を使用して、Kubernetesの外部の既存のPostgreSQLクラスターをCloudNativePGに移行することは避けてください。 CloudNativePGコミュニティは、このようなユースケースについてこのアプローチを承認しておらず、代わりに論理インポートを使用することをお勧めします。物理レプリケーションのすべての要件がCloudNativePGとシームレスに動作する方法で満たされることは非常にまれです。 　 .. Warning:: 現在の実装では、このメソッドはソースPostgreSQLインスタンスのクローンを作成し、それにより*スナップショット*を作成します。クローン作成プロセスが完了すると、新しいクラスターがすぐに起動されます。詳細については、 :ref:`現在の制限 <現在の制限>` を参照してください。 　 ``recovery`` ブートストラップ方法と同様、クローン操作が完了すると、オペレーターは最初のインスタンスからターゲットクラスターの完全な所有権を取得します。これには、CloudNativePGの必要に応じて特定の構成パラメーターのオーバーライド、スーパーユーザーパスワードのリセット、\ ``streaming_replica`` ユーザーの作成、レプリカの管理などが含まれます。結果のクラスターは、ソースインスタンスから独立して動作します。 .. Note:: ターゲットインスタンスとソースインスタンス間のネットワーク接続の構成は、特定のコンテキストと環境に大きく依存するため、CloudNativePGドキュメントの範囲外です。 　 ``pg_basebackup`` によって透過的に管理されるターゲットインスタンス上のストリーミングレプリケーションクライアントは、次のいずれかの方法を使用してソースインスタンスで認証できます。 1. :ref:`ユーザー名/パスワードの認証 <ユーザー名/パスワードの認証>` 2. :ref:`TLS証明書認証 ` 両方の認証方法について以下に詳しく説明します。 要件 ^^^^ ``pg_basebackup`` ブートストラップ方法には、次の要件が適用されます。 - ターゲットとソースは同じハードウェアアーキテクチャである必要があります - ターゲットとソースは同じメジャーPostgreSQLバージョンである必要があります - ターゲットとソースは同じテーブルスペースを持つ必要があります - バックアップ用に少なくとも1つの *walsender* とWALストリーミング用に1つを提供することにより、この一回限りのオペレーションのターゲットからのアクセスを許可するために、十分な\ ``max_wal_senders`` でソースを構成する必要があります - ターゲットインスタンスがソースインスタンスのPostgreSQLポートに接続できるように、ソースとターゲット間のネットワークを構成する必要があります - ソースには\ ``REPLICATION LOGIN`` 特権を持つロールが必要で、\ ``pg_hba.conf`` でこのロールのターゲットインスタンスからの接続を受け入れる必要があります、できればTLSを介して 下記の :ref:`レプリケーションユーザーについて <レプリケーションユーザーについて>` を参照してください - ターゲットは、\ ``REPLICATION LOGIN`` 特権を持つロールを使用してソースPostgreSQLインスタンスに正常に接続できる必要があります .. Note:: 詳細については、 `Planning `_ 、 `pg_basebackup `_ を参照してください。 `High Availability, Load Balancing, and Replication `_ PostgreSQLドキュメント。 　 レプリケーションユーザーについて ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 要件セクションで説明したように、ソースインスタンスに\ ``SUPERUSER`` または、できれば\ ``REPLICATION`` 特権のみを持つユーザーが必要です。 ソースデータベースがCloudNativePGで作成されている場合、 ``streaming_replica`` ユーザーを再利用し、クライアントTLS証明書認証を利用できます。デフォルトでは、\ ``streaming_replica`` に許可される唯一の接続方法です。 Kubernetesの外部を含む他のすべての場合、 ``REPLICATION`` 特権を持つユーザーが既に存在することを確認するか、以下の手順に従って新しいユーザーを作成してください。 ソースシステムの\ ``postgres`` ユーザーとして、次を実行してください。 .. code:: console createuser -P --replication streaming_replica ターゲットインスタンスのシークレットに追加する必要があるため、プロンプトにパスワードを入力し、後で保存します。 .. Note:: 名前は重要ではありませんが、簡単にするために`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`` キーに保存されます。 .. code:: yaml 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`` のクローンを作成します。 .. Note:: この例は、Kubernetesクラスターの外部にあるインスタンスをカバーするように簡単に適合できます。 　 マニフェストは、 ``cluster-clone-tls`` と呼ばれる新しいPostgreSQL 18.1クラスターを定義します。これは、 ``cluster-example`` 外部クラスターから\ ``pg_basebackup`` メソッドを使用してブートストラップされます。ホストは同じクラスター内の読み取り/書き込みサービスによって識別され、 ``streaming_replica`` ユーザーは、提供されたキー、証明書、および認証局情報それぞれ\ ``cluster-example-replication`` および\ ``cluster-example-ca`` シークレットのおかげで認証されます。 .. code:: yaml 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`` ブートストラップ方法の場合と同様に、ライブクラスターからブートストラップするクラスターのアプリケーションデータベースの構成もサポートしています。新しいクラスターがレプリカクラスターとしてレプリカモードが有効化されて作成される場合、アプリケーションデータベースの構成はスキップされます。 .. Note:: `Cluster` がリカバリモードである間、カタログを含むデータベースへの変更は許可されません。この制限には、`Cluster` がプライマリに移行するまで遅延されるロールオーバーライドが含まれます。復旧フェーズでは、ロールはソースクラスターで定義されたとおりに残ります。 　 次の例では、ライブクラスターからブートストラップに従って、所有者\ ``app`` と提供されたシークレット\ ``app-secret`` に保存されたパスワードを使用して\ ``app`` データベースを構成します。 .. code:: 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`` データベースが存在しない場合、作成されます。 2. ``app`` ユーザーが存在しない場合、作成されます。 3. ``app`` ユーザーが\ ``app`` データベースの所有者でない場合、所有権は\ ``app`` ユーザーに付与されます。 4. ``username`` 値がシークレットの\ ``owner`` 値と一致する場合、アプリケーションユーザーこの場合は\ ``app`` ユーザーのパスワードはシークレットの\ ``password`` 値に更新されます。 現在の制限 ^^^^^^^^^^ スナップショットコピー '''''''''''''''''''''' ``pg_basebackup`` メソッドは、PostgreSQLベースバックアップの形式でソースインスタンスのスナップショットを取得します。バックアップの開始からバックアップの適切な終了までに書き込まれるすべてのトランザクションは、2番目の接続を使用してターゲットインスタンスにストリーミングされます ``pg_basebackup`` の\ ``--wal-method=stream`` オプションを参照してください。 バックアップが完了すると、新しいインスタンスが新しいタイムラインで起動され、ソースから分岐します。このため、ターゲットデータベースに移行する前に、ソースデータベースへのすべての書き込み操作を停止することをお勧めします。 この制限は、ターゲットクラスターがレプリカクラスターとして定義されていない場合にのみ適用されることに注意してください。 .. Note:: 移行を試行する前に、プロシージャとアプリケーションの両方をテストする必要があります。特に、必要なだけ移行手順を実行して、運用中のアプリケーションのダウンタイムを体系的に測定することが重要です。