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 extensions: - name: bloom ensure: present 適用されると、このマニフェストは、 ``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`` クラスターから削除されることを保証します。 データベース内の拡張機能の管理 ------------------------------ .. NOTE:: 拡張機能はグローバルオブジェクトではなくデータベーススコープですが、CloudNativePGはそれらを管理するための宣言型インターフェイスを提供します。特定の拡張機能のインストールにはスーパーユーザー権限が必要になる場合があるため、このアプローチが必要です。CloudNativePGは、デフォルトで無効にすることをお勧めします。このAPIを活用することにより、ユーザーは昇格した特権を必要とせずに、スケーラブルで制御された方法で拡張機能を効率的に管理できます。 CloudNativePGは、ターゲットデータベース内のPostgreSQL拡張機能の管理を簡素化および自動化します。 この機能を有効にするには、次の例に示すように、拡張仕様のリストを使用して\ ``spec.extensions`` フィールドを定義します。 .. code:: yaml # ... spec: extensions: - name: bloom ensure: present # ... 各拡張エントリは、次のプロパティをサポートしています。 - ``name`` *必須* 拡張機能の名前。 - ``ensure`` 拡張機能がデータベースに存在するかどうかを指定します。 - ``present`` 拡張機能がインストールされていることを確認しますデフォルト - ``absent`` 拡張機能が削除されたことを確認します。 - ``version`` インストールまたはアップグレードする拡張機能の特定のバージョン。 - ``schema`` 拡張機能をインストールするスキーマ。 .. NOTE:: CloudNativePGは、次のPostgreSQLのSQLコマンドを使用して拡張機能を管理します。 `CREATE EXTENSION `_ 、 `DROP EXTENSION `_ 、 `ALTER EXTENSION `_ ``UPDATE TO`` および\ ``SET SCHEMA`` に限定します。 オペレーターは、\ ``spec.extensions`` に明示的にリストされている拡張子のみをリコンサイルします。このリストで指定されていない既存の拡張子は変更されないままです。 .. Warning:: 宣言的拡張機能管理を導入する前、CloudNativePGは、構成から拡張機能を作成する簡単な方法を提供していません。これに対処するために、 :ref:`マネージド拡張機能 <マネージド拡張機能>` 機能が導入され、\ ``pg_stat_statements`` のような主要な拡張機能の自動かつ透過的な管理が可能になります。現在、\ ``Database`` CRDの拡張機能サポートと管理対象拡張機能の間で競合がないことを確認するのはあなたの責任です。 データベースでのスキーマの管理 ------------------------------ .. NOTE:: PostgreSQLのスキーマ管理は、グローバルオブジェクトの管理に対するCloudNativePGの主な焦点の例外です。スキーマはデータベース内に存在するため、通常はアプリケーション開発プロセスの一部として管理されます。ただし、CloudNativePGは、主にスキーマ内での拡張機能の展開のサポートを完了するために、スキーマ管理の宣言的インターフェイスを提供します。 CloudNativePGは、ターゲットデータベース内のPostgreSQLスキーマの管理を簡素化および自動化します。 この機能を有効にするには、次の例に示すように、スキーマ仕様のリストを使用して\ ``spec.schemas`` フィールドを定義します。 .. code:: yaml # ... spec: schemas: - name: app owner: app # ... 各スキーマエントリは、次のプロパティをサポートしています。 - ``name`` *(必須)* スキーマの名前。 - ``owner`` スキーマの所有者。 - ``ensure`` データベースにスキーマが存在するかどうかを指定します。 - ``present`` スキーマがインストールされていることを確認しますデフォルト。 - ``absent`` スキーマが削除されたことを確認します。 .. NOTE:: CloudNativePGは、 PostgreSQLのSQLコマンド `CREATE SCHEMA `_ 、 `DROP SCHEMA `_ 、 `ALTER SCHEMA `_ を使用してスキーマを管理します。 制限と注意事項 -------------- データベースの名前の変更 ^^^^^^^^^^^^^^^^^^^^^^^^ 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を直接変更するための柔軟性が得られます。