マネージド インポートを使用して外部データベースからのレプリケーションを設定する

このページでは、外部サーバーから Cloud SQL にレプリケーションを行う際に、データのマネージド インポートを設定し、使用する方法について説明します。

このページで説明する手順はすべて完了する必要があります。完了したら、他の Cloud SQL インスタンスと同じ方法でソース表現インスタンスを管理し、監視できます。

始める前に

始める前に、次の手順を完了してください。

  1. 外部サーバーを構成します

  2. ソース表現インスタンスを作成します

  3. Cloud SQL レプリカを設定します

レプリケーションの設定を確認する

設定が完了したら、外部サーバーから Cloud SQL レプリカが複製できることを確認します。

以下の外部同期設定が正しいことを確認します。

  • Cloud SQL レプリカと外部サーバーとの間の接続
  • レプリケーション ユーザーの権限
  • バージョンの互換性
  • Cloud SQL レプリカがまだレプリケートされていない

これらの設定を確認するには、Cloud Shell ターミナルを開いて次のコマンドを入力します。

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

これらの呼び出しは、sql#externalSyncSettingErrorList 型のリストを返します。

リストが空の場合は、エラーはありません。エラーのないレスポンスは、次のようになります。

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
プロパティ 説明
SYNC_MODE レプリケーションの設定後に、Cloud SQL レプリカと外部サーバーの同期を確実に維持できるようになります。同期モードには EXTERNAL_SYNC_MODE_UNSPECIFIEDONLINEOFFLINE があります。
SYNC_PARALLEL_LEVEL

データベースのテーブルからのデータ転送速度を制御する設定を確認します。指定できる値は次のとおりです。

  • min:: 最小量のコンピューティング リソースがデータベースに対して使用されます。これは、データ転送速度が最も遅くなる設定です。
  • optimal:: バランスの取れたパフォーマンスが実現し、データベースへの負荷が最適な状態になります。
  • max:: データ転送速度が最も速くなりますが、その結果としてデータベースの負荷が増加する可能性があります。

注: このパラメータのデフォルト値は optimal です。この設定では良好な速度でデータが転送され、データベースへの影響も妥当であるためです。この値を使用することをおすすめします。

PROJECT_ID Google Cloud プロジェクトの ID です。
REPLICA_INSTANCE_ID Cloud SQL レプリカの ID。

外部サーバーでレプリケーションを開始する

外部サーバーから複製できることを確認したら、レプリケーションを開始します。最初のインポート プロセスのためのレプリケーション実行速度は、1 時間あたり最大 500 GB です。ただし、この速度は、マシンのティア、データディスク サイズ、ネットワーク スループット、データベースの性質によって異なる可能性があります。

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
プロパティ 説明
SYNC_MODE レプリケーションの設定後に、Cloud SQL レプリカと外部サーバーの同期を維持できることを確認します。
SKIP_VERIFICATION データを同期する前に、組み込みの検証ステップをスキップするかどうか。このパラメータは、レプリケーションの設定を確認済みの場合にのみ使用することをおすすめします。
SYNC_PARALLEL_LEVEL

データベースのテーブルからのデータ転送速度を制御する設定を指定します。指定できる値は次のとおりです。

  • min:: 最小量のコンピューティング リソースがデータベースに対して使用されます。これは、データ転送速度が最も遅くなる設定です。
  • optimal:: バランスの取れたパフォーマンスが実現し、データベースへの負荷が最適な状態になります。
  • max:: データ転送速度が最も速くなりますが、その結果としてデータベースの負荷が増加する可能性があります。

注: このパラメータのデフォルト値は optimal です。この設定では良好な速度でデータが転送され、データベースへの影響も妥当であるためです。この値を使用することをおすすめします。

PROJECT_ID Google Cloud プロジェクトの ID です。
REPLICA_INSTANCE_ID Cloud SQL レプリカの ID。

移行をモニタリングする

外部サーバーからのレプリケーションを開始したら、レプリケーションをモニタリングする必要があります。詳細については、レプリケーションのモニタリングをご覧ください。その後、移行を完了できます。

トラブルシューティング

次のトラブルシューティング オプションを検討してください。

問題 トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。
リードレプリカを作成できない - invalidFlagValue エラー。 リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

まず、max_connections フラグの値がプライマリの値以上であることを確認します。

max_connections フラグが適切に設定されている場合、Cloud Logging のログを調べて、実際のエラーを確認します。

リードレプリカを作成できない - 不明なエラー。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。

エラーが set Service Networking service account as servicenetworking.serviceAgent role on consumer project の場合は、Service Networking API を無効にしてから再度有効にします。この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。

ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
ディスク容量が大幅に増加します。 データの追跡に使用されていないスロットでは、PostgreSQL が WAL セグメントに無期限に維持するため、ディスク容量は無期限に増加します。Cloud SQL で論理レプリケーションと論理デコーディング機能を使用すると、レプリケーション スロットが自動的に作成、削除されます。pg_replication_slots システムビューにクエリを実行し、active 列でフィルタリングすると、未使用のレプリケーション スロットを検出できます。未使用のスロットを削除することで、pg_drop_replication_slot コマンドで WAL セグメントを削除できます。
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。

レプリケーションが停止した。 ストレージの上限に達しており、ストレージの自動増量が有効になっていません。

インスタンスを編集して automatic storage increase を有効にします。

レプリケーション ラグが常に大きい。 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

考えられる解決策は次のとおりです。

  • インスタンスを編集してレプリカのサイズを増やします。
  • データベースの負荷を軽減します。
  • リードレプリカにリード トラフィックを送信します。
  • テーブルをインデックスに登録します。
  • 遅い書き込みクエリを特定して修正します。
  • レプリカを再作成します。
PostgreSQL 9.6 でインデックスを再構築する際のエラー。 特定のインデックスを再構築する必要があることを示す PostgreSQL のエラーが発生します。これは、プライマリ インスタンスでのみ行うことができます。新しいレプリカ インスタンスを作成すると、すぐに同じエラーが発生します。バージョン 10 より前の PostgreSQL ではハッシュ インデックスはレプリカに伝播されません

ハッシュ インデックスを使用する必要がある場合は、PostgreSQL 10 以降にアップグレードしてください。レプリカも使用する場合は、PostgreSQL 9.6 でハッシュ インデックスを使用しないでください。

プライマリ インスタンスでのクエリは常に実行中です。 レプリカの作成後、クエリ SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' はプライマリ インスタンスで継続的に実行されます。
レプリカの作成がタイムアウトで失敗する。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

実行中のクエリをすべて停止してからレプリカを再作成します。

プライマリ インスタンスとレプリカの vCPU サイズが異なる場合、クエリ オプティマイザーは vCPU サイズを考慮するため、クエリのパフォーマンスに問題が生じる可能性があります。

この問題を解決するには、次の操作を行います。

  1. log_duration フラグをオンにして、log_statement パラメータを ddl に設定します。これにより、データベースのクエリと実行時間の両方を確認できます。ただし、ワークロードによっては、パフォーマンスの問題が発生する可能性があります。
  2. プライマリ インスタンスとリードレプリカの両方で、クエリに対して explain analyze を実行します。
  3. クエリプランを比較して違いを確認します。

特定のクエリの場合は、クエリを変更します。たとえば、結合の順序を変更して、パフォーマンスが向上するかどうかを確認できます。

レプリケーション ログを確認する

レプリケーションの設定を確認したときに、ログが生成されています。

これらのログは次の手順で確認できます。

  1. Google Cloud コンソールでログビューアに移動します。

    ログビューアに移動

  2. [インスタンス] プルダウンから Cloud SQL レプリカを選択します。
  3. replication-setup.log ログファイルを選択します。

Cloud SQL レプリカが外部サーバーに接続できない場合は、次の点を確認してください。

  • 外部サーバー上のすべてのファイアウォールが、Cloud SQL レプリカの送信 IP アドレスからの接続を受け入れるように構成されている。
  • SSL / TLS 構成が正しく行われている。
  • 正しいレプリケーション ユーザー、ホスト、パスワードを使用している。

次のステップ