Data Transmission Service (DTS) を使用して、Google Cloud SQL for MySQL インスタンスから ApsaraDB RDS for MySQL インスタンスに、最小限のダウンタイムでデータを移行します。 DTS は、スキーマ移行、完全データ移行、および増分データ移行をサポートしています。
このガイドでは、次の内容について説明します:
-
ソースデータベースと移行先データベースの両方の前提条件と制限事項の確認
-
Google Cloud SQL for MySQL でのバイナリロギングの設定 (増分移行に必要)
-
DTS 移行タスクの作成と実行
-
移行後のクリーンアップの完了
前提条件
開始する前に、次の要件を満たしていることを確認してください:
ソース: Google Cloud SQL for MySQL
-
インスタンスでパブリックアクセスが有効になっており、パブリックエンドポイントとポートが利用できること
-
インスタンスに特権アカウントが作成されていること
詳細については、「Google Cloud SQL for MySQL のドキュメント」をご参照ください。
移行先: ApsaraDB RDS for MySQL
-
ApsaraDB RDS for MySQL インスタンスが作成されていること。 詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。
-
読み取りおよび書き込み権限を持つアカウントが作成されていること。 詳細については、「ApsaraDB RDS for MySQL インスタンスのデータベースとアカウントの作成」をご参照ください。
制限事項
-
スキーマ移行はイベントをサポートしていません。
-
DTS は
round(column,precision)関数を使用して FLOAT および DOUBLE 列の値を読み取ります。 精度が指定されていない場合、FLOAT 値は 38 ビット精度、DOUBLE 値は 308 ビット精度を使用します。 移行前に、これらの精度レベルが要件を満たしていることを確認してください。 -
オブジェクト名マッピングがオブジェクトに適用されている場合、それに依存する他のオブジェクトは移行に失敗する可能性があります。
[増分データ移行のみ:]
-
Google Cloud SQL for MySQL インスタンスでバイナリロギングが有効になっている必要があります。
-
binlog_formatパラメーターはrowに設定する必要があります。 -
MySQL 5.6 以降の場合:
binlog_row_imageパラメーターはfullに設定する必要があります。 -
増分移行中にソースインスタンスでクロスホスト移行または再構築が発生した場合、バイナリログファイルの ID が乱れ、増分データが失われる可能性があります。
これらのパラメーターの変更手順については、「Google Cloud SQL for MySQL のドキュメント」をご参照ください。
増分移行のためのバイナリロギングの設定
完全データ移行のみを実行する場合は、このセクションをスキップしてください。
増分データ移行 (CDC) の場合は、Google Cloud SQL for MySQL インスタンスでバイナリロギングを有効にし、次のパラメーターを設定します:
| パラメーター | 必須値 | 理由 |
|---|---|---|
binlog_format |
ROW |
行レベルの変更をキャプチャし、正確なレプリケーションを保証します |
binlog_row_image |
FULL |
MySQL 5.6 以降で必須です。完全な行イメージをキャプチャすることで、DTS が変更を再構築できるようになります |
Google Cloud SQL には、バイナリロギングを有効にするための組み込みオプションがあります。 Google Cloud コンソールで、Cloud SQL インスタンスの設定に移動し、[Backups] セクションの [Binary logging] を有効にします。
データの移行
DTS は、過去 7 日以内に実行されていた異常な移行タスクを自動的に再開します。 その結果、ソースデータベースのデータが、すでに移行先インスタンスに書き込まれているサービスデータを上書きする可能性があります。 移行が完了したら、REVOKE ステートメントを実行して、ApsaraDB RDS for MySQL インスタンスに対する DTS アカウントの書き込み権限を取り消してください。
ステップ 1: データ移行ページへの移動
次のいずれかの方法を使用します:
DTS コンソール
-
DTS コンソールにログインします。
-
左側メニューで、[データ移行] をクリックします。
-
左上隅で、移行インスタンスがあるリージョンを選択します。
Data Management Service (DMS) コンソール
手順は DMS コンソールのモードとレイアウトによって異なる場合があります。 詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。
-
DMS コンソールにログインします。
-
上部メニューで、[データ + AI] > [DTS (DTS)] > [データ移行] にポインターを合わせます。
-
[データ移行タスク] の右側にあるドロップダウンリストから、リージョンを選択します。
ステップ 2: ソースデータベースと移行先データベースの設定
[タスクの作成] をクリックします。 タスク設定ページで、次の項目を入力します:
ソースデータベースと移行先データベースを設定した後、次に進む前にページの上部に表示される [制限事項] を確認してください。 これらの制限事項を無視すると、タスクが失敗したり、データが不整合になったりする可能性があります。
[ソースデータベース]
| パラメーター | 値 |
|---|---|
| [既存のDMSデータベースインスタンスの選択] | 既存のインスタンスを選択するか、手動で設定します |
| [データベースタイプ] | MySQL |
| [アクセス方法] | パブリック IP アドレス |
| [インスタンスリージョン] | ソースインスタンスに最も近いリージョン |
| [ドメイン名または IP] | Google Cloud SQL インスタンスのパブリック IP アドレス。 確認するには、Cloud SQL インスタンスの左側メニューで [接続] をクリックします。 [概要] タブの [ネットワーキング] で、[パブリック IP アドレス] の値をコピーします。 |
| [ポート] | 3306 (デフォルト) |
| [データベースアカウント] | ソースインスタンスの特権アカウント |
| [データベースパスワード] | アカウントのパスワード |
[宛先データベース]
| パラメーター | 値 |
|---|---|
| [既存のDMSデータベースインスタンスの選択] | 既存のインスタンスを選択するか、手動で設定します |
| [データベースタイプ] | MySQL |
| [アクセス方法] | Alibaba Cloud インスタンス |
| [インスタンスリージョン] | 移行先 RDS インスタンスのリージョン |
| [Alibaba Cloud アカウント間でのデータレプリケーション] | いいえ |
| [RDS インスタンス ID] | 移行先の ApsaraDB RDS for MySQL インスタンスの ID |
| [データベースアカウント] | 読み取りおよび書き込み権限を持つアカウント |
| [データベースパスワード] | アカウントのパスワード |
| [暗号化] | [非暗号化] または [SSL 暗号化] を選択します。 SSL 暗号化を使用する場合は、まず RDS インスタンスで SSL を有効にする必要があります。 詳細については、「クラウド証明書を使用した SSL 暗号化の有効化」をご参照ください。 |
ステップ 3: 接続テスト
[接続テストと次へ] をクリックします。
DTS は両方のデータベースにアクセスする必要があります。 ソースデータベースに IP アドレスホワイトリストが設定されている場合は、DTS サーバーの CIDR ブロックをホワイトリストに追加します。 詳細については、「DTS サーバーの CIDR ブロックの追加」をご参照ください。
DTS サーバーの CIDR ブロックをデータベースのホワイトリストまたは ECS のセキュリティグループルールに追加すると、セキュリティリスクが生じる可能性があります。 続行する前に、強力な認証情報の適用、公開ポートの制限、API 呼び出しの監査、ホワイトリストルールの定期的な確認などの予防措置を講じてください。 または、Express Connect、VPN Gateway、または Smart Access Gateway を使用してソースデータベースを DTS に接続します。
ステップ 4: 移行するオブジェクトの選択
次のパラメーターを設定します:
[移行タイプ]
要件に応じて選択します:
-
完全移行のみ: [スキーマ移行] と [完全データ移行] を選択します。 データの整合性を確保するため、移行中はソースデータベースにデータを書き込まないことを推奨します。
-
最小限のダウンタイムでの移行: [スキーマ移行]、[完全データ移行]、および [増分データ移行] を選択します。
[スキーマ移行] を選択しない場合は、開始前に移行先データベースとテーブルを手動で作成し、[選択したオブジェクト] でオブジェクト名マッピングを有効にする必要があります。
[増分データ移行] を選択しない場合は、移行中にソースデータベースへのデータの書き込みを避けてください。
[競合テーブルの処理モード]
| オプション | 動作 |
|---|---|
| [事前チェックしてエラーを報告] | ソースと移行先で同じ名前のテーブルがあるかどうかをチェックします。 競合がある場合、タスクは事前チェックに失敗します。 競合するテーブルの名前を変更するには、オブジェクト名マッピングを使用します。 詳細については、「オブジェクト名のマッピング」をご参照ください。 |
| [エラーを無視して続行] | 名前の競合に関する事前チェックをスキップします。 完全移行中は、移行先の既存のレコードは保持されます。 増分移行中は、既存のレコードは上書きされます。 スキーマが異なる場合、特定の列のみが移行されたり、タスクが失敗したりすることがあります。 |
その他のパラメーター
| パラメーター | 説明 |
|---|---|
| [ソースデータベースのトリガーを移行する方法] | 要件に応じて方法を選択します。 [スキーマ移行] が選択されている場合にのみ設定できます。 詳細については、「ソースデータベースからのトリガーの同期または移行」をご参照ください。 |
| [移行評価の有効化] | [はい]alert notification settings に設定すると、DTS はソースと移行先のスキーマが移行要件 (インデックス長、ストアドプロシージャ、依存テーブル) を満たしているかどうかをチェックします。 [スキーマ移行] が選択されている場合にのみ設定可能です。 結果は事前チェックの結果には影響しません。 |
| [宛先インスタンスでのオブジェクト名の大文字化] | 移行先のデータベース名、テーブル名、列名の大文字/小文字を制御します。 デフォルト: [DTS のデフォルトポリシー]。 詳細については、「移行先インスタンスでのオブジェクト名の大文字/小文字の指定」をご参照ください。 |
| [ソースオブジェクト] | 移行するオブジェクトを選択し、 |
| [選択したオブジェクト] | オブジェクトを右クリックして名前を変更するか、行をフィルタリングするための WHERE 条件を設定します。 [一括編集] をクリックすると、一度に複数のオブジェクトの名前を変更できます。 詳細については、「オブジェクト名のマッピング」および「フィルター条件の指定」をご参照ください。 |
ステップ 5: 詳細設定の構成
[次へ: 詳細設定] をクリックします。
データ検証設定
移行後のデータの整合性を検証するには、データ検証タスクを設定します。 詳細については、「データ検証タスクの設定」をご参照ください。
詳細設定
| パラメーター | 説明 |
|---|---|
| [タスクスケジューリング用の専用クラスター] | デフォルトでは、DTS はタスクを共有クラスターにスケジュールします。 専用クラスターを使用するには、まず専用クラスターを購入する必要があります。 詳細については、「DTS 専用クラスターとは」をご参照ください。 |
| [Set Alerts] | タスクの失敗やレイテンシーがしきい値を超えた場合にアラートを設定します。 詳細については、「モニタリングとアラートの設定」をご参照ください。 |
| [ソーステーブルで生成されたオンライン DDL ツールのテンポラリテーブルを移行先データベースにコピーします。] | オンライン DDL 操作 (DMS または gh-ost のみ) からのテンポラリテーブルの処理を制御します。 重要
pt-online-schema-change はサポートされておらず、タスクが失敗する原因となります。 |
| [接続失敗時の再試行時間] | 接続失敗時に、DTS がタスクを失敗と見なすまで再試行する時間。 範囲: 10~1,440 分。 デフォルト: 720 分。 30 以上に設定してください。 複数のタスクが同じソースまたは移行先を共有する場合、最短の再試行時間が適用されます。 |
| [その他の問題に対する再試行時間] | DTS が失敗した DDL または DML 操作を再試行する時間。 範囲: 1~1,440 分。 デフォルト: 10 分。 10 より大きい値に設定してください。 [接続失敗時の再試行時間] より短くする必要があります。 |
| [完全データ移行のスロットリングを有効にする] | 完全移行中に、ソースデータベースへの 1 秒あたりのクエリ数 (QPS)、1 秒あたりの行数 (RPS)、および移行速度 (MB/s) を制限します。 [完全データ移行] が選択されている場合にのみ利用可能です。 |
| [増分データ移行のスロットリングを有効にする] | 増分移行中に、RPS と移行速度 (MB/s) を制限します。 [増分データ移行] が選択されている場合にのみ利用可能です。 |
| [環境タグ] | 任意。 移行タスクに環境ラベルをタグ付けします。 |
| [ETLの設定] | 抽出、変換、ロード (ETL) 機能を有効にして、移行中にデータを処理します。 詳細については、「データ移行またはデータ同期タスクでの ETL の設定」をご参照ください。 |
| [順方向および逆方向タスクのハートビートテーブルに対する SQL 操作を削除するかどうか] | DTS がハートビートテーブルに対する SQL 操作をソースデータベースに書き込むかどうかを制御します。 [はい] を選択すると書き込みは防止されますが、移行のレイテンシーが表示される場合があります。 [いいえ] を選択すると書き込みが有効になりますが、ソースの物理バックアップとクローン作成に影響する可能性があります。 |
ステップ 6: 事前チェックの実行
[次へ: タスク設定を保存して事前チェック] をクリックします。
このタスクの API パラメーターを確認するには、[次へ: タスク設定を保存して事前チェック] にポインターを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。
移行タスクを開始する前に、DTS は事前チェックを実行します。 事前チェックが完了したら、次のようにします:
-
合格項目: 対応は不要です。
-
失敗項目: 失敗した項目の横にある [詳細の表示] をクリックします。 問題を修正してから、[再事前チェック] をクリックします。
-
アラート項目:
-
アラートを無視できない場合: [詳細の表示] をクリックして問題を修正し、事前チェックを再実行します。
-
アラートを無視できる場合: [アラート詳細の確認] > [無視] > [OK] > [再事前チェック] をクリックします。 アラートを無視すると、データの不整合が発生する可能性があることにご注意ください。
-
ステップ 7: 移行インスタンスの購入
[成功率] が [100%] に達するまで待ってから、[次へ: インスタンスの購入] をクリックします。
[インスタンスの購入] ページで、次の項目を設定します:
| パラメーター | 説明 |
|---|---|
| [リソースグループ] | 移行インスタンスのリソースグループ。 デフォルト: [デフォルトリソースグループ]。 詳細については、「リソース管理とは」をご参照ください。 |
| [インスタンスクラス] | 移行速度はインスタンスクラスによって異なります。 データ量と時間の要件に基づいて選択してください。 詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。 |
ステップ 8: 移行の開始
-
[Data Transmission Service (従量課金) のサービス規約] を読み、チェックボックスにチェックを入れます。
-
[購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。
[データ移行] ページで進捗状況を確認できます。
次のステップ
移行タスクが完了したら、次の手順を実行してください:
-
REVOKEステートメントを実行して、ApsaraDB RDS for MySQL インスタンスに対する DTS アカウントの書き込み権限を取り消してください。 これにより、DTS がタスクを再開した場合の意図しない上書きを防ぐことができます。 -
データ検証機能を使用して、データの整合性を検証してください。 詳細については、「データ検証タスクの設定」をご参照ください。
-
アプリケーションの接続文字列を更新して、ApsaraDB RDS for MySQL インスタンスを指すようにしてください。