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

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

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

始める前に

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

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

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

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

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

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

必要な権限

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

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

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

タイプ 1

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

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

タイプ 2

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

タイプ 3

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

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

タイプ 4

権限は必要ありません。

権限を更新する

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

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_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

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

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_UNSPECIFIEDONLINEOFFLINE があります。
SYNC_PARALLEL_LEVEL

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

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

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

SYNC_FLAGS 検証する初期同期フラグのリスト。ソースからの複製でカスタム同期フラグを指定する場合にのみ、使用することをおすすめします。使用可能なフラグのリストについては、初期同期フラグをご覧ください。
PROJECT_ID Google Cloud プロジェクトの ID。
REPLICA_INSTANCE_ID 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 時間あたり最大 500 GB です。ただし、この速度は、マシンのティア、データディスク サイズ、ネットワーク スループット、データベースの性質によって異なる可能性があります。

最初のインポート プロセス中は、外部サーバーで 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_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

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

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_PARALLEL_LEVEL

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

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

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

SYNC_FLAGS 検証する初期同期フラグのリスト。ソースからの複製でカスタム同期フラグを指定する場合にのみ、使用することをおすすめします。使用可能なフラグのリストについては、初期同期フラグをご覧ください。
PROJECT_ID Google Cloud プロジェクトの ID。
REPLICA_INSTANCE_ID 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 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

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

レプリケーション ラグが突然急増する。 これは、トランザクションが長時間実行されていることが原因です。ソース インスタンスでトランザクション(単一ステートメントまたは複数ステートメント)が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。

長時間のトランザクションを避けるために、次のような解決策が考えられます。

  • トランザクションを複数の小さなトランザクションに分割します。
  • 1 つの大きな書き込みクエリを小さなバッチに分割します。
  • DML を含むトランザクションから長い SELECT クエリを分離します。
並列レプリケーション フラグを変更するとエラーが発生する。 1 つ以上のフラグに間違った値が設定されています。

エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。

  1. binlog_transaction_dependency_tracking フラグと transaction_write_set_extraction フラグを変更します。
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. slave_pending_jobs_size_max フラグを追加します。

    slave_pending_jobs_size_max=33554432

  3. transaction_write_set_extraction フラグを変更します。

    transaction_write_set_extraction=XXHASH64

  4. 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-dbbinlog-ignore-dbreplicate-do-dbreplicate-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 構成が正しく行われている。
  • 正しいレプリケーション ユーザー、ホスト、パスワードを使用している。

次のステップ