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

MySQL   |  PostgreSQL   |  SQL Server

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

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

始める前に

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

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

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

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

レプリケーション ユーザーの権限を更新する

外部サーバー上のレプリケーション ユーザーは、任意のホスト（%）からの接続を受け入れるように構成されています。Cloud SQL レプリカでのみ使用されるように、このユーザー アカウントを更新します。

必要な権限

移行とダンプの組み合わせは 4 種類あります。

• タイプ 1: 継続的な移行とマネージド ダンプ
• タイプ 2: 継続的な移行と手動ダンプ
• タイプ 3: 1 回限りの移行とマネージド ダンプ
• タイプ 4: 1 回限りの移行と手動ダンプ

移行とダンプの組み合わせの種類ごとの権限を以下に示します。

タイプ 1

ユーザー アカウントには次の権限が必要です。

• REPLICATION SLAVE
• EXECUTE
• SELECT
• SHOW VIEW
• REPLICATION CLIENT
• RELOAD
• TRIGGER
• （Amazon RDS と Amazon Aurora からの移行の場合のみ） LOCK TABLES

MySQL バージョン 8.0 以降では、最適なパフォーマンスを得るために、BACKUP ADMIN 権限をスキップすることをおすすめします。

注: これらの権限の詳細については、MySQL によって提供される権限をご覧ください。

タイプ 2

ユーザー アカウントには次の権限が必要です。

• REPLICATION SLAVE
• EXECUTE

注: これらの権限の詳細については、MySQL によって提供される権限をご覧ください。

タイプ 3

ユーザー アカウントには次の権限が必要です。

• SELECT
• SHOW VIEW
• TRIGGER
• （GTID_MODE = ON 設定の移行元からの移行のみ） 再読み込み

MySQL バージョン 8.0 以降では、最適なパフォーマンスを得るために、BACKUP ADMIN 権限をスキップすることをおすすめします。

注: これらの権限の詳細については、MySQL によって提供される権限をご覧ください。

タイプ 4

権限は必要ありません。

注: これらの権限の詳細については、MySQL によって提供される権限をご覧ください。

権限を更新する

権限を更新するには、外部サーバーでターミナルを開いて次のコマンドを入力します。

mysql クライアント

GTID の場合:

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

バイナリログの場合:

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

例

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;

プロパティ	説明
NEW_HOST	Cloud SQL レプリカの送信 IP を指定します。
OLD_HOST	変更する Host に割り当てる現在の値。
USERNAME	外部サーバー上のレプリケーション ユーザー アカウント。
GCP_USERNAME	ユーザー アカウントのユーザー名。
HOST	ユーザー アカウントのホスト名。

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

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

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

• Cloud SQL レプリカと外部サーバーとの間の接続
• レプリケーション ユーザーの権限
• バージョンの互換性
• Cloud SQL レプリカはまだレプリケートされていない
• 外部サーバーでバイナリログが有効になっている
• RDS 外部サーバーから外部同期を行う場合と、Google Cloud バケットを使用している場合に、GTID が有効になっている。

これらの設定を確認するには、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",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE/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

同期フラグ付きのサンプル

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"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

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

リストが空の場合、エラーはありません。エラーのないレスポンスは、{ "kind": "sql#externalSyncSettingErrorList" } のようになります。

プロパティ	説明
SYNC_MODE	レプリケーションの設定後に、Cloud SQL レプリカと外部サーバーの同期を維持します。同期モードには EXTERNAL_SYNC_MODE_UNSPECIFIED、ONLINE、OFFLINE があります。
SYNC_FLAGS	検証する初期同期フラグのリスト。ソースからの複製でカスタム同期フラグを指定する場合にのみ、使用することをおすすめします。使用可能なフラグのリストについては、こちらをご覧ください。
SYNC_PARALLEL_LEVEL	データの転送速度を制御する設定を確認します。並列レベルには、MIN、MAX、OPTIMAL があります。デフォルト値は OPTIMAL です。
PROJECT_ID	Google Cloud のプロジェクトの ID。
REPLICA_INSTANCE	Cloud SQL レプリカの ID。

グローバル読み取りロックの権限

外部サーバー上のグローバル読み取りロックにアクセスする権限がない場合は（Amazon RDS や Amazon Aurora ではこうしたアクセス権がない場合があります）、次の手順で説明されているように、サーバーへの書き込みを一時的に停止します。

1. ログ エクスプローラに移動し、リソースリストから Cloud SQL レプリカを選択します。Cloud SQL レプリカの最新のログのリストが表示されます。ここでは無視します。
2. ターミナルを開き、外部サーバーでレプリケーションを開始するのコマンドを入力して、外部サーバーから複製します。

3. ログ エクスプローラに戻ります。次のようなログが表示されたら、外部サーバー上のデータベースへの書き込みを停止します。ほとんどの場合、数秒間の停止ですみます。

      DUMP_IMPORT(START): Start importing data, please pause any write to the
      external primary database.
   

4. ログ エクスプローラに次のログエントリが表示されたら、外部サーバー上のデータベースへの書き込みを再度有効にします。

      DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
      external primary may resume.
   
   

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

外部サーバーから複製できることを確認したら、レプリケーションを実行する準備は完了です。レプリカは 1 時間あたり 25～50 GB をインポートすると想定してください。

注意: Amazon RDS や Amazon Aurora などのマネージド サービスのデータベースからインポートを開始すると、Cloud SQL により、データダンプの整合性を確保するため、数秒間書き込みを停止するように指示されます。マネージド サービスのプライマリ インスタンスへの書き込みでダウンタイムの発生を回避するには、レプリケーション ソースとしてプライマリ インスタンスではなくリードレプリカを選択します。書き込みの停止が必要なフェーズでは、移行元のリードレプリカへのレプリケーションを一時的に停止し、書き込み停止フェーズが終了してからレプリケーションを再開できます。

最初のインポート プロセス中は、外部サーバーで DDL オペレーションを実行しないでください。インポートを行うと、インポート中に不整合が生じる可能性があります。インポート プロセスが完了すると、レプリカは外部サーバー上のバイナリログを使用して、外部サーバーの現在の状態に近くなります。

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",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE/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

同期フラグ付きのサンプル

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"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

プロパティ	説明
SYNC_MODE	レプリケーションの設定後に、Cloud SQL レプリカと外部サーバーの同期が維持できることを確認します。
SKIP_VERIFICATION	データを同期する前に、組み込みの検証ステップをスキップするかどうか。レプリケーションの設定を確認している場合にのみ使用することをおすすめします。
SYNC_FLAGS	検証する初期同期フラグのリスト。ソースからの複製でカスタム同期フラグを指定する場合にのみ、使用することをおすすめします。使用可能なフラグのリストについては、こちらをご覧ください。
SYNC_PARALLEL_LEVEL	データの転送速度を制御する設定を確認します。並列レベルには、MIN、MAX、OPTIMAL があります。デフォルト値は OPTIMAL です。
PROJECT_ID	Google Cloud のプロジェクトの ID。
REPLICA_INSTANCE	Cloud SQL レプリカの ID。

初期同期フラグ

カスタム データベース フラグで移行するには、次のフラグを使用できます。

• --add-drop-database
• --add-drop-table
• --add-drop-trigger
• --add-locks
• --allow-keywords
• --all-tablespaces
• --apply-slave-statements
• --column-statistics
• --comments
• --compact
• --compatible
• --complete-insert
• --compress
• --compression-algorithms
• --create-options
• --default-character-set
• --delayed-insert
• --disable-keys
• --dump-date
• --events
• --extended-insert
• --fields-enclosed-by
• --fields-escaped-by
• --fields-optionally-enclosed-by
• --fields-terminated-by
• --flush-logs
• --flush-privileges
• --force
• --get-server-public-key
• --hex-blob
• --ignore-error
• --ignore-read-lock-error
• --ignore-table
• --insert-ignore
• --lines-terminated-by
• --lock-all-tables
• --lock-tables
• --max-allowed-packet
• --net-buffer-length
• --network-timeout
• --no-autocommit
• --no-create-db
• --no-create-info
• --no-data
• --no-defaults
• --no-set-names
• --no-tablespaces
• --opt
• --order-by-primary
• --pipe
• --quote-names
• --quick
• --replace
• --routines
• --secure-auth
• --set-charset
• --shared-memory-base-name
• --show-create-skip-secondary-engine
• --skip-opt
• --ssl-cipher
• --ssl-fips-mode
• --ssl-verify-server-cert
• --tls-ciphersuites
• --tls-version
• --triggers
• --tz-utc
• --verbose
• --xml
• --zstd-compression-level

使用可能な値については、MySQL の公開ドキュメントをご覧ください。

移行をモニタリングする

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

トラブルシューティング

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

問題	トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。	ログファイルに、より具体的なエラーが記録されている可能性があります。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 を無効にしてから再度有効にします。この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。
ディスクに空きがない。	レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
レプリカ インスタンスのメモリ使用量が多すぎる。	レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。
レプリケーションが停止した。	ストレージの上限に達しており、ストレージの自動増量が有効になっていません。 インスタンスを編集して automatic storage increase を有効にします。
レプリケーション ラグが常に大きい。	書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。 レプリカのクエリが遅い。遅いクエリを見つけて修正します。 すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。 DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。 考えられる解決策は次のとおりです。 並列レプリケーションを構成します。 リードレプリカの innodb_flush_log_at_trx_commit フラグを 2 に設定します。 このフラグの詳細については、フラグの使用に関するヒントをご覧ください。 インスタンスを編集してレプリカのサイズを増やします。 データベースの負荷を軽減します。 リードレプリカにリード トラフィックを送信します。 テーブルをインデックスに登録します。 遅い書き込みクエリを特定して修正します。 レプリカを再作成します。
レプリケーション ラグが突然急増する。	これは、トランザクションが長時間実行されていることが原因です。ソース インスタンスでトランザクション（単一ステートメントまたは複数ステートメント）が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。 長時間のトランザクションを避けるために、次のような解決策が考えられます。 トランザクションを複数の小さなトランザクションに分割します。 1 つの大きな書き込みクエリを小さなバッチに分割します。 DML を含むトランザクションから長い SELECT クエリを分離します。
並列レプリケーション フラグを変更するとエラーが発生する。	1 つ以上のフラグに間違った値が設定されています。 エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。 binlog_transaction_dependency_tracking フラグと transaction_write_set_extraction フラグを変更します。 binlog_transaction_dependency_tracking=COMMIT_ORDER transaction_write_set_extraction=OFF slave_pending_jobs_size_max フラグを追加します。 slave_pending_jobs_size_max=33554432 transaction_write_set_extraction フラグを変更します。 transaction_write_set_extraction=XXHASH64 binlog_transaction_dependency_tracking フラグを変更します。 binlog_transaction_dependency_tracking=WRITESET
レプリカの作成がタイムアウトで失敗する。	プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。 実行中のクエリをすべて停止してからレプリカを再作成します。

MySQL の場合は、次のオプションも検討してください。

問題	トラブルシューティング
Lost connection to MySQL server during query when dumping table.	ソースが使用不能か、ダンプに含まれているパケットが大きすぎる可能性があります。 外部プライマリが接続できることを確認します。また、ソース インスタンスの net_read_timeout フラグと net_write_timeout フラグの値を変更して、エラーを防ぐこともできます。これらのフラグに使用可能な値の詳細については、データベース フラグを構成するをご覧ください。 マネージド インポート移行の mysqldump フラグの使用方法については、使用可能な初期同期フラグとデフォルトの初期同期フラグをご覧ください。
最初のデータの移行は成功したが、データが複製されていない。	根本原因の一つとして、ソース データベースでレプリケーション フラグが定義されているため、データベースの一部またはすべての変更が複製されていない可能性があります。 binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db などのレプリケーション フラグが競合する方法で設定されていないことを確認します。 プライマリ インスタンスで show master status コマンドを実行して、現在の設定を確認します。
最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。	次の方法をお試しください。 Google Cloud Console の [Cloud Monitoring] セクションで、レプリカ インスタンスのレプリケーション指標を確認します。 MySQL IO スレッドまたは SQL スレッドのエラーは、mysql.err log ファイルの Cloud Logging で確認できます。 このエラーは、レプリカ インスタンスに接続するときにも発生する場合があります。SHOW SLAVE STATUS コマンドを実行して、出力で次のフィールドを確認します。 Slave_IO_Running Slave_SQL_Running Last_IO_Error Last_SQL_Error
mysqld check failed: data disk is full.	レプリカ インスタンスのデータディスクに空き容量がありません。 レプリカ インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。

レプリケーション ログの確認

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

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

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

   ログビューアに移動

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

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

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

次のステップ

• インスタンスの更新の詳細を確認する。
• レプリカの管理について学習する。
• インスタンスのモニタリングについて確認する。
• Cloud SQL レプリカの昇格について確認する。