このページでは、外部サーバーから Cloud SQL にレプリケーションを行う際に、データのマネージド インポートを設定し、使用する方法について説明します。
このページで説明する手順はすべて完了する必要があります。完了したら、他の 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 権限をスキップすることをおすすめします。
タイプ 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_UNSPECIFIED、ONLINE、OFFLINE があります。 |
| SYNC_PARALLEL_LEVEL | データベースのテーブルからのデータ転送速度を制御する設定を確認します。指定できる値は次のとおりです。
注: このパラメータのデフォルト値は |
| SYNC_FLAGS | 検証する初期同期フラグのリスト。ソースからの複製でカスタム同期フラグを指定する場合にのみ、使用することをおすすめします。使用可能なフラグのリストについては、初期同期フラグをご覧ください。 |
| PROJECT_ID | Google Cloud プロジェクトの ID。 |
| REPLICA_INSTANCE_ID | Cloud SQL レプリカの ID。 |
グローバル読み取りロックの権限
外部サーバー上のグローバル読み取りロックにアクセスする権限がない場合は（Amazon RDS や Amazon Aurora ではこうしたアクセス権がない場合があります）、次の手順で説明されているように、サーバーへの書き込みを一時的に停止します。
- ログ エクスプローラに移動し、リソースリストから Cloud SQL レプリカを選択します。Cloud SQL レプリカの最新のログのリストが表示されます。ここでは無視します。
- ターミナルを開き、外部サーバーでレプリケーションを開始するのコマンドを入力して、外部サーバーから複製します。
ログ エクスプローラに戻ります。次のようなログが表示されたら、外部サーバー上のデータベースへの書き込みを停止します。ほとんどの場合、数秒間の停止ですみます。
DUMP_IMPORT(START): Start importing data, please pause any write to the external primary database.ログ エクスプローラに次のログエントリが表示されたら、外部サーバー上のデータベースへの書き込みを再度有効にします。
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 | データベースのテーブルからのデータ転送速度を制御する設定を指定します。指定できる値は次のとおりです。
注: このパラメータのデフォルト値は |
| 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 エラー。 | リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。 まず、
|
| リードレプリカを作成できない - 不明なエラー。 | ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。 エラーが |
| ディスクに空きがない。 | レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。 |
| レプリカ インスタンスのメモリ使用量が多すぎる。 | レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。 |
| レプリケーションが停止した。 | ストレージの上限に達しており、ストレージの自動増量が有効になっていません。 インスタンスを編集して |
| レプリケーション ラグが常に大きい。 | 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
考えられる解決策は次のとおりです。
|
| レプリケーション ラグが突然急増する。 | これは、トランザクションが長時間実行されていることが原因です。ソース インスタンスでトランザクション（単一ステートメントまたは複数ステートメント）が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。 長時間のトランザクションを避けるために、次のような解決策が考えられます。
|
| 並列レプリケーション フラグを変更するとエラーが発生する。 | 1 つ以上のフラグに間違った値が設定されています。
エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。
|
| レプリカの作成がタイムアウトで失敗します。 | プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。 実行中のクエリをすべて停止してからレプリカを再作成します。 |
MySQL の場合は、次のオプションも検討してください。
| 問題 | トラブルシューティング |
|---|---|
Lost connection to MySQL server during query when dumping table. |
ソースが使用不能か、ダンプに含まれているパケットが大きすぎる可能性があります。 外部プライマリが接続できることを確認します。また、ソース インスタンスの net_read_timeout フラグと net_write_timeout フラグの値を変更して、エラーを防ぐこともできます。これらのフラグに使用可能な値の詳細については、データベース フラグを構成するをご覧ください。 マネージド インポート移行の |
| 最初のデータの移行は成功したが、データが複製されていない。 | 根本原因の一つとして、ソース データベースでレプリケーション フラグが定義されているため、データベースの一部またはすべての変更が複製されていない可能性があります。
プライマリ インスタンスで |
| 最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。 | 次の方法をお試しください。
|
mysqld check failed: data disk is full. |
レプリカ インスタンスのデータディスクに空き容量がありません。 レプリカ インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。 |
レプリケーション ログの確認
レプリケーションの設定を確認したときに、ログが生成されています。
これらのログは次の手順で確認できます。
Google Cloud コンソールでログビューアに移動します。
- [インスタンス] プルダウンから Cloud SQL レプリカを選択します。
replication-setup.logログファイルを選択します。
Cloud SQL レプリカが外部サーバーに接続できない場合は、次の点を確認してください。
- 外部サーバー上のすべてのファイアウォールが、Cloud SQL レプリカの送信 IP アドレスからの接続を受け入れるように構成されている。
- SSL / TLS 構成が正しく行われている。
- 正しいレプリケーション ユーザー、ホスト、パスワードを使用している。
次のステップ
- インスタンスの更新の詳細を確認する。
- レプリカの管理について学習する。
- インスタンスのモニタリングについて確認する。
- Cloud SQL レプリカの昇格について確認する。