既存の移行先クラスタに移行する

このページでは、AlloyDB for PostgreSQL で直接作成された既存の AlloyDB for PostgreSQL クラスタにデータベースを移行する方法について説明します。

このパスは、移行先クラスタが別のチームによって管理されている場合や、Database Migration Service の外部でクラスタを作成して、特定のカスタムフラグ、事前割り当て IP 範囲、複雑な VPC ネットワーク トポロジを構成する必要がある場合に便利です。移行の要件が異なる場合は、別の移行フローを検討してください。詳細については、 PostgreSQL から AlloyDB for PostgreSQL への移行を開始するをご覧ください。

継続的な移行の手順は、大まかに次のとおりです。

  1. Database Migration Service がデータを複製できるように、移行元データベースを構成します。
  2. ソース データベースと Google Cloud間のネットワーク接続を設定します。
  3. 既存の移行先 AlloyDB for PostgreSQL クラスタを準備して構成します。
  4. ソース接続プロファイルと継続的な移行ジョブを作成します。
  5. 継続的な移行ジョブを開始してモニタリングする。
  6. 移行ジョブをプロモートし、新しいデータベースを使用するようにアプリケーションを移行します。

費用

このドキュメントでは、課金対象である次のGoogle Cloudコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

始める前に

  1. この移行パスがシナリオを完全にサポートできるかどうかを確認します。次のページをご覧ください。
    • シナリオの概要ページの サポートされている移行元と移行先に、サポートされているすべての移行元と移行先のバージョンが一覧表示されます。
    • 既知の制限事項では、運用上の境界、サポートされているデータ型、パフォーマンスの上限について説明します。AlloyDB for PostgreSQL 向けの Database Migration Service は、継続的な移行をサポートしています。
  2. 宛先クラスタを作成するリージョンを検討します。Database Migration Service は完全にリージョンに依存するプロダクトです。つまり、移行に関連するすべてのエンティティ（移行元の接続プロファイル、移行ジョブ、移行先のクラスタ）は、1 つの Google Cloud リージョンに存在する必要があります。
  3. Google Cloud コンソールのプロジェクト セレクタ ページで、 Google Cloud プロジェクトを選択または作成します。

    プロジェクト セレクタに移動

  4. Database Migration Service、AlloyDB for PostgreSQL、Compute Engine の API を有効にします。

    API を有効にする

必要なロール

Database Migration Service を使用して AlloyDB for PostgreSQL への同種の PostgreSQL 移行を実行するために必要な権限を取得するには、プロジェクトに対する必要な IAM ロールを付与するよう管理者に依頼してください。

ロールの付与の詳細については、Identity and Access Management のドキュメントの アクセスを管理するをご覧ください。

これらの事前定義ロールには、Database Migration Service を使用して同種の PostgreSQL 移行を実行するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

必要な権限

Database Migration Service を使用して、既存の AlloyDB for PostgreSQL クラスタに同種の PostgreSQL 移行を実行するには、次の権限が必要です。

  • datamigration.*
  • alloydb.clusters.get
  • alloydb.clusters.list
  • alloydb.clusters.update
  • alloydb.instances.get
  • alloydb.instances.list
  • alloydb.instances.update
  • alloydb.operations.get
  • alloydb.users.list
  • alloydb.users.get
  • alloydb.users.create
  • alloydb.users.update

カスタムロールや他の 事前定義ロールを使用して、これらの権限を取得することもできます。

ソース データベースを準備する

移行元データベースを移行用に準備する手順は次のとおりです。

  1. 移行元のネットワーク接続方法を選択して構成する。
  2. ソース データベース インスタンスを構成します。大まかな手順は次のとおりです。
    1. 移行元のデータベースと、移行対象のすべてのデータベースに pglogical PostgreSQL 拡張機能（バージョン 2.2.1 以降）をインストールします。
    2. PostgreSQL パラメータを構成します。wal_level = logical を設定し、max_replication_slots、max_wal_senders、max_worker_processes に適切な値を設定します。
    3. 移行ユーザーにレプリケーション権限を付与し、移行先の AlloyDB for PostgreSQL クラスタからの受信接続を許可するように pg_hba.conf を構成します。

    詳細な手順については、 移行元データベースを構成するをご覧ください。

  3. ソース接続プロファイルを作成する。

移行先クラスタを準備して構成する

既存の AlloyDB for PostgreSQL クラスタ（別のチームによって事前にプロビジョニングされたクラスタや Terraform で管理されているクラスタなど）に移行する場合は、移行ジョブを作成する前に、クラスタが Database Migration Service のすべての前提条件を満たしていることを確認してください。

  1. クラスタの準備状況とデータ状態:
    • 宛先クラスタは RUNNABLE 状態であり、アクティブなプライマリ インスタンスが存在する必要があります。
    • クラスタは、移行ジョブおよび接続プロファイルと同じ Google Cloud リージョンに存在する必要があります。
    • クラスタに関連付けることができるアクティブな移行ジョブは、一度に 1 つのみです。
    • 宛先クラスタには、デフォルトのシステム データベース（postgres、template0、template1）のみが含まれ、ユーザー テーブルは含まれていない必要があります。
  2. データベース フラグの構成: 移行先の AlloyDB for PostgreSQL クラスタで alloydb.enable_pglogical フラグを有効にします。このフラグは、論理レプリケーションのデコードと取り込みに必要です。フラグの更新手順については、AlloyDB for PostgreSQL のドキュメントの データベース フラグを構成するをご覧ください。
  3. データベース ユーザーの認証情報と権限: 管理者権限を持つユーザー アカウント postgres（または alloydbsuperuser ロールが付与された専用の移行アカウント）が移行先クラスタに存在することを確認します。Database Migration Service は、レプリケーション サブスクライバーを管理し、スキーマを同期するために、管理者権限で宛先に接続します。
  4. ネットワーク接続の要件: 選択した接続方法に従って、移行先クラスタのネットワーキングが移行元データベースと通信するように適切に構成されていることを確認します。
    • Private Service Connect: 宛先クラスタで Private Service Connect が有効になっている場合は、クラスタが適切な Private Service Connect ネットワーク アタッチメントとルーティングで構成され、ソース ネットワークに到達できることを確認します。詳細については、AlloyDB for PostgreSQL ドキュメントの Private Service Connect を構成するをご覧ください。
    • Virtual Private Cloud ピアリング（プライベート サービス アクセス / プライベート IP）: 宛先クラスタには、ソース データベースとピアリングまたはルーティングする Virtual Private Cloud ネットワーク（Cloud VPN や Cloud Interconnect など）でプライベート サービス アクセスが構成されている必要があります。詳細については、AlloyDB for PostgreSQL のドキュメントの プライベート サービス アクセスを構成するをご覧ください。
    • パブリック IP 許可リスト: 移行元データベースにパブリック インターネット経由でアクセスできる場合は、移行先の AlloyDB for PostgreSQL プライマリ インスタンスの送信 IP アドレスからの受信接続が移行元のファイアウォールで許可されていることを確認します。
    • リバース SSH トンネルまたは TCP プロキシ VM: 移行元データベースが Google Cloud の外部にあり、直接プライベート ピアリングがない場合は、移行先クラスタの Virtual Private Cloud ネットワークから到達可能なサブネットに中間 Compute Engine VM（踏み台インスタンスまたは TCP プロキシ）がデプロイされていることを確認します。詳細については、 ネットワーキング メソッドをご覧ください。
  5. プライマリ インスタンスの降格と書き込みロックの通知:
    • Database Migration Service は、移行プロセス中に外部レプリケーション サブスクライバーとして機能するように、既存の移行先プライマリ インスタンスを降格します。 Google Cloud コンソールで移行ジョブを構成するときに、移行先クラスタ ID を入力して、この降格を確認する必要があります。
    • プライマリ インスタンスを降格しても、データベースは厳密な読み取り専用モードになりませんが、レプリケーションの競合とデータドリフトを防ぐために、移行に参加しているテーブルまたはデータベースに対する書き込みオペレーションは避ける必要があります。詳細については、 既存の宛先クラスタへの移行に関する制限事項をご覧ください。

移行ジョブを作成して実行する

既存の宛先クラスタへの継続的な移行を構成して実行する手順は次のとおりです。

  1. 省略可: 移行ジョブの独自の証明書または暗号鍵を管理する場合は、 必要な暗号鍵を準備します。
  2. 既存の移行先クラスタの移行ジョブを作成して実行します。

    Database Migration Service のオブザーバビリティ機能を使用すると、移行の進行状況と移行先クラスタの状態をモニタリングできます。 移行ジョブの指標をご覧ください。

移行を完了する

アプリケーション トラフィックを新しい AlloyDB for PostgreSQL クラスタに切り替える場合は、次の手順で移行を完了します。

  1. 移行元データベースに対するすべての書き込みオペレーションを停止します。ソース データベースを読み取り専用モードに構成すると、クエリの可用性を維持しながら、新しい変更を防止できます。
  2. 移行ジョブをプロモートします。移行ジョブをプロモートすると、残りのすべての CDC トランザクションが同期され、ソースからのレプリケーションが終了し、AlloyDB for PostgreSQL プライマリ インスタンスがスタンドアロンの完全に動作するプライマリ クラスタにプロモートされます。
  3. 省略可: 移行データを検証して、完全性と行の整合性を確認します。

次のステップ

AlloyDB for PostgreSQL の機能と管理機能の詳細。 AlloyDB for PostgreSQL の概要をご覧ください。