Tablespaces =========== テーブルスペースは、データベース管理システムで堅牢で広く採用されている機能です。データの物理的および論理モデリングを分離することにより、データベースの垂直スケーラビリティを強化する強力な手段を提供します。基本的に、これは物理データベースモデリングの技術として機能し、個別のストレージ上のマルチプルのボリューム全体にI/O操作を効率的に分散できます。これにより、並列ディスク上の読み取り/書き込み操作を介してパフォーマンスが最適化されます。 データベース業界のコンテキストでは、テーブルスペースは、特に論理データベースモデリング技術であるテーブルパーティショニングと組み合わせた場合、戦略的な役割を果たします。これらは大規模なデータベースの管理に役立つことが証明されており、インデックスからテーブルを分離したり、一時的な操作を実行したりするようなタスクにも使用されます。 PostgreSQLのテーブルスペースは、2005バージョン8.0から重要な役割を果たしていますが、宣言的パーティショニングは2017バージョン10に導入されました。その結果、テーブルスペースは、サポートされているPostgreSQLのすべてのリリースにシームレスに統合されています。 :ref:`PostgreSQL documentation on tablespaces ` からの引用 テーブルスペースを使用することにより、管理者はPostgreSQLインストールのディスクレイアウトを制御できます。これは、少なくとも2つの方法で役立ちます。 > > - まず、クラスターが初期化されたパーティションまたはボリュームが領域不足で実行され、拡張できない場合、別のパーティションにテーブルスペースを作成し、システムが再構成できるまで使用できます。 > - 第二に、テーブルスペースにより、管理者はデータベースオブジェクトの使用パターンに関する知識を使用して、パフォーマンスを最適化できます。 宣言的テーブルスペース ---------------------- EDB CloudNativePGクラスターは、2つの異なるレベルで動作する *宣言テーブルスペース* を介してPostgreSQLテーブルスペースのサポートを提供します。 - Kubernetes、PGDATAおよびWALボリュームが処理される方法と同じように、永続ボリューム要求を管理します - PostgreSQL、 PostgreSQLインスタンスで\ ``TABLESPACE`` グローバルオブジェクトを管理する Kubernetesエコシステムの一部であるため、EDB CloudNativePG クラスターの宣言的テーブルスペースは、永続ボリューム要求および永続ボリュームを活用して実装されます。クラスターで定義された各テーブルスペースは、独自の永続ボリュームに格納されます。 EDB CloudNativePG クラスターは、PVCの生成を担当します。正規化された場所のインスタンスポッドに必要なボリュームをマウントし、プライマリでアクティブにする前にレプリカがテーブルスペースをサポートする準備ができていることを確認します。 要求されたときにストレージが利用可能な場合、クラスターの作成時にテーブルスペースを設定するか、後で追加できます。現在、それらを削除することはできません。ただし、この制限はEDB CloudNativePG クラスターの将来のマイナーまたはパッチバージョンで対応される予定です。 宣言的テーブルスペースの使用 ---------------------------- 宣言的テーブルスペースの使用は簡単です。以下に完全な例を見つけることができます。 :: apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-example-with-tablespaces spec: instances: 3 storage: size: 1Gi tablespaces: - name: atablespace storage: size: 1Gi storageClass: standard temporary: true - name: another_tablespace storage: size: 2Gi storageClass: standard temporary: true - name: tablespacea1 storage: size: 2Gi storageClass: standard これらを使用するには、新しいまたは既存の\ ``Cluster`` リソースで新しい\ ``tablespaces`` スタンザを使用します。 .. code:: yaml spec: instances: 3 # ... tablespaces: - name: tbs1 storage: size: 1Gi - name: tbs2 storage: size: 2Gi - name: tbs3 storage: size: 2Gi 各テーブルスペースには、生成されたPVCのサイズとストレージクラスを構成できる独自のストレージセクションがあります。したがって、管理者は、 :ref:`ストレージクラスとテーブルスペース <ストレージクラスとテーブルスペース>` で説明しているように、さまざまな種類のワークロードに異なるストレージクラスの使用を計画できます。 EDB CloudNativePGクラスターは、高可用性Postgresクラスター内の各インスタンスの永続ボリューム要求を作成します。プロビジョニングが完了すると、各ポッドにマウントします。次に、 ``CREATE TABLESPACE`` コマンドを使用してプライマリPostgreSQLインスタンスに\ ``tbs1`` 、\ ``tbs2`` 、および\ ``tbs3`` 表領域が作成されることを確認します。このプロセスは迅速で、これはPostgresに反映されます。 .. code:: txt app=# SELECT oid, spcname FROM pg_tablespace; oid | spcname - ------+-------------------- 1663 | pg_default 1664 | pg_global 16387 | tbs1 16388 | tbs2 16389 | tbs3 (5 rows) すぐに使用を開始できます。 .. code:: txt app=# CREATE TABLE fibonacci(num INTEGER) TABLESPACE tbs1; CREATE TABLE クラスターステータスには、テーブルスペースのセクションがあります。 .. code:: yaml status: <- snipped -> tablespacesStatus: - name: atablespace state: reconciled - name: another_tablespace state: reconciled - name: tablespacea1 state: reconciled ストレージクラスとテーブルスペース ---------------------------------- PGDATAおよびWALボリュームと同じように、テーブルスペースにさまざまなストレージクラスを使用できます。これは、リソースを最適化し、データアクセスの使用量と予想に基づいてストレージのパフォーマンスとコストのバランスを保つ便利な方法です。 この例は、機能を説明するのに役立ちます。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: yardbirds spec: instances: 3 storage: size: 10Gi walStorage: size: 10Gi tablespaces: - name: current size: 100Gi storageClass: fastest - name: this_year size: 500Gi storageClass: balanced ``yardbirds`` クラスター例は、3つの異なるストレージクラスを使用して4つの永続ボリューム要求を要求します。 - デフォルトのストレージクラス – ``PGDATA`` およびWALボリュームによって使用されます。 - ``fastest`` – ``current`` テーブルスペースによって使用され、データベースで最もアクティブで要求の高いデータセットを保存します。 - ``balanced`` – ``this_year`` 表領域によって使用され、ユーザーがほとんどアクセスせず、パフォーマンスの期待が最も高くないデータの古いパーティションを保存します。 次に、ホリゾンタルテーブルパーティショニングを利用して、\ ``current`` 表領域に当月のテーブル2023年12月のファクトなどを作成できます。 .. code:: sql CREATE TABLE facts_202312 PARTITION OF facts FOR VALUES FROM (2023-12-01) TO (2024-01-01) TABLESPACE current; .. Important:: この例では、 `PostgreSQL declarative partitioning `_ に精通していることを前提としています。 テーブルスペースの所有権 ------------------------ デフォルトでは、特に指定しない限り、表領域は ``.spec.bootstrap.initdb.owner`` で定義されているように、\ ``app`` アプリケーションユーザーが所有します。詳細は、 :ref:`Bootstrap a new cluster ` を参照してください。このデフォルトの動作は、ほとんどのマイクロサービスデータベースのユースケースで動作します。 次の抜粋のように、 ``owner`` スタンザで表領域の所有者、たとえば ``postgres`` ユーザーを設定できます。 .. code:: yaml # ... tablespaces: - name: clapton owner: name: postgres storage: size: 1Gi .. Important:: 表領域の所有権を変更する場合は、既存のロールを使用していることを確認します。それ以外の場合、クラスターのステータスが問題を報告し、修正されるまでテーブルスペースのリコンサイルを停止します。ステータスとログを監視し、問題を修正して迅速に介入するのはあなたの責任です。 存在しない所有者でテーブルスペースを定義すると、EDB CloudNativePGクラスターはテーブルスペースを作成できず、これをクラスターステータスに反映します。 .. code:: yaml spec: instances: 3 # ... tablespaces: - name: tbs1 storage: size: 1Gi - name: tbs2 storage: size: 2Gi - name: tbs3 owner: name: badhombre storage: size: 2Gi status: <- snipped -> tablespacesStatus: - name: tbs1 status: reconciled - name: tbs2 status: reconciled - error: while creating tablespace tbs3: ERROR: role "badhombre" does not exist (SQLSTATE 42704) name: tbs3 status: pending バックアップ リカバリー ----------------------- EDB CloudNativePGクラスターは、オブジェクトストアとボリュームスナップショットの両方でテーブルスペースおよび相対テーブルスペースマップのバックアップを処理します。 .. Warning:: デフォルトでは、バックアップはレプリカノードから取得されます。クラスターで表領域を作成した直後にバックアップを作成すると、レプリカからの表領域の不完全なビュー、したがって不完全なバックアップが生成される場合があります。遅延は、次の調整で最大5分で解決されます。 テーブルスペースを含むクラスターにベースバックアップがあると、そこから新しいクラスターを復元できます。復旧側については、復旧したデータベースの\ ``Cluster`` 定義に表領域の正確なリストが含まれていることを確認するのは自分の責任です。 レプリカクラスター ------------------ レプリカクラスターには、オリジンと同じ表領域定義が必要です。その理由は、 ``CREATE TABLESPACE`` のようなテーブルスペース管理コマンドはWALログに記録され、物理レプリケーションクライアントストリーミングまたはWALシッピング経由で再生されるためです。 レプリカクラスターに同じ名前のテーブルスペースの同じリストがあることを確認するのはあなたの責任です。ストレージクラスとサイズは異なる場合があります。 例 .. code:: yaml spec: # ... bootstrap: recovery: # ... your selected recovery method tablespaces: - name: tbs1 storage: size: 1Gi - name: tbs2 storage: size: 2Gi - name: tbs3 storage: size: 2Gi 一時テーブルスペース -------------------- PostgreSQLでは、1つ以上の一時表領域を定義して、 ``CREATE`` コマンドが明示的に表領域を指定しない場合に、一時オブジェクト一時テーブルと一時テーブルのインデックスを作成したり、大規模なデータセットのソートなどの目的で一時ファイルを作成したりできます。一時表領域が指定されない場合、PostgreSQLは、現在メインの\ ``PGDATA`` ボリュームであるデータベースのデフォルトの表領域を使用します。 複数の一時テーブルスペースを指定すると、PostgreSQLは、トランザクションで最初に一時オブジェクトを作成する必要があるときにランダムに1つを選択します。次に、リストを順番に反復します。 一時テーブルスペースは、バックアップに関して通常のテーブルスペースと同様に動作します。 EDB CloudNativePGクラスターは、 ``temp_tablespaces`` PostgreSQLパラメーターにテーブルスペースを追加するかどうかを決定する\ ``.spec.tablespaces[*].temporary`` オプションを提供し、明示的なテーブルスペースの割り当てがない一時データを保存できるようになります。 .. code:: yaml spec: [...] tablespaces: - name: atablespace storage: size: 1Gi temporary: true これらは初期化時に作成するか、後で追加できますが、ローリング更新が必要です。 ``temporary: true/false`` オプションは、 ``temp_tablespaces`` オプションの表領域のリストに表領域名を追加または削除します。この変更では、PostgreSQLの再起動は必要ありません。 一時表領域は通常の表領域として機能することもできますが、ユーザーが一時的な操作に使用しながら通常のデータをホストすることもできますが、2つのワークロードを混合しないことをお勧めします。 `PostgreSQL documentation on `temp_tablespaces` `_ を参照してください。 詳細については。 kubectlプラグインのサポート --------------------------- :ref:`kubectl status ` プラグインには、表領域のステータス、所有者、一時フラグ、エラーなどの便利な概要を提供する表領域専用のセクションが含まれています。 .. code:: yaml [...] Tablespaces status Tablespace Owner Status Temporary Error - --------- ----- ------ --------- ----- atablespace app reconciled true another_tablespace app reconciled true tablespacea1 app reconciled false Instances status [...] 制限事項 -------- 現在、既存のEDB CloudNativePG Clusterクラスターからテーブルスペースを削除することはできません。