PostgreSQLデータベース管理

CloudNativePGは、デフォルトでapp という名前のアプリケーションデータベースを自動的に作成することにより、PostgreSQLデータベースのプロビジョニングを簡素化します。このデフォルトの動作については、 空のクラスターをブートストラップする `initdb <空のクラスターをブートストラップする initdb>` で説明しています

セクション。

より高度なユースケースのために、CloudNativePGは 宣言的データベース管理 を導入します。これにより、ユーザーはDatabase カスタムリソース定義CRDを使用してPostgreSQLデータベースのライフサイクルを定義および制御できます。この方法はKubernetesとシームレスに統合し、PostgreSQLデータベースを管理するためのスケーラブルで自動化された一貫したアプローチを提供します。

主要なコンセプト

管理範囲

重要

CloudNativePGは、データベース、ロール、テーブルスペースなどのPostgreSQLクラスターの**グローバルオブジェクト**を管理します。ただし、データベースのコンテンツスキーマやテーブルなどは管理しません。データベースのコンテンツには、専用のツールまたはアプリケーション自分自身を使用する必要があります。

宣言的なDatabase マニフェスト

次の例は、 Database リソースがCluster とどのように相互作用するかを示しています。

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: cluster-example-one
spec:
  name: one
  owner: app
  cluster:
    name: cluster-example

適用されると、このマニフェストは、 cluster-example PostgreSQLクラスター内のapp ロールが所有するone という名前のデータベースを要求するcluster-example-one と呼ばれるDatabase オブジェクトを作成します。

注釈

APIリファレンス を参照してください。

各Database オブジェクトに定義できる属性の完全なリスト。

Database マニフェストの必須フィールド

  • metadata.name 名前空間内のKubernetesオブジェクトの一意の名前。

  • spec.name PostgreSQLに表示されるデータベースの名前。

  • spec.owner データベースを所有するPostgreSQLロール。

  • spec.cluster.name ターゲットPostgreSQLクラスターの名前。

Database オブジェクトは特定のCluster を参照し、データベースを作成する場所を決定する必要があります。クラスターのプライマリインスタンスによって管理され、データベースが必要に応じて作成または更新されます。

注釈

metadata.name と`spec.name` の違いにより、複数の`Database` リソースは、同じKubernetes名前空間内の異なるCloudNativePGクラスターにわたって同じ名前のデータベースを参照できます。

予約されたデータベース名

PostgreSQLは、 postgres 、template0 、template1 などのデータベースを自動的に作成します。これらの名前は予約されており、CloudNativePGの新しいDatabase オブジェクトに使用できません。

重要

spec.name を`postgres` 、template0 、または`template1` に設定して`Database` を作成することはできません。

調整とステータス

Database オブジェクトが正常にリコンサイルされると、

  • status.applied はtrue に設定されます。

  • status.observedGeneration は、最後に適用された構成のmetadata.generation と一致します。

リコンサイルされたDatabase オブジェクトの例

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  generation: 1
  name: cluster-example-one
spec:
  cluster:
    name: cluster-example
  name: one
  owner: app
status:
  observedGeneration: 1
  applied: true

リコンシリエーション中にエラーが発生した場合、status.applied はfalse になり、エラーメッセージはstatus.message フィールドに含まれます。

データベースの削除

CloudNativePGは、データベース削除の2つの方法をサポートしています。

  1. delete 再利用ポリシーの使用

  2. データベースのensure フィールドをabsent に宣言的に設定する

delete 再利用ポリシーを介した削除

databaseReclaimPolicy フィールドは、Database オブジェクトが削除されたときの動作を決定します。

  • retain デフォルト データベースは、手動管理のためにPostgreSQLに残ります。

  • delete データベースはPostgreSQLから自動的に削除されます。

例

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: cluster-example-two
spec:
  databaseReclaimPolicy: delete
  name: two
  owner: app
  cluster:
    name: cluster-example

このDatabase オブジェクトを削除すると、cluster-example クラスターからtwo データベースが自動的に削除されます。

ensure: absent の宣言的設定

データベースを削除するには、次の例のようにensure フィールドをabsent に設定します。

apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
  name: cluster-example-database-to-drop
spec:
  cluster:
    name: cluster-example
  name: database-to-drop
  owner: app
  ensure: absent

このマニフェストは、 database-to-drop データベースがcluster-example クラスターから削除されることを保証します。

制限と注意事項

データベースの名前の変更

CloudNativePGはPostgreSQLの CREATE DATABASE および ALTER DATABASE に準拠していますが

コマンド、 データベースの名前の変更はサポートされていません 。既存のDatabase オブジェクトのspec.name を変更しようとすると、Kubernetesによって拒否されます。

データベースの作成と変更

  • 新しいデータベースの場合、CloudNativePGはCREATE DATABASE ステートメントを使用します。

  • 既存のデータベースの場合、ALTER DATABASE を使用して変更を適用します。

これら2つのPostgresコマンドにはいくつかの違いがあることに注意することが重要です。特に、ALTER によって受け入れられるオプションは、CREATE によって受け入れられるオプションのサブセットです。

警告

エンコードや照合設定などの一部のフィールドは、PostgreSQLで不変です。既存のデータベースのこれらのフィールドを変更しようとすると、無視されます。

レプリカクラスター

レプリカには書き込み特権がないため、レプリカクラスターで宣言されたデータベースオブジェクトは適用できません。これらのオブジェクトは、レプリカが昇格するまで保留状態のままです。

競合の解決

同じ名前空間内の2つのDatabase オブジェクトが同じPostgreSQLデータベースつまり同一のspec.name およびspec.cluster.name を管理している場合、2番目のオブジェクトは拒否されます。

ステータスメッセージの例

status:
  applied: false
  message: reconciliation error: database "one" is already managed by Database object "cluster-example-one"

Postgresバージョンの違い

CloudNativePGは、PostgreSQLの機能を遵守しています。たとえば、PostgreSQL 16で導入されたICU_RULES のような機能は、以前のバージョンでは使用できません。 PostgreSQLからのエラーは、Database オブジェクトのstatus に反映されます。

手動変更

CloudNativePGは、データベースへの手動変更を上書きしません。リコンサイルが完了すると、 Database オブジェクトは、 metadata.generation が変更しない限り再適用されないため、 PostgreSQLを直接変更するための柔軟性が得られます。