Postgresデータベースのインポート¶

このセクションでは、新しいCloudNativePGクラスター内に1つ以上の既存のPostgreSQLデータベースをインポートする方法について説明します。

インポート操作は、PostgreSQLのオンライン論理バックアップの概念に基づいており、オリジンホストへのネットワーク接続を介したpg_dump 、およびpg_restore に依存しています。ネイティブのマルチバージョン同時実行制御（MVCC）とスナップショットのおかげで、PostgreSQLは、書き込みアクティビティを停止することなく、ネットワークを介して同時に一貫したバックアップを作成できます。

論理バックアップは、PostgreSQLバージョンのメジャーアップグレードを実行するための最も一般的で柔軟で信頼できる手法でもあります。

その結果、このセクションの手順は、次の両方に適しています。

Kubernetesの外部であっても、既存のPostgreSQLインスタンスから1つ以上のデータベースをインポートする
任意のPostgreSQLバージョンから同じまたは新しいバージョンにデータベースをインポートし、PostgreSQLの メジャーアップグレード を有効にします（バージョン11.xからバージョン15.xなど）

警告

PostgreSQLのメジャーアップグレードを実行するときは、アプリケーションが新しいバージョンと互換性があること、およびデータベースに含まれるオブジェクト（拡張機能を含む）のアップグレードパスが実行可能であることを確認する責任があります。

どちらの場合も、操作は元のデータベースの一貫した スナップショット で実行されます。

重要

このため、 Cluster リソースでの最終インポートの前にソースでの書き込み操作を停止することをお勧めします。「オフラインインポート」または「オフラインメジャーアップグレード」として。

仕組み¶

概念的には、インポートでは BootstrapInitDB を使用して新しいクラスター（ 宛先クラスター ）を最初から作成し（ 宛先クラスター ）、 initdb.import サブセクションを完了して既存のPostgresクラスター（ ソースクラスター ）からオブジェクトをインポートする必要があります。 PostgreSQLの推奨事項に従って、 宛先クラスター のPostgreSQLメジャーバージョンは、 ソースクラスター のメジャーバージョン以上であることをお勧めします。

CloudNativePGは、ソースクラスターから宛先クラスターにオブジェクトをインポートするための2つの主な方法を提供します。

マイクロサービスアプローチ ：宛先クラスターは、CloudNativePGプロジェクトの推奨に従って、指定されたアプリケーションユーザーが所有する単一のアプリケーションデータベースをホストするように設計されています
モノリスアプローチ ：宛先クラスターは、ソースクラスターからインポートされた複数のデータベースと異なるユーザーをホストするように設計されています

最初のインポート方法はmicroservice タイプを介して利用でき、後者はmonolith タイプを介して利用できます。

警告

スーパーユーザーまたは`pg_dump` で論理バックアップを作成するための十分な特権を持つユーザーを使用して、宛先クラスターがソースクラスターにアクセスできることを保証するのはあなたの責任です。 PostgreSQL documentation on "SQL Dump" を参照してください

詳細については。

`microservice` タイプ¶

マイクロサービスアプローチでは、ソースクラスターから宛先クラスターにインポートする単一のデータベースを指定できます。操作は4つのステップで実行されます。

新しいクラスターのinitdb ブートストラップ
pg_dump -Fc を使用した選択したデータベース（initdb.import.databases 内）のエクスポート
pg_restore --no-acl --no-owner を使用したデータベースの、initdb.owner ユーザーが所有するinitdb.database （アプリケーションデータベース）へのインポート
データベースダンプファイルのクリーンアップ
postImportApplicationSQL パラメーターを介したアプリケーションデータベースでのユーザー定義SQLクエリのオプションの実行
インポートされたデータベースでのANALYZE VERBOSE の実行

たとえば、以下のYAMLは、 cluster-microservice と呼ばれる新しい3インスタンスPostgreSQLクラスター（オペレーターがリリースされた時点で利用可能な最新のメジャーバージョン）を作成します。 cluster-pg96-superuser シークレットに保存されているパスワードを介して、postgres ユーザーを使用するデータベース。

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

  bootstrap:
    initdb:
      import:
        type: microservice
        databases:
          - angus
        source:
          externalCluster: cluster-pg96
        #postImportApplicationSQL:
        #- |
        #  INSERT YOUR SQL QUERIES HERE
  storage:
    size: 1Gi
  externalClusters:
    - name: cluster-pg96
      connectionParameters:
        # Use the correct IP or host name for the source database
        host: pg96.local
        user: postgres
        dbname: postgres
      password:
        name: cluster-pg96-superuser
        key: password

警告

上記の例では、コミュニティ、したがってCloudNativePGでサポートされなくなったPostgreSQLのバージョンを実行しているソースデータベースを意図的に使用しています。ソースインスタンスからのデータエクスポートは、宛先クラスターの`pg_dump` のバージョンを使用して実行されます。これは、サポートされているものであり、ソースと等しいかそれ以降である必要があります。私たちの経験に基づいて、データをエクスポートするこの方法はPostgresの古いサポートされていないバージョンでも機能するはずであり、レガシーデータをKubernetes内のより良いシステムに移動する機会を提供します。これが、このセクションの例で9.6を使用した主な理由です。この分野で問題が発生した場合は、ご意見をお聞かせください。

microservice タイプを使用する際には、注意する必要があることがいくつかあります。

インポートするデータを含む既存のPostgreSQLインスタンスを指すexternalCluster が必要です（詳細については、 :ref:``externalClusters` セクション<externalClusters セクション>` を参照してください）
オペレーション中にKubernetesクラスターとexternalCluster の間でトラフィックを許可する必要があります
pg_dump を実行し、ロール情報を読み取る必要がある指定されたユーザーでソースデータベースへの接続を許可する必要があります（ スーパーユーザー はOKです）
現在、pg_dump -Fc の結果はPGDATA ボリュームのdumps フォルダー内に一時的に保存されます。インポート操作が完了すると、このフォルダーはオペレーターによって自動的に削除されます。
initdb.import.databases 配列内に指定できるデータベースは1つだけです
ロールはインポートされません-そのため、initdb.import.roles 内で指定できません

`monolith` タイプ¶

モノリスアプローチでは、ソースクラスターから宛先クラスターにインポートするロールとデータベースのセットを指定できます。操作は次の手順で実行されます。

新しいクラスターのinitdb ブートストラップ
選択したロールのエクスポートとインポート
pg_dump -Fc を使用して、選択したデータベース（initdb.import.databases 内）を一度に1つずつエクスポート
選択した各データベースを作成し、pg_restore を使用してデータをインポートします
インポートされた各データベースでANALYZE を実行します
データベースダンプファイルのクリーンアップ

たとえば、以下のYAMLは、accountant およびbank_user ロール、ならびにaccounting 、banking 、resort データベースをインポートするcluster-monolith という新しい3インスタンスPostgreSQLクラスター（オペレーターがリリースされた時点で利用可能な最新のメジャーバージョン）を作成します。クラスター（サポートされていないPostgreSQL 9.6を使用）、 cluster-pg96-superuser シークレットに保存されているパスワードを介して、 postgres ユーザーを使用してpostgres データベースに接続します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-monolith
spec:
  instances: 3
  bootstrap:
    initdb:
      import:
        type: monolith
        databases:
          - accounting
          - banking
          - resort
        roles:
          - accountant
          - bank_user
        source:
          externalCluster: cluster-pg96
  storage:
    size: 1Gi
  externalClusters:
    - name: cluster-pg96
      connectionParameters:
        # Use the correct IP or host name for the source database
        host: pg96.local
        user: postgres
        dbname: postgres
        sslmode: require
      password:
        name: cluster-pg96-superuser
        key: password

monolith タイプを使用する際には、注意する必要があることがいくつかあります。

インポートするデータを含む既存のPostgreSQLインスタンスを指すexternalCluster が必要です（詳細については、 :ref:``externalClusters` セクション<externalClusters セクション>` を参照してください）
オペレーション中にKubernetesクラスターとexternalCluster の間でトラフィックを許可する必要があります
pg_dump を実行し、ロール情報を取得する必要がある指定されたユーザーでソースデータベースへの接続を許可する必要があります（ スーパーユーザー はOKです）
現在、pg_dump -Fc の結果はPGDATA ボリュームのdumps フォルダー内に一時的に保存されます。インポート操作が完了すると、このフォルダーはオペレーターによって自動的に削除されます。
initdb.import.databases 配列で指定される少なくとも1つのデータベース
インポートされたデータベースに必要なロールは、以下の制限付きでinitdb.import.roles 内で指定する必要があります。-次のロールが存在する場合、インポートされません：postgres 、streaming_replica 、cnp_pooler_pgbouncer
ワイルドカード"*" は、databases および/またはroles 配列内の唯一の要素として使用して、その種類のすべてのオブジェクトをインポートできます。データベースと一致する場合、ワイルドカードはpostgres データベース、テンプレートデータベース、および接続を許可しないそれらのデータベースを無視します
cloneプロシージャが完了した後、すべてのデータベースに対してANALYZE VERBOSE が実行されます。
postImportApplicationSQL フィールドはサポートされていません

Postgresデータベースのインポート¶

仕組み¶

`microservice` タイプ¶

`monolith` タイプ¶

前のトピックへ

次のトピックへ

目次

Postgresデータベースのインポート¶

仕組み¶

microservice タイプ¶

monolith タイプ¶

`microservice` タイプ¶

`monolith` タイプ¶