Postgres データベースのインポート¶
このセクションでは、新しい CloudNativePG クラスター内に 1 つ以上の既存の PostgreSQL データベースをインポートする方法について説明します。
インポート操作は、PostgreSQL
のオンライン論理バックアップの概念に基づいており、元のホストへのネットワーク接続を介した
pg_dump と pg_restore に依存しています。ネイティブの
Multi-Version Concurrency Control (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の実行
Example of microservice import type¶
たとえば、以下の 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
警告
上記の例では、コミュニティによってサポートされなくなったバージョンの PostgreSQL を実行しているソース データベースを意図的に使用しており、結果として CloudNativePG によってサポートされていません。ソース インスタンスからのデータ エクスポートは、宛先クラスター内の 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を実行しますデータベース ダンプ ファイルのクリーンアップ
Example of monolith import type¶
たとえば、以下の YAML は、cluster-pg96 から accounting
、banking 、resort データベースだけでなく、accountant
および bank_user ロールをインポートする cluster-monolith
と呼ばれる新しい 3 インスタンス PostgreSQL クラスター
(オペレーターがリリースされた時点で利用可能な最新のメジャー バージョン)
を作成します。 cluster-pg96-superuser
シークレットに保存されているパスワードを介して、postgres
ユーザーを使用して postgres
データベースに接続することにより、クラスター (サポートされていない
PostgreSQL 9.6 を使用)。
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フィールドはサポートされていません
