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

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

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

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

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

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

警告

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

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

重要

このため、バックアップの開始後にソースデータベースに行われた変更は宛先クラスタにないため、 Cluster リソースの最終インポートの前にソースの書き込み操作を停止することをお勧めします。したがって、この機能が参照される理由「オフラインインポート」または「オフラインメジャーアップグレード」として。

その仕組み#

概念的には、インポートには、空のクラスターをブートストラップする `initdb <空のクラスターをブートストラップする initdb>` を使用して新しいクラスター 宛先クラスター を作成し、 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 内のエクスポート
initdb.owner ユーザーが所有するinitdb.database アプリケーションデータベースへのpg_restore --no-acl --no-owner を使用したデータベースのインポート
データベースダンプファイルのクリーンアップ
postImportApplicationSQL パラメーターを介してアプリケーションデータベースでのユーザー定義のSQLクエリーのオプションの実行
インポートされたデータベースでのANALYZE VERBOSE の実行

たとえば、以下のYAMLは、 postgres に接続することにより、cluster-pg96 クラスターサポートされていないPostgreSQL 9.6からangus データベースをインポートする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は、 cluster-monolith と呼ばれる新しい3インスタンスのPostgreSQLクラスターオペレーターがリリースされた時点での利用可能な最新のメジャーバージョンを作成します。 postgres ユーザーを使用してpostgres データベースに接続し、cluster-pg96-superuser シークレットに保存されているパスワードを介して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 内で指定する必要があります。以下の制限があります。
ワイルドカード"*" は、databases および/またはroles 配列の唯一の要素として使用して、その種類のすべてのオブジェクトをインポートできます。データベースを照合する場合、ワイルドカードはpostgres データベース、テンプレートデータベース、および接続を許可しないデータベースを無視します
クローンプロシージャが完了した後、すべてのデータベースに対してANALYZE VERBOSE が実行されます。
postImportApplicationSQL フィールドはサポートされていません

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

目次

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

その仕組み#

microservice タイプ#

monolith タイプ#

`microservice` タイプ#

`monolith` タイプ#