Bootstrap ========= .. Note:: このセクションで「PostgreSQLクラスター」を参照する場合、特に記載のない限り、 PostgreSQLとEDB Postgres Advancedの両方に同じ概念が適用されます。 このセクションでは、新しいPostgreSQLクラスターを作成するために必要なオプションと、その背後にある設計理論的根拠について説明します。新しいクラスターをブートストラップするには、主に2つの方法があります。 - スクラッチから ``initdb`` - 既存のPostgreSQLクラスターから直接\ ``pg_basebackup`` または物理ベースバックアップ\ ``recovery`` を介して間接的に ``initdb`` ブートストラップは、Kubernetesの外部で、Postgresの異なるメジャーバージョンを使用している場合でも、既存のPostgresクラスターから1つ以上のデータベースをインポートする可能性も提供します。この機能の詳細については、 :ref:`Importing Postgres databases ` セクションを参照してください。 .. Important:: 既存のクラスターからのブートストラップは、**レプリカクラスター**を作成する可能性を開きます。これは、継続的リカバリーでソースと同期し、読み取り専用接続を受け入れる独立したPostgreSQLクラスターです。 .. Warning:: EDB CloudNativePGクラスターでは、 `postgres` ユーザーとデータベースの両方が常に存在する必要があります。クラスターで管理タスクを実行するには、ローカルのUnixドメインソケットを使用して、 `postgres` ユーザーとして`peer` 認証を介して`postgres` データベースに接続する必要があります。 `postgres` ユーザーまたは`postgres` データベースは**削除しないでください**。 .. Note:: EDB CloudNativePGクラスターは、 `Kubernetes' native `VolumeSnapshot` API `_ のサポートを段階的に導入しています バックアップおよびリカバリ操作におけるインクリメンタルおよび差分コピーの場合 - 基になるストレージクラスでサポートされている場合。 :ref:`Recovery from Volume Snapshot objects ` を参照してください。 詳細については。 ``bootstrap`` セクション ------------------------ *bootstrap* メソッドは、クラスター仕様の\ ``bootstrap`` セクションで定義できます。 EDB CloudNativePGクラスターは、現在次のブートストラップ方法をサポートしています。 - ``initdb`` 新しいPostgreSQLクラスターを初期化しますデフォルト - ``recovery`` 既存のクラスターのベースバックアップから復元し、必要に応じて、使用可能なすべてのWALファイルまたは特定の *ポイント・インタイム* までを再生することにより、PostgreSQLクラスターを作成します - ``pg_basebackup`` ストリーミングレプリケーションプロトコルを介して\ ``pg_basebackup`` を使用して、同じメジャーバージョンの既存のクローンを作成することにより、PostgreSQLクラスターを作成します。Kubernetesの外部からでもデータベースをEDB CloudNativePGクラスターに移行する場合に役立ちます。 ``initdb`` 方法とは異なり、 ``recovery`` と\ ``pg_basebackup`` は両方とも別のクラスターオフラインまたはオンラインに基づいて新しいクラスターを作成し、レプリカクラスターをスピンアップするために使用できます。どちらも外部クラスターの定義に依存します。 EDB CloudNativePG クラスターオペレーターが提供するバックアップストレージの組み合わせがいくつかあることを考慮して、各方法のガイダンスについては :ref:`バックアップ リカバリー <バックアップ リカバリー>` を参照してください。 .. Seealso:: :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つのブートストラップ方法のいずれかを選択できます。 さらに、 ``pg_basebackup`` または完全な\ ``recovery`` ポイントインタイムの場合、クラスターはレプリカクラスターモードの資格があります。これは、クラスターがストリーミングを介して、PostgreSQLの\ ``restore_command`` を介したWALシッピングを介して、または2つのいずれかを介してソースから継続的にフィードされることを意味します。 .. Seealso:: :ref:`"API reference for the `externalClusters` section ` を参照してください。 詳細については、 パスワードファイル ^^^^^^^^^^^^^^^^^^ ``externalClusters`` エントリー内でパスワードが指定されるたび、EDB CloudNativePGクラスターは `PostgreSQL password file `_ を自律的に管理します その場合、各インスタンスの\ ``/controller/external/NAME/pgpass`` にあります。 このアプローチにより、EDB CloudNativePGクラスターは、接続文字列でパスワードを公開せずに、外部サーバーとの接続を安全に確立できます。代わりに、接続は\ ``passfile`` 接続パラメーターを介して前述のファイルを安全に参照します。 空のクラスターをブートストラップする ``initdb`` ----------------------------------------------- ``initdb`` ブートストラップ方法は、新しいPostgreSQLクラスターをスクラッチから作成するために使用されます。特に指定しない限り、デフォルトのものです。 次の例には、\ ``initdb`` 構成の完全な構造が含まれています。 .. code:: yaml 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 上記のブートストラップの例では、次のことを行います。 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 アプリケーションデータベースは、アプリケーションデータを保存するために使用するデータベースです。アプリケーションは、アプリケーションデータベースを所有するユーザーでクラスターに接続する必要があります。 .. Important:: 追加のユーザーを作成する必要がある場合は、 :ref:`Declarative database role management ` を参照してください。 データベース名を指定しない場合、オペレーターは慣例に従って\ ``app`` データベースを作成し、 *デフォルトのWebhook* を使用してクラスター定義に追加します。データベースを所有するユーザーは、代わりにデータベース名をデフォルトにします。 アプリケーションユーザーは、オペレーターによって内部的に使用されず、代わりにスーパーユーザーに依存して、クラスターを目的のステータスに調整します。 ``initdb`` にオプションを渡す ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ PostgreSQLデータディレクトリは、 `initdb `_ を使用して初期化されます。 EDB CloudNativePGクラスターを使用すると、\ ``initdb`` の動作をカスタマイズ、デフォルトのロケール構成やデータチェックサムなどの設定を変更できます。 .. Warning:: PostgreSQLのロケールサポートの進行中の重要な機能強化により、EDB CloudNativePGクラスターは、ロケール関連オプションの`initdb` への直接プロキシとしてのみ機能します。 PostgreSQLドキュメントに従って、正しいオプションが提供されていることを確認し、ブートストラッププロセスが正常に完了したことを確認するのはあなたの責任です。 ``initdb`` コマンドにカスタムオプションを含めるには、次のパラメーターを使用できます。 builtinLocale ``builtinLocale`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--builtin-locale`` オプションに渡します。このオプションは、 `Locale Support `_ で定義された組み込みロケールを制御します PostgreSQLドキュメントからデフォルト空このオプションでは、 ``localeProvider`` を\ ``builtin`` に設定する必要があることに注意してください。 PostgreSQL 17から利用できます。 dataChecksums ``dataChecksums`` が\ ``true`` に設定されている場合、EDB CloudNativePGクラスターは\ ``initdb`` の\ ``-k`` オプションを呼び出して、データページのチェックサムを有効にし、I/Oシステムによる破損の検出に役立ちます。それ以外の場合はサイレントデフォルト\ ``false`` 。 enabled ``encoding`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--encoding`` オプションに渡します。これはテンプレートデータベースデフォルト\ ``UTF8`` のエンコードを選択します。 icuLocale ``icuLocale`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--icu-locale`` オプションに渡します。このオプションは、 `Locale Support `_ で定義されたICUロケールを制御します PostgreSQLドキュメントからデフォルト空このオプションでは、 ``localeProvider`` を\ ``icu`` に設定する必要があることに注意してください。 PostgreSQL 15から利用できます。 icuRules ``icuRules`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--icu-rules`` オプションに渡します。このオプションは、 PostgreSQLドキュメントデフォルト空の `Locale Support `_ で定義されたICUロケールを制御します。このオプションでは、 ``localeProvider`` を\ ``icu`` に設定する必要があることに注意してください。 PostgreSQL 16から利用できます。 locale ``locale`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--locale`` オプションに渡します。このオプションは、PostgreSQLドキュメントの `Locale Support `_ で定義されているロケールを制御します。デフォルトでは、localeパラメーターは空です。この場合、\ ``LANG`` などの環境変数はロケールを決定するために使用されます。これらの変数はコンテナイメージごとに異なる場合があり、一貫性のない動作が発生する可能性があることに注意してください。 localeCollate ``localeCollate`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--lc-collate`` オプションに渡します。このオプションは、 `Locale Support `_ で定義されているように、照合順序\ ``LC_COLLATE`` サブカテゴリを制御します PostgreSQLドキュメントデフォルト\ ``C`` より。 localeCType ``localeCType`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--lc-ctype`` オプションに渡します。このオプションは、 `Locale Support `_ で定義されているように、照合順序\ ``LC_CTYPE`` サブカテゴリを制御します PostgreSQLドキュメントデフォルト\ ``C`` より。 localeProvider ``localeProvider`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--locale-provider`` オプションに渡します。このオプションは、 PostgreSQLドキュメントの `Locale Support `_ デフォルト空、PostgreSQLの\ ``libc`` を意味しますの `Locale Support `_ で定義されたロケールプロバイダーを制御します。 PostgreSQL 15から利用できます。 walSegmentSize ``walSegmentSize`` が値に設定されている場合、EDB CloudNativePGクラスターはそれを\ ``initdb`` の\ ``--wal-segsize`` オプションに渡しますデフォルト未設定-16メガバイトとしてPostgreSQLによって定義されています。 .. Note:: `initdb` ブートストラップ中にEDB CloudNativePGクラスターが実装する2つの唯一のロケールオプションは、 `LC_COLLATE` および`LC_TYPE` サブカテゴリーを参照します。残りのロケールサブカテゴリは、 `lc_messages` 、`lc_monetary` 、`lc_numeric` 、および`lc_time` パラメーターを使用して、PostgreSQL構成で直接構成できます。 次の例は、データのチェックサムを有効にし、デフォルトのエンコードを\ ``LATIN1`` に設定します。 .. code:: yaml 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 .. Warning:: EDB CloudNativePGクラスターは、 `options` サブセクションを使用して、`initdb` 呼び出しの動作をカスタマイズする別の方法をサポートしています。ただし、オペレーターの動作を壊す可能性のあるオプション`--auth` や`-d` などがあることを考えると、このテクニックは非推奨であり、APIの将来のバージョンから削除されます。 初期化後のクエリの実行 ^^^^^^^^^^^^^^^^^^^^^^ クラスターが作成および構成された直後に、1回実行されるクエリのカスタムリストを指定できます。これらのクエリーは、3つの異なるデータベースに対して *スーパーユーザー* ``postgres`` として、次の特定の順序で実行されます。 1. ``postgres`` データベース ``postInit`` セクション 2. ``template1`` データベース ``postInitTemplate`` セクション 3. アプリケーションデータベース ``postInitApplication`` セクション EDB CloudNativePG クラスターは、これらのセクションごとに、次の順序で実行されるカスタムクエリを指定する2つの方法を提供します。 - クラスターの定義\ ``postInitSQL`` 、\ ``postInitTemplateSQL`` 、および\ ``postInitApplicationSQL`` スタンザ内のSQLクエリーのリストとして - シークレットおよび/またはConfigMapのリストとして、それぞれに実行されるSQLスクリプト\ ``postInitSQLRefs`` 、\ ``postInitTemplateSQLRefs`` 、および\ ``postInitApplicationSQLRefs`` スタンザが含まれます。シークレットはConfigMapの前に処理されます。 各リストのオブジェクトはシークエンシャルに処理されます。 .. Warning:: クエリーはスーパーユーザーとして実行され、クラスター全体を中断する可能性があるため、 `postInit` 、`postInitTemplate` 、および`postInitApplication` オプションを使用する際には細心の注意を払ってください。これらのクエリのエラーはブートストラップフェーズを中断し、クラスターが不完全なままとなり、手動介入が必要になります。 .. Important:: `postInitSQLRefs` 、`postInitTemplateSQLRefs` 、および`postInitApplicationSQLRefs` で指定されたConfigMapsまたはSecrets内のエントリの存在を確認します。それ以外の場合、ブートストラップは失敗します。これらのSQLファイルにエラーがあると、ブートストラップフェーズが正常に完了できません。 次の例では、\ ``postInitSQL`` スタンザの一部として単一のSQLクエリーを実行します。 .. code:: yaml 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を指定します。 .. code:: yaml 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 .. Note:: SQLスクリプト内では、各SQLステートメントは `PostgreSQL semantics `_ に従ってサーバーで1回のexecで実行されます。コメントを含めることはできますが、 `psql` のような内部コマンドは含めることができません。 互換性機能 ^^^^^^^^^^ EDB Postgres Advancedは、プレーンコミュニティPostgreSQLに多くの互換性機能を追加します。これに関する詳細については、 `EDB Postgres Advanced `_ を参照してください。 これらの機能は、EPASでのクラスターの作成中に既に有効になっており、コミュニティPostgreSQLイメージではサポートされていません。それらを無効にするには、次の例のように ``initdb`` セクションで\ ``redwood`` フラグを使用できます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-example-initdb spec: instances: 3 imageName: licenseKey: bootstrap: initdb: database: app owner: app redwood: false storage: size: 1Gi .. Important:: EDB Postgres Advancedを起動するには、有効なライセンスキートライアルまたはプロダクションが必要です。 別のクラスターからのブートストラップ ------------------------------------ EDB CloudNativePG クラスターは、同じメジャーバージョンの別のクラスターから開始するクラスターのブートストラップを有効にします。この操作は、ストリーミングレプリケーション\ ``pg_basebackup`` を介してソースクラスターに直接接続することにより、または既存の物理的な *ベースバックアップ* ``recovery`` を介して間接的に接続することにより発生します。 ソースクラスターは、 ``name`` で識別される\ ``externalClusters`` セクションで定義する必要があります。オリジンクラスターと同じ\ ``name`` を使用することをお勧めします。 .. Important:: デフォルトでは、 `recovery` メソッドは`externalClusters` セクションのクラスターの`name` を厳密に使用して、通常サーバーの名前に予約されているオブジェクトストア内のバックアップデータのメインフォルダーを見つけます。 `barmanObjectStore.serverName` プロパティデフォルトで、外部クラスター定義の`name` の値に割り当てられますを使用して、別のプロパティを指定できます。 バックアップからのブートストラップ ``recovery`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ EDB CloudNativePG クラスターオペレーターがバックアップとリカバリーの面で提供するいくつかの可能性、方法、および組み合わせを考慮して、 :ref:`バックアップ リカバリー <バックアップ リカバリー>` を参照してください。 ライブクラスターからのブートストラップ ``pg_basebackup`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pg_basebackup`` ブートストラップモードでは、有効な *ストリーミングを使用して、EDB CloudNativePGクラスターによって管理される既存の* **バイナリ互換** *PostgreSQLインスタンス* ソース *の正確な物理コピーとして、新しいクラスター* ターゲット *を作成できます。ストリーミングレプリケーション* 接続。ソースインスタンスは、プライマリまたはスタンバイのPostgreSQLサーバーのいずれかです。 PostgreSQLの物理レプリケーションの長所と短所が完全に適用されるため、以下の要件セクションを完全に確認することが重要です。 この方法の主な使用例には次のものが含まれます。 - 定期的に(毎日、毎週)再生成する必要があるレポートおよびビジネスインテリジェンスクラスター - 定期的な再生毎日、毎週、毎月、匿名化が必要なライブデータを含むテストデータベース - スタンドアロンレプリカクラスターの迅速なスピンアップ - EDB CloudNativePG Clusterクラスターの別の名前空間またはKubernetesクラスターへの物理的な移行 .. Important:: すべての要件が満たされ、操作が徹底的にテストされたことを完全に確信している場合を除き、物理的レプリケーションに基づくこの方法を使用して、Kubernetesの外部の既存のPostgreSQLクラスターをEDB CloudNativePGクラスターに移行することは避けてください。 EDB CloudNativePG クラスターコミュニティは、このようなユースケースについてこのアプローチを承認しておらず、代わりに論理インポートを使用することをお勧めします。 EDB CloudNativePGクラスターとシームレスに動作する方法で、物理レプリケーションのすべての要件が満たされることは、非常にまれです。 .. Warning:: 現在の実装では、このメソッドはソースPostgreSQLインスタンスのクローンを作成し、それにより*スナップショット*を作成します。クローン作成プロセスが完了すると、新しいクラスターがすぐに起動されます。詳細については、 :ref:`現在の制限 <現在の制限>` を参照してください。 ``recovery`` ブートストラップ方法と同様、クローン操作が完了すると、オペレーターは最初のインスタンスからターゲットクラスターの完全な所有権を取得します。これには、EDB CloudNativePGクラスターの必要に応じて特定の構成パラメーターのオーバーライド、スーパーユーザーパスワードのリセット、\ ``streaming_replica`` ユーザーの作成、レプリカの管理などが含まれます。結果のクラスターは、ソースインスタンスから独立して動作します。 .. Important:: ターゲットインスタンスとソースインスタンス間のネットワーク接続の構成は、特定のコンテキストと環境に大きく依存するため、EDB CloudNativePG クラスタードキュメントの範囲外です。 ``pg_basebackup`` によって透過的に管理されるターゲットインスタンス上のストリーミングレプリケーションクライアントは、次のいずれかの方法を使用してソースインスタンスで認証できます。 1. :ref:`ユーザー名/パスワードの認証 <ユーザー名/パスワードの認証>` 2. :ref:`TLS client certificate <#tls-certificate-authentication>` 両方の認証方法について以下に詳しく説明します。 要件 ^^^^ ``pg_basebackup`` ブートストラップ方法には、次の要件が適用されます。 - ターゲットとソースは同じハードウェアアーキテクチャである必要があります - ターゲットとソースは同じメジャーPostgreSQLバージョンである必要があります - ターゲットとソースは同じテーブルスペースを持つ必要があります - バックアップ用に少なくとも1つの *walsender* とWALストリーミング用に1つを提供することにより、この一回限りのオペレーションのターゲットからのアクセスを許可するために、十分な\ ``max_wal_senders`` でソースを構成する必要があります - ターゲットインスタンスがソースインスタンスのPostgreSQLポートに接続できるように、ソースとターゲット間のネットワークを構成する必要があります - ソースには\ ``REPLICATION LOGIN`` 特権を持つロールが必要で、\ ``pg_hba.conf`` でこのロールのターゲットインスタンスからの接続を受け入れる必要があります、できればTLSを介して 下記の :ref:`レプリケーションユーザーについて <レプリケーションユーザーについて>` を参照してください - ターゲットは、\ ``REPLICATION LOGIN`` 特権を持つロールを使用してソースPostgreSQLインスタンスに正常に接続できる必要があります .. Seealso:: 詳細については、 `Planning `_ 、 `pg_basebackup `_ を参照してください。 `High Availability, Load Balancing, and Replication `_ PostgreSQLドキュメント。 レプリケーションユーザーについて ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 要件セクションで説明したように、ソースインスタンスに\ ``SUPERUSER`` または、できれば\ ``REPLICATION`` 特権のみを持つユーザーが必要です。 ソースデータベースがEDB CloudNativePGクラスターで作成されている場合、 ``streaming_replica`` ユーザーを再利用し、クライアントTLS証明書認証を利用できます。デフォルトでは、\ ``streaming_replica`` に許可される唯一の接続方法です。 Kubernetesの外部を含む他のすべての場合、 ``REPLICATION`` 特権を持つユーザーが既に存在することを確認するか、以下の手順に従って新しいユーザーを作成してください。 ソースシステムの\ ``postgres`` ユーザーとして、次を実行してください。 .. code:: console createuser -P --replication streaming_replica ターゲットインスタンスのシークレットに追加する必要があるため、プロンプトにパスワードを入力し、後で保存します。 .. Note:: 名前は重要ではありませんが、簡単にするために`streaming_replica` を使用します。以下のセクションの指示を調整する場合、必要に応じて変更してください。 ユーザー名/パスワードの認証 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``pg_basebackup`` ブートストラップを使用してEDB 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.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: target-db spec: instances: 3 imageName: quay.io/enterprisedb/postgresql:17.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バージョンこの場合は17.2を含むすべての要件を満たす必要があります。 TLS証明書認証 ^^^^^^^^^^^^^ ``pg_basebackup`` ブートストラップを使用してEDB CloudNativePGクラスターでサポートされている2番目の認証方法は、TLSクライアント証明書に基づいています。これは、セキュリティの観点から推奨されるアプローチです。 次の例では、同じKubernetesクラスター内の既存のPostgreSQLクラスター\ ``cluster-example`` のクローンを作成します。 .. Note:: この例は、Kubernetesクラスターの外部にあるインスタンスをカバーするように簡単に適合できます。 マニフェストは、 ``cluster-clone-tls`` と呼ばれる新しいPostgreSQL 17.2クラスターを定義します。これは、 ``cluster-example`` 外部クラスターから\ ``pg_basebackup`` メソッドを使用してブートストラップされます。ホストは同じクラスター内の読み取り/書き込みサービスによって識別され、 ``streaming_replica`` ユーザーは、提供されたキー、証明書、および認証局情報それぞれ\ ``cluster-example-replication`` および\ ``cluster-example-ca`` シークレットのおかげで認証されます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-clone-tls spec: instances: 3 imageName: quay.io/enterprisedb/postgresql:17.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 アプリケーションデータベースの構成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ また、\ ``initdb`` および\ ``recovery`` ブートストラップ方法の場合と同様に、ライブクラスターからブートストラップするクラスターのアプリケーションデータベースの構成もサポートしています。新しいクラスターがレプリカクラスターとしてレプリカモードが有効化されて作成される場合、アプリケーションデータベースの構成はスキップされます。 .. Important:: `Cluster` がリカバリモードである間、カタログを含むデータベースへの変更は許可されません。この制限には、`Cluster` がプライマリに移行するまで遅延されるロールオーバーライドが含まれます。復旧フェーズでは、ロールはソースクラスターで定義されたとおりに残ります。 次の例では、ライブクラスターからブートストラップに従って、所有者\ ``app`` と提供されたシークレット\ ``app-secret`` に保存されたパスワードを使用して\ ``app`` データベースを構成します。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.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`` オプションを参照してください。 バックアップが完了すると、新しいインスタンスが新しいタイムラインで起動され、ソースから分岐します。このため、ターゲットデータベースに移行する前に、ソースデータベースへのすべての書き込み操作を停止することをお勧めします。 .. Important:: 移行を試行する前に、プロシージャとアプリケーションの両方をテストする必要があります。特に、必要なだけ移行手順を実行して、運用中のアプリケーションのダウンタイムを体系的に測定することが重要です。