Data Transmission Service:RDS for MySQL から Lindorm へのデータ移行

移行元データベースの制限事項

• 移行元データベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度に影響が出ます。

• 移行対象のテーブルには、プライマリキーまたは一意キーが必要です。これらがない場合、移行先に重複データが発生する可能性があります。

• テーブルレベルで移行し、オブジェクトを編集する場合 (テーブル名や列名のマッピングなど)、1 つのタスクでサポートされるテーブル数は最大 1,000 です。この制限を超える場合は、テーブルを複数のタスクに分割するか、データベース全体を移行するようにタスクを設定してください。

• 移行元が MySQL 8.0.23 以降で、データに非表示列が含まれている場合、DTS はそれらの列を読み取ることができず、データ損失が発生します。移行前に非表示列を表示するには、次のコマンドを実行してください：

  ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

  詳細については、「Invisible Columns」をご参照ください。明示的なプライマリキーを持たないテーブルは、自動的に非表示のプライマリキーを生成します。これらも表示する必要があります。詳細については、「Generated Invisible Primary Keys」をご参照ください。

[増分データ移行のみ：]

• バイナリログを有効にし、以下の設定を行っておく必要があります。これらがない場合、事前チェックが失敗し、タスクを開始できません。バイナリログ保持要件：DTS がバイナリログを読み取る前に削除された場合、タスクが失敗するか、データ不整合が発生する可能性があり、DTS のサービスレベルアグリーメント (SLA) が適用されないことがあります。

  • ApsaraDB RDS for MySQL：最低 3 日間 (7 日間を推奨)。詳細については、RDS インスタンスのバイナリログファイルを自動削除するパラメータの設定をご参照ください。

  • セルフマネージド MySQL：最低 7 日間。

  パラメータ	必要な値	設定しない場合の影響
  binlog_format	ROW	STATEMENT または MIXED に設定すると、移行先でデータ不整合が発生する可能性があります。
  binlog_row_image	full	部分的な行イメージでは、不完全なデータレプリケーションが発生する可能性があります。
  log_slave_updates	ON	デュアルプライマリクラスターのセルフマネージド MySQL にのみ必要です。これがない場合、DTS はすべてのバイナリログを取得できません。

完全データ移行のみ：

• 完全データ移行中は、移行元で DDL 操作を実行しないでください。DDL 操作により、タスクが失敗する可能性があります。

  完全データ移行中、DTS は移行元データベースにクエリを実行し、メタデータロックを作成します。これにより、移行元での DDL 操作がブロックされる可能性があります。

• [全量データ移行] のみを選択した場合、ソースに新しいデータを書き込まないでください。 移行全体を通してソースとデスティネーションの同期を維持するには、[全量データ移行] と [増分データ移行] の両方を選択してください。

• 移行元 RDS for MySQL インスタンスで EncDB 機能が有効になっている場合、完全データ移行を実行できません。

  透過的データ暗号化 (TDE) が有効になっている RDS for MySQL インスタンスは、スキーマ移行、完全データ移行、および増分データ移行をサポートします。

その他の制限事項

• Lindorm へのスキーマ移行は、Lindorm 自体のスキーマ作成機能に依存します。

• Lindorm の非プライマリキー列のインデックスには、デフォルトの列数制限があります。列数がこの制限を超える場合、DTS はスキーマ移行中にそのようなインデックスを作成できません。このようなインデックスを使用するには、手動で作成してください。詳細については、ALTER SYSTEM をご参照ください。

• INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および外部キーオブジェクトの移行はサポートされていません。

• BIT データ型の移行はサポートされていません。

• プライマリキーフィールドのみを移行することはできません。データには少なくとも 1 つの非プライマリキーフィールドが含まれている必要があります。

• データは Lindorm インスタンスのワイドテーブルエンジンにのみ書き込むことができます。

• VARBINARY 型の空文字列は、DTS と Lindorm の両方で null として扱われます。

• 移行先の DECIMAL フィールドの精度が移行元と異なる場合、タスクは失敗します。

• Lindorm に書き込まれるデータは、「データリクエストの制限」に準拠している必要があります。これらの制限を超えるリクエストがあると、タスクが失敗します。

• 完全データ移行では並行 INSERT 操作が実行されるため、移行先でテーブルスペースの断片化が発生します。完全初期化の完了後、移行先のテーブルスペースは移行元よりも大きくなります。

• 移行中に、移行元の移行対象オブジェクトで pt-online-schema-change などのオンライン DDL ツールを実行しないでください。これにより、移行が失敗します。

• 移行中に DTS 以外の手段で移行先にデータが書き込まれると、データ不整合が発生する可能性があります。

• バイナリログ変更操作によって生成されたデータ (物理バックアップから復元されたデータやカスケード操作など) は、移行先に移行されません。

  そのようなデータが移行されない場合、ビジネスに影響がない限り、完全データ移行を再度実行できます。

• DTS インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内に復旧を試みます。復旧操作には、インスタンスの再起動や DTS インスタンスパラメータ (データベースパラメータではない) の調整が含まれる場合があります。調整される可能性のあるパラメータについては、詳細については、インスタンスパラメータの変更をご参照ください。

特殊なケース

セルフマネージド MySQL 移行元：

• 移行タスクの実行中に移行元でプライマリ/セカンダリ スイッチオーバーが発生した場合、タスクは失敗します。

• DTS は定期的に移行元で CREATE DATABASE IF NOT EXISTS `test` を実行して、バイナリログファイルの位置を進めます。

• 移行元で長期間 DML 操作が実行されない場合、表示される移行遅延が不正確になる可能性があります。移行元で DML 操作を実行して、遅延を更新してください。移行対象オブジェクトとしてデータベース全体を選択した場合は、毎秒更新を受け取るハートビートテーブルを作成してください。

ApsaraDB RDS for MySQL 移行元：

• [増分データ移行のみ：]読み取り専用 RDS for MySQL V5.6 インスタンスは、トランザクションログを記録しないため、移行元として使用できません。

• DTS は定期的に移行元で CREATE DATABASE IF NOT EXISTS `test` を実行して、バイナリログファイルの位置を進めます。

ステップ 1：データ移行ページを開く

次のいずれかの方法を使用します：

ステップ 2：移行元と移行先のデータベースを設定する

1. [タスクの作成] をクリックします。

2. 次のパラメータを使用して、移行元と移行先のデータベースを設定します：

   移行元データベース：

   パラメータ	説明
   [タスク名]	DTS タスクの名前。DTS は自動的に名前を生成します。タスクを識別しやすくするために、わかりやすい名前を指定してください。名前は一意である必要はありません。
   [既存の接続を選択]	移行元インスタンスが既に DTS に登録されている場合は、ドロップダウンリストから選択してください。DTS がデータベースパラメータを自動的に入力します。それ以外の場合は、以下のパラメータを手動で設定してください。
   [データベースタイプ]	[MySQL] を選択します。
   [アクセス方法]	[Alibaba Cloud インスタンス] を選択します。
   [インスタンスリージョン]	移行元 RDS for MySQL インスタンスが存在するリージョンを選択します。
   [Alibaba Cloud アカウント間でデータをレプリケート]	ソースが同じ Alibaba Cloud アカウントにある場合は、[いいえ] を選択します。
   [RDS インスタンス ID]	移行元 RDS for MySQL インスタンスの ID を選択します。
   [データベースアカウント]	移行元インスタンスのデータベースアカウントを入力します。必要な権限については、データベースアカウントの権限をご参照ください。
   [データベースパスワード]	データベースアカウントのパスワードを入力します。
   [暗号化]	[非暗号化] または [SSL 暗号化] を選択します。 SSL 暗号化を使用するには、まず RDS for MySQL インスタンスで有効にする必要があります。 詳細については、「クラウド証明書を使用して SSL 暗号化を有効にする」をご参照ください。

   移行先データベース：

   パラメータ	説明
   [既存の接続を選択]	移行先インスタンスが既に DTS に登録されている場合は、ドロップダウンリストから選択してください。それ以外の場合は、以下のパラメータを手動で設定してください。
   [データベースタイプ]	[Lindorm] を選択します。
   [アクセス方法]	[Alibaba Cloud インスタンス] を選択します。
   [インスタンスリージョン]	移行先 Lindorm インスタンスが存在するリージョンを選択します。
   [インスタンス ID]	移行先 Lindorm インスタンスの ID を選択します。
   [データベースアカウント]	移行先インスタンスのデータベースアカウントを入力します。
   [データベースパスワード]	データベースアカウントのパスワードを入力します。

3. [接続をテストして続行] をクリックします。

   DTS サーバーの CIDR ブロックが、送信元データベースと宛先データベースのセキュリティ設定に追加されていることを確認してください。 詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。 送信元または宛先が自己管理型データベースで、[Alibaba Cloud インスタンス] 経由でアクセスされない場合は、[DTS サーバーの CIDR ブロック] ダイアログボックスで [接続テスト] をクリックします。

ステップ 3：移行対象オブジェクトを設定する

1. [オブジェクトの設定] ページで、次のパラメーターを設定します。

   [増分データ移行] を選択しない場合は、データの一貫性を確保するために、移行中に移行元に新しいデータを書き込まないでください。

   パラメータ	説明
   [移行タイプ]	1 回限りの移行の場合は、[完全データ移行] を選択します。移行中、移行先を移行元と同期し続けるには、[完全データ移行] と [増分データ移行] の両方を選択します。
   [競合するテーブルの処理モード]	デフォルト値のままにします。
   [移行先インスタンスでのオブジェクト名の大文字化]	移行先のデータベース名、テーブル名、カラム名の大文字/小文字を制御します。デフォルトは [DTS デフォルトポリシー] です。詳細については、「移行先インスタンスのオブジェクト名の大文字/小文字を指定する」をご参照ください。
   [移行元オブジェクト]	移行するデータベースまたはテーブルを選択し、 をクリックして [選択済みオブジェクト] に移動します。
   [選択されたオブジェクト]	移行先 Lindorm インスタンスのデータベース名、テーブル名、または列名が移行元と異なる場合は、オブジェクト名のマッピングを使用します。詳細については、「オブジェクト名のマッピング」をご参照ください。行レベルのフィルターを適用するには、テーブルを右クリックして WHERE 条件を指定します。詳細については、フィルター条件の指定をご参照ください。増分移行に含める SQL 操作を選択するには、オブジェクトを右クリックして操作を選択します。

2. [次へ: 詳細設定] をクリックし、次の項目を設定します。

   パラメータ	説明
   [タスクスケジューリング専用クラスター]	デフォルトでは、DTS は共有クラスターを使用します。安定性を向上させるには、専用クラスターを購入してください。詳細については、DTS 専用クラスターとはをご参照ください。
   [接続失敗時の再試行時間]	移行元または移行先が使用できない場合に DTS が再試行する期間。有効な値：10～1,440 分。デフォルト：720 分。これを 30 分以上に設定してください。DTS がこの期間内に再接続した場合、タスクを再開します。そうでない場合、タスクは失敗します。注：複数のタスクが同じ移行元または移行先を共有する場合、最後に設定された値が適用されます。再試行中は DTS インスタンスに課金されます。
   [その他の問題の再試行時間]	DTS が失敗した DDL または DML 操作を再試行する期間。有効値: 1～1,440 分。デフォルト値: 10 分。10 分より大きい値を設定することを推奨します。この値は [失敗した接続の再試行時間] より小さくする必要があります。
   [完全データ移行のスロットリングを有効化]	フルデータ移行を調整して、移行元と移行先の負荷を軽減します。[移行元データベースへの 1 秒あたりのクエリ数 (QPS)]、[フルデータ移行の RPS]、および [フルデータ移行のデータ移行速度 (MB/s)] を設定します。[フルデータ移行] が選択されている場合にのみ利用可能です。
   [増分データ移行のスロットリングを有効化]	増分移行を調整します。[増分データ移行の RPS] と [増分移行のデータ移行速度 (MB/s)] を設定します。[増分データ移行] が選択されている場合にのみ利用可能です。
   [環境タグ]	インスタンスを識別するタグを選択します。この例ではタグは不要です。
   [順方向および逆方向タスクのハートビートテーブルの SQL 操作を削除するかどうか]	インスタンスの実行中に DTS がハートビートテーブルの SQL 操作をソースに書き込むかどうかを制御します。 書き込みをスキップするには、[はい]アラート通知設定 を選択します (DTS インスタンスにレイテンシー値が表示される場合があります)。 ハートビート操作を書き込むには、[いいえ] を選択します (これにより、ソースの物理バックアップとクローニングに影響する可能性があります)。
   [ETL の設定]	コードエディターで抽出、変換、ロード (ETL) ルールを設定するには、[はい] を選択します。詳細については、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。[いいえ] を選択して ETL 設定をスキップします。
   [監視とアラート]	タスクが失敗した場合、または移行レイテンシがしきい値を超えた場合にアラートを受信するには、[はい] を選択します。アラートのしきい値と通知設定を構成します。詳細については、「DTS タスク作成時のモニタリングとアラートの設定」をご参照ください。

ステップ 4：事前チェックを実行する

[次へ: タスク設定を保存して事前チェック] をクリックします。

このタスク設定の OpenAPI パラメーターを表示するには、次に進む前に [次へ: タスク設定の保存と事前チェック] にポインターを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。

DTS は移行を開始する前に事前チェックを実行します。事前チェックが失敗した場合：

• 失敗した各項目の横にある[詳細を表示]をクリックして問題を解決してから、[再度事前チェック]をクリックします。

• 事前チェックアラートを無視できる場合は、[アラート詳細の確認] をクリックし、ダイアログボックスで [無視] をクリックし、[OK] をクリックしてから [再度事前チェック] をクリックします。アラートを無視すると、データ不整合が発生する可能性があります。

ステップ 5：インスタンスを購入して開始する

1. [成功率] が [100%] に達するまで待ち、[次へ: インスタンスの購入] をクリックします。

2. [インスタンスの購入] ページで、次の項目を設定します：

   パラメータ	説明
   [リソースグループ]	移行インスタンスのリソースグループ。 デフォルト: [デフォルトのリソースグループ]。 詳細については、「リソース管理とは」をご参照ください。
   [インスタンスクラス]	DTS は移行速度が異なるインスタンスクラスを提供します。ビジネスシナリオに基づいてインスタンスクラスを選択できます。詳細については、データ移行インスタンスのインスタンスクラスをご参照ください。

3. [データ転送サービス (従量課金) サービス規約]を読み、同意して、[購入して開始]をクリックします。確認メッセージで[OK]をクリックします。

[データ移行] ページでタスクの進捗を表示できます。

データ移行タスクで増分データを移行できない場合、タスクは自動的に停止します。[完了] ステータスが表示されます。

データ移行タスクで増分データを移行できる場合、タスクは自動的に停止しません。増分データ移行タスクは継続的に実行されます。[実行中] ステータスが表示されます。