PostgreSQLデータベース管理 ========================== CloudNativePGは、デフォルトで\ ``app`` という名前のアプリケーションデータベースを自動的に作成することにより、PostgreSQLデータベースのプロビジョニングを簡素化します。このデフォルトの動作については、 :ref:`空のクラスターをブートストラップする `initdb` <空のクラスターをブートストラップする `initdb`>` で説明しています セクション。 より高度なユースケースのために、CloudNativePGは **宣言的データベース管理** を導入します。これにより、ユーザーは\ ``Database`` カスタムリソース定義CRDを使用してPostgreSQLデータベースのライフサイクルを定義および制御できます。この方法はKubernetesとシームレスに統合し、PostgreSQLデータベースを管理するためのスケーラブルで自動化された一貫したアプローチを提供します。 -------------- 主要なコンセプト ---------------- 管理範囲 ^^^^^^^^ .. Important:: CloudNativePGは、データベース、ロール、テーブルスペースなどのPostgreSQLクラスターの**グローバルオブジェクト**を管理します。ただし、データベースのコンテンツスキーマやテーブルなどは管理しません。データベースのコンテンツには、専用のツールまたはアプリケーション自分自身を使用する必要があります。 宣言的な\ ``Database`` マニフェスト ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次の例は、 ``Database`` リソースが\ ``Cluster`` とどのように相互作用するかを示しています。 .. code:: yaml 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`` オブジェクトを作成します。 .. Note:: :ref:`APIリファレンス ` を参照してください。 各\ ``Database`` オブジェクトに定義できる属性の完全なリスト。 ``Database`` マニフェストの必須フィールド ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - ``metadata.name`` 名前空間内のKubernetesオブジェクトの一意の名前。 - ``spec.name`` PostgreSQLに表示されるデータベースの名前。 - ``spec.owner`` データベースを所有するPostgreSQLロール。 - ``spec.cluster.name`` ターゲットPostgreSQLクラスターの名前。 ``Database`` オブジェクトは特定の\ ``Cluster`` を参照し、データベースを作成する場所を決定する必要があります。クラスターのプライマリインスタンスによって管理され、データベースが必要に応じて作成または更新されます。 .. Note:: `metadata.name` と`spec.name` の違いにより、複数の`Database` リソースは、同じKubernetes名前空間内の異なるCloudNativePGクラスターにわたって同じ名前のデータベースを参照できます。 予約されたデータベース名 ------------------------ PostgreSQLは、 ``postgres`` 、\ ``template0`` 、\ ``template1`` などのデータベースを自動的に作成します。これらの名前は予約されており、CloudNativePGの新しい\ ``Database`` オブジェクトに使用できません。 .. Important:: `spec.name` を`postgres` 、`template0` 、または`template1` に設定して`Database` を作成することはできません。 調整とステータス ---------------- ``Database`` オブジェクトが正常にリコンサイルされると、 - ``status.applied`` は\ ``true`` に設定されます。 - ``status.observedGeneration`` は、最後に適用された構成の\ ``metadata.generation`` と一致します。 リコンサイルされた\ ``Database`` オブジェクトの例 .. code:: yaml 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から自動的に削除されます。 例 .. code:: yaml 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`` に設定します。 .. code:: yaml 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`` によって受け入れられるオプションのサブセットです。 .. Warning:: エンコードや照合設定などの一部のフィールドは、PostgreSQLで不変です。既存のデータベースのこれらのフィールドを変更しようとすると、無視されます。 レプリカクラスター ^^^^^^^^^^^^^^^^^^ レプリカには書き込み特権がないため、レプリカクラスターで宣言されたデータベースオブジェクトは適用できません。これらのオブジェクトは、レプリカが昇格するまで保留状態のままです。 競合の解決 ^^^^^^^^^^ 同じ名前空間内の2つの\ ``Database`` オブジェクトが同じPostgreSQLデータベースつまり同一の\ ``spec.name`` および\ ``spec.cluster.name`` を管理している場合、2番目のオブジェクトは拒否されます。 ステータスメッセージの例 .. code:: yaml 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を直接変更するための柔軟性が得られます。