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

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

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

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

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

-  Kubernetesの外部でも、既存のPostgreSQLインスタンスから1つ以上のデータベースをインポート

-  PostgreSQLバージョンから同じまたは新しいバージョンにデータベースをインポートし、PostgreSQLの
   *メジャーアップグレード*
   を有効にしますバージョン11.xからバージョン15.xなど

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

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

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

その仕組み
----------

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

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

-  **マイクロサービスアプローチ**
   宛先クラスターは、CloudNativePGプロジェクトで推奨されているように、指定されたアプリケーションユーザーが所有する単一のアプリケーションデータベースをホストするように設計されています

-  **モノリスアプローチ**
   宛先クラスターは、ソースクラスターからインポートされた複数のデータベースとさまざまなユーザーをホストするように設計されています。

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

..  Warning::
   宛先クラスターが、スーパーユーザーまたは`pg_dump` で論理バックアップを取るための十分な特権を持つユーザーでソースクラスターにアクセスできることを確認するのはあなたの責任です。 `PostgreSQL documentation on "SQL Dump" <https://www.postgresql.org/docs/current/app-pgdump.html>`_ を参照してください。

詳細については、

``microservice`` タイプ
-----------------------

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

-  新しいクラスターの\ ``initdb`` ブートストラップ

-  ``pg_dump -Fc``
   を使用した選択したデータベース\ ``initdb.import.databases``
   内のエクスポート

-  ``initdb.owner`` ユーザーが所有する\ ``initdb.database``
   アプリケーションデータベースへの\ ``pg_restore --no-acl --no-owner``
   を使用したデータベースのインポート

-  データベースダンプファイルのクリーンアップ

-  ``postImportApplicationSQL``
   パラメーターを介してアプリケーションデータベースでのユーザー定義のSQLクエリーのオプションの実行

-  インポートされたデータベースでの\ ``ANALYZE VERBOSE`` の実行

.. figure:: /images/microservice-import.png
   :width: 70% 
   :alt: Example of microservice import type

   Example of microservice import type

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

.. code:: yaml

   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

..  Warning::
   上記の例では、コミュニティ、したがって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`` を実行します

-  データベースダンプファイルのクリーンアップ

.. figure:: /images/monolith-import.png
   :width: 70% 
   :alt: Example of monolith import type

   Example of monolith import type

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

.. code:: yaml

   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`` フィールドはサポートされていません
