ApsaraDB RDS for MySQL の X-Engine を使用するインスタンスを、論理移行方式で PolarDB for MySQL クラスターに移行します。移行自体は無料です — 料金が発生するのは、移行先の PolarDB for MySQL クラスターのみです。
前提条件
開始する前に、以下の点をご確認ください。
本移行ソリューションでは論理移行方式を使用します。ソースとなる ApsaraDB RDS for MySQL インスタンスのバージョンは問いません。
ソースインスタンスにトリガーが設定されている場合、事前にトリガーを削除したうえで、[続行] をクリックして進めてください。または、[キャンセル] をクリックし、Data Transmission Service (DTS) コンソールで手動でデータ同期タスクを作成してください。詳細については、「トリガーを含むソースデータベース向けのデータ同期タスクの設定」をご参照ください。
ソースインスタンスでデータベースプロキシ (安全モード) が有効になっている場合は、特権アカウントを作成するか、ネットワーク接続モードを高性能モードに切り替えます。 詳細については、「アカウントの作成」および「ネットワーク接続モードの切り替え」をご参照ください。
制限事項
| 制限事項 | 詳細 |
|---|---|
| MySQL バージョン | 同じかそれ以降の MySQL バージョンにのみ移行できます。たとえば、ApsaraDB RDS for MySQL 5.7 インスタンスを PolarDB for MySQL 5.6 クラスターに移行することや、ApsaraDB RDS for MySQL 8.0.2 インスタンスを PolarDB for MySQL 8.0.1 クラスターに移行することはサポートされていません。 |
| リージョン間移行 | サポートされていません。 |
| IPv6 | エンドポイントを使用したスイッチオーバーでは、IPv6 アドレスはサポートされていません。 |
| パラメーター変更 | 移行中にソースインスタンスのパラメーターを変更することはできません。 |
| 移行可能なオブジェクトタイプ | 移行できるのは、データベース、テーブル、ビュー、ストアドプロシージャ、および関数の 5 種類のみです。 |
| テーブル同期制限 | 単一のデータ同期タスクは、最大 1,000 個のテーブルをサポートします。1,000 個を超えるテーブルの場合は、複数のタスクをバッチで実行するか、データベース全体を同期してください。 |
| プライマリキー要件 | 同期するテーブルには、すべてのユニークフィールドを含む PRIMARY KEY または一意制約が必要です。これがない場合、ターゲットデータベースに重複レコードが含まれる可能性があります。 |
| バイナリロギング | ソースインスタンスでバイナリロギングを有効にし、binlog_row_image を full に設定する必要があります。詳細については、「インスタンスパラメーターの変更」をご参照ください。 |
| バイナリログ保持 | 増分データ同期の場合のみ: バイナリログを少なくとも 24 時間保持します。フルおよび増分データ同期の場合: 少なくとも 7 日間保持します。完全同期が完了した後、保持期間を 24 時間以上に短縮できます。詳細については、「バイナリログファイルの管理」をご参照ください。 |
注意事項
SSL の一貫性: ソースと送信先のエンドポイント間で、SSL ステータスは一貫している必要があります。
ソースインスタンスで SSL が有効化されており、エンドポイントによるスイッチオーバーを利用する場合、送信先の PolarDB クラスターでも SSL を有効化する必要があります。
ソースインスタンスで SSL が無効化されている場合、送信先の PolarDB クラスターでも SSL を無効化してください。
完全データ同期中は、DTS がソースおよびターゲットデータベースの両方から読み取り・書き込みを行うため、両サーバーの負荷が増加する可能性があります。
完全データ同期中は、同時 INSERT 操作によりテーブルの断片化が発生するため、完全データ同期完了後のターゲットデータベースの表領域は、ソースデータベースよりも大きくなります。
論理移行方式を使用する際は、DTS タスクを手動でリリースしないでください。
完全データ同期中は、送信先の PolarDB クラスターは 作成中 のステータスになります。
課金
移行自体は無料です。課金対象となるのは、移行先の PolarDB for MySQL クラスターのみです。
クラスターのコストを最適化するには、クラスター作成時にホットスタンバイストレージクラスター機能の有効化の可否を検討し、適切なストレージタイプを選択してください。
データ移行
一般的な移行プロシージャについては、「手順」をご参照ください。以下の X-Engine 固有の注意事項が各ステップに適用されます。
ステップ 1：ソースインスタンスからのデータ移行
送信先の PolarDB for MySQL クラスターを作成する際は、以下の点にご注意ください。
PolarDB for MySQL Enterprise Edition のみが InnoDB および X-Engine の両方をサポートしています。[データベースエディション] を Enterprise Edition に、[ストレージエンジン] を InnoDB & X-Engine に設定し、X-Engine のメモリ使用量を構成してください。詳細については、「ステップ 1：ソース ApsaraDB RDS for MySQL インスタンスからのデータ移行」をご参照ください。
課金方法を 従量課金 に設定してください。従量課金クラスターは、データ移行中は課金されません。
ステップ 2：サービスのスイッチオーバー
移行を開始した後、送信先の PolarDB クラスターで作成されたテーブルが X-Engine を使用していることを確認してください。InnoDB が使用されている場合は、チケットを送信 してください。
スイッチオーバー中および移行完了前は、データが PolarDB クラスターからソース ApsaraDB RDS for MySQL インスタンスへ逆方向に同期されます。このフェーズでは、双方向のテーブル作成に X-Engine が必要です。
スイッチオーバー完了後、送信先の PolarDB クラスターにおけるデフォルトストレージエンジンは InnoDB に変更されます。X-Engine を使用するテーブルを作成するには、DDL 文で engine=xengine を明示的に指定してください。例：
CREATE TABLE my_table (id INT PRIMARY KEY, name VARCHAR(100)) engine=xengine;すべての新規テーブルで X-Engine をデフォルトエンジンとするには、PolarDB コンソールで default_storage_engine パラメーターを xengine に設定してください。
default_storage_engine を変更した後は、変更を有効にするためにクラスター内のすべてのノードを再起動する必要があります。再起動がサービスに影響を与えないことを事前に確認してから、作業を進めてください。
詳細については、「ステップ 2：サービスのスイッチオーバー」をご参照ください。
ステップ 3：移行の完了
移行完了後も、デフォルトストレージエンジンは InnoDB のままです。X-Engine を使用するには、DDL 文で engine=xengine を指定するか、default_storage_engine を xengine に設定してください。
詳細については、「ステップ 3：移行の完了」をご参照ください。