ブートストラップ¶

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

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

initdb ブートストラップは、Kubernetesの外部であっても、既存のPostgresクラスターから1つ以上のデータベースをインポートし、Postgresの異なるメジャーバージョンを使用する可能性も提供します。この機能の詳細については、

Postgresデータベースのインポートセクションを参照してください。

重要

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

警告

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に移行する場合に役立ちます。Kubernetesの外部からでも。

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

詳細については。

`externalClusters` セクション¶

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

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

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

注釈

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

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

さらに、 pg_basebackup または完全なrecovery 時点）の場合、クラスターはレプリカクラスターモードに適格です。これは、クラスターが、ストリーミング、PostgreSQLのrestore_command を介したWALシッピング、またはその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 フォルダーを作成します
superuser-secret という名前のシークレットからpostgres スーパーユーザー のパスワードを設定します
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

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

重要

オペレーターの将来の実装では、宣言的な構成方法で追加のユーザーを作成できるようになるかもしれません。

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

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

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

重要

今のところ、スーパーユーザーシークレットの名前の変更はクラスターに適用されません。

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

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

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

localeCollate ： localeCollate が値に設定されている場合、CNPGはそれを initdb の--lc-collate オプションに渡します。このオプションは、

Locale Support で定義されているように、照合順序（LC_COLLATE

サブカテゴリ）を制御します

PostgreSQLのドキュメントから（デフォルト：C ）。

localeCType ： localeCType が値に設定されている場合、CNPGはそれをinitdb の--lc-ctype オプションに渡します。このオプションは、

Locale Support で定義されているように、照合順序（LC_CTYPE

サブカテゴリ）を制御します

PostgreSQLのドキュメントから（デフォルト：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の将来のバージョンから削除されます。

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

さらに、データベースの作成および構成後に実行されるSQLスクリプトを含むSecretsおよび/またはConfigMapsのリストを指定できます。これらのSQLスクリプトは、 initdb セクションで指定されたデータベースに接続された superuser ロール（postgres ）を使用して実行されます。

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

注釈

secretRefs で参照されるSQLスクリプトは、 configMapRefs で参照されるSQLスクリプトよりも前に実行されます。両方のセクションで、 SQLスクリプトはリスト内の順序に従って実行されます。 SQLスクリプト内では、各SQLステートメントは PostgreSQL semantics に従ってサーバー上の単一のexecで実行され、コメントを含めることができますが、 psql のような内部コマンドはできません。

警告

postInitApplicationSQLRefs で指定されたConfigMapまたはSecrets内にエントリーが存在することを確認してください。そうでない場合、ブートストラップは失敗します。これらのSQLファイルのいずれかにエラーがあると、ブートストラップフェーズが正常に完了しません。

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

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

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

重要

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

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

recovery ブートストラップモードでは、既存の物理ベースバックアップから新しいクラスターを作成し、アーカイブからREDOログを含むWALファイルを再適用できます。ベースバックアップとWALファイルの両方が リカバリオブジェクトストア からプルされます。

リカバリオブジェクトストア からのリカバリは、2つの方法で実現できます。

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

どちらの回復方法も、完全な回復（利用可能な最後のWALまで）または最大: ポイントインタイムリカバリ（PITR）

のいずれかを有効にします。完全復旧を実行する場合、クラスターをレプリカモードで起動することもできます。また、回復したクラスターのPostgreSQL構成（.spec.postgresql.parameters ）が、物理レプリケーションの観点から、元の構成と互換性があることを確認してください。

注釈

バックアップとリカバリ実行中のクラスターのバックアップとリカバリの詳細については、を見つけることができます。

CloudNativePGは、Kubernetesのボリュームスナップショットのサポートも導入しています。 CloudNativePGの現在のバージョンでは、次のことができます。

kubectl cnpg snapshot コマンドを使用して、スタンバイからPostgresクラスターの一貫したコールドバックアップを取得します-必要なVolumeSnapshot オブジェクト（現在、別のボリュームにWALがある場合は1つまたは2つ）を作成します
:ref:VolumeSnapshot` オブジェクトからの回復<`VolumeSnapshot` オブジェクトからの回復>` で説明されているように、 ``.spec.bootstrap.recovery

スタンザのvolumeSnapshots オプションを介して、上記の VolumeSnapshot オブジェクトから回復します

以下

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

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` を厳密に使用して、通常サーバーの名前用に予約されているオブジェクトストア内のバックアップデータのメインフォルダーを見つけます。 barmanObjectStore.serverName プロパティで別のものを指定できます（デフォルトでは、外部クラスター定義の`name` の値に割り当てられます）。

注釈

上記の例では、並列WAL復元機能を利用して、最大8つのジョブを専用にして、アーカイブから必要なWALファイルを同時にフェッチします。この機能により、回復時間を大幅に短縮できます。このシナリオを事前に計画し、環境に合わせてこのパラメーターの値を正しく調整してください。それは確かに違いを生む **いつ**（場合ではない）必要があります。

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

クラスターを作成する必要がある名前空間でBackupリソースが既に利用可能な場合、次の例のように、 .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

このブートストラップ方法では、復元が必要なバックアップへの参照のみを指定できます。

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

CloudNativePGは、kubectl cnpg snapshot で取得された既存のCluster のPVCのVolumeSnapshot から新しいクラスターを作成できます。次の例のように、スナップショットの名前を指定する必要があります。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore
spec:
  [...]

bootstrap:
    recovery:
      volumeSnapshots:
        storage:
          name: <snapshot name>
          kind: VolumeSnapshot
          apiGroup: snapshot.storage.k8s.io

警告

Kubernetesの`VolumeSnapshot` APIの宣言的サポートの開発が進むにつれて、ポイントインタイムリカバリオペレーションまたはレプリカクラスターのWALアーカイブと組み合わせてこの手法を使用できるようになります。

バックアップされたクラスターが別のPVCを使用してWALファイルを保存していた場合、リカバリにはそれも含める必要があります。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-restore
spec:
  [...]

bootstrap:
    recovery:
      volumeSnapshots:
        storage:
          name: <snapshot name>
          kind: VolumeSnapshot
          apiGroup: snapshot.storage.k8s.io

        walStorage:
          name: <snapshot name>
          kind: VolumeSnapshot
          apiGroup: snapshot.storage.k8s.io

kubectl cnpg snapshot コマンドは、ボリュームの物理コピーを作成する前にスタンバイをフェンシングすることにより、 コールドバックアップ と呼ばれる手法を使用して、レプリカの一貫したスナップショットを作成できます。詳細は

Postgresクラスターのスナップショットを参照ください。

その他の考慮事項¶

リカバリオブジェクトストアまたは既存のBackup リソースのどちらからリカバリする場合でも、次の考慮事項が適用されます。

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

重要

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

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

最新のWALまですべてのWALをリプレイする代わりに、ベースバックアップを抽出した後、任意の時点でWALのリプレイを停止するようにPostgreSQLに依頼できます。 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 を指定するだけでよいことに気付いたかもしれません。

backupID オプションは、リカバリプロセスを開始するベースバックアップを指定できるオプションです。デフォルトでは、この値は空です。

それに値を（ BarmanバックアップIDの形式で）割り当てると、オペレーターはそのバックアップをリカバリのベースとして使用します。

重要

そのようなバックアップが存在し、アクセス可能であることを確認する必要があります。

バックアップIDが指定されていない場合、オペレーターは次のようにリカバリ用のベースバックアップを自動的に検出します。

targetTime またはtargetLSN を使用する場合、オペレーターはそのターゲットの前に完了した最も近いバックアップを選択します
それ以外の場合、オペレーターは利用可能な最新のバックアップを時系列で選択します。

使用できるリカバリターゲットの基準は次のとおりです。

targetTime ：: RFC 3339 形式で表される、回復が進行するタイムスタンプ（正確な停止ポイントは

exclusive オプションの影響も受けます）

targetXID ：リカバリが続行されるトランザクションID（正確な停止ポイントは exclusive オプションの影響も受けます）。トランザクションIDはトランザクション開始時に連続して割り当てられますが、トランザクションは異なる番号順に完了することに注意してください。回復されるトランザクションは、指定されたトランザクションの前にコミットされたトランザクションです（オプションで含めます）

targetName ：リカバリが進む名前付き復元ポイント（ pg_create_restore_point() で作成）

targetLSN ：リカバリが進むログ先行書き込みの場所のLSN（正確な停止ポイントは exclusive オプションの影響も受けます）

targetImmediate ：リカバリは、一貫性のある状態に到達次第、つまりできるだけ早く終了する必要があります。オンラインバックアップから復元する場合、これはバックアップの取得が終了した時点を意味します

重要

targetTime または`targetLSN` が指定されている場合、オペレーターは最も近いバックアップを自動的に取得できますが、これは残りのターゲット、targetName 、targetXID 、および`targetImmediate` では不可能です。このような場合、カタログ内の利用可能な最後のバックアップで問題ない場合を除き、 backupID を指定することが重要です。

以下の例では、 targetName ベースのリカバリターゲットを使用しています。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
  bootstrap:
    recovery:
      source: clusterBackup
      recoveryTarget:
        backupID: 20220616T142236
        targetName: restore_point_1
[...]

各recoveryTarget 構成で、上記のターゲットから1つだけを選択できます。

さらに、特定のタイムラインへのtargetTLI 強制リカバリを指定できます。

デフォルトでは、以前のパラメーターは包括的であると見なされ、リカバリーターゲットの直後で停止し、: the behavior in PostgreSQL に一致します

AzureのBLOBコンテナーに依存する次の例のように、 exclusive パラメーターをtrue に設定することにより、復旧ターゲットの直前で停止する排他的な動作を要求できます。

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

  storage:
    size: 5Gi

  bootstrap:
    recovery:
      source: clusterBackup
      recoveryTarget:
        backupID: 20220616T142236
        targetName: "maintenance-activity"
        exclusive: true

  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

アプリケーションデータベースを構成する¶

回復したクラスターの場合、追加の構成でアプリケーションデータベース名と資格情報を構成できます。アプリケーションデータベースの資格情報を更新するには、独自のパスワードを生成し、それらをシークレットとして保存し、シークレットを使用してデータベースを更新します。または、オペレーターに、ランダムに安全なパスワードを使用して使用するシークレットを生成させることもできます。: 空のクラスターをブートストラップする（`initdb ）<空のクラスターをブートストラップする（initdb ）>` を参照してください

シークレットの詳細については、セクションをご覧ください。

次の例では、所有者app 、指定されたシークレットapp-secret でアプリケーションデータベースapp を構成します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  bootstrap:
    recovery:
      database: app
      owner: app
      secret:
        name: app-secret
      [...]

上記の構成では、リカバリが完了した後に次のことが起こります。

1.データベースapp が存在しない場合、新しいデータベースapp が作成されます。

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

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

username の値がowner の値とシークレットに一致する場合、アプリケーションデータベースのパスワードはpassword の値にシークレットに変更されます。

重要

レプリカモードが有効になっているレプリカクラスターの場合、オペレーターはPostgreSQLインスタンスにデータベースまたはユーザーを作成しません。これらは元のクラスターからリカバリされます。

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

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

このメソッドの主なユースケースは、Kubernetesの外部またはKubernetes内（別のオペレーターなど）からCloudNativePGへの移行によって表されます。

警告

現在の実装では、クローニングプロセスが終了し、作成されたクラスターをすぐに起動すると、オリジンPostgreSQLインスタンスの*スナップショット*を作成します。詳細については、以下の現在の制限を参照してください。

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

重要

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

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

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

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

要件¶

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

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

参考

詳細については、 Planning 、ライブクラスターからのブートストラップ（`pg_basebackup ）<ライブクラスターからのブートストラップ（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

次のマニフェストは、 target-db という新しいPostgreSQL 15.3クラスターを作成します。 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:15.3

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

TLS証明書認証¶

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

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

注釈

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

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

  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-secret` のパスワードを使用してアプリケーションデータベース`app` を構成します。

```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 が存在しない場合、新しいデータベースapp が作成されます。

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

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

username の値がowner の値とシークレットに一致する場合、アプリケーションデータベースのパスワードはpassword の値にシークレットに変更されます。

重要

レプリカモードが有効になっているレプリカクラスターの場合、オペレーターはPostgreSQLインスタンスにデータベースまたはユーザーを作成しません。これらは元のクラスターからリカバリされます。

現在の制限¶

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

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

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

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

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

重要

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

ブートストラップ¶

`bootstrap` セクション¶

`externalClusters` セクション¶

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

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

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

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

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

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

その他の考慮事項¶

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

アプリケーションデータベースを構成する¶

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

要件¶

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

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

TLS証明書認証¶

現在の制限¶

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

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

前のトピックへ

次のトピックへ

目次

ブートストラップ¶

bootstrap セクション¶

externalClusters セクション¶

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

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

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

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

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

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

その他の考慮事項¶

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

アプリケーションデータベースを構成する¶

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

要件¶

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

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

TLS証明書認証¶

現在の制限¶

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

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

`bootstrap` セクション¶

`externalClusters` セクション¶

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

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

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

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

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