PolarDB:ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにクローンする

注意事項

ワンクリッククローニングを使用して PolarDB クラスタにデータを移行する場合、ソース ApsaraDB RDS for MySQL インスタンスの増分データは PolarDB クラスタに同期されません。

背景情報

PolarDB では、ApsaraDB RDS for MySQL インスタンスから PolarDB for MySQL クラスタにデータをクローンできます。ワンクリッククローニング方法を使用して、ソース ApsaraDB RDS インスタンスと同じデータを持つ PolarDB クラスタを作成できます。PolarDB クラスタは、ソース ApsaraDB RDS インスタンスのアカウント、データベース、IP ホワイトリスト、および必須パラメータを保持します。

ソース ApsaraDB RDS for MySQL インスタンスとターゲット PolarDB for MySQL クラスタは、次の要件を満たしている必要があります。

• [すべての Mysql バージョン] を実行し、[すべてのストレージタイプ] を使用するソース ApsaraDB RDS for MySQL インスタンスは、クローンできます。MySQL 5.6、5.7、および 8.0 を実行し、ローカル SSD とクラウドディスクを使用するインスタンスを、ワンクリックで PolarDB for MySQL クラスタにクローンできます。

• ApsaraDB RDS for MySQL インスタンスは、ワンクリックで、[同じまたは異なる Mysql バージョン] を実行する PolarDB for MySQL クラスタにクローンできます。たとえば、ApsaraDB RDS for MySQL 5.6 インスタンスを PolarDB for MySQL 5.6 クラスタ、または PolarDB for MySQL 8.0 クラスタにクローンできます。

物理移行と論理移行の比較

ワンクリッククローニング機能は、物理移行（物理レプリケーション）と論理移行（DTS を介したデータ同期）をサポートしています。

• 物理移行: 物理レプリケーション方式を使用して、ソース ApsaraDB RDS for MySQL インスタンスからターゲット PolarDB for MySQL クラスタに完全データをコピーできます。

• 論理移行: DTS でデータ同期タスクを作成して、ソース ApsaraDB RDS for MySQL インスタンスのスキーマと完全データをターゲット PolarDB for MySQL クラスタに移行できます。

次の表は、物理移行方式と論理移行方式を比較したものです。

次の表は、2 つの移行方式でサポートされている MySQL バージョンとストレージタイプを示しています。

物理移行は、ローカル SSD を使用する High-availability Edition の ApsaraDB RDS for MySQL 5.6 または 5.7 インスタンスを、同じ MySQL バージョンの PolarDB for MySQL クラスタにクローンする場合にのみ使用されます。論理移行は、他の仕様の ApsaraDB RDS for MySQL インスタンスを、同じバージョンまたは異なるバージョンの PolarDB for MySQL クラスタにクローンするために使用されます。

メリット

• クローニング機能は無料です。

• クローニングプロセス中にデータ損失は発生しません。

前提条件

• 物理移行を使用する場合、ソース ApsaraDB RDS インスタンスは次の要件を満たしている必要があります。論理移行はこれらの要件の対象外です。

  • ApsaraDB RDS for MySQL 5.6 の場合、インスタンスのマイナーバージョンは 20190815 以降である必要があります。

  • ApsaraDB RDS for MySQL 5.7 の場合、インスタンスのマイナーバージョンは 20200331 以降である必要があります。

  説明

  SHOW VARIABLES LIKE '%rds_release_date%'; 文を実行して、ソース ApsaraDB RDS インスタンスのマイナーバージョンを表示できます。マイナーバージョンが必要なバージョンより古い場合は、マイナーバージョンを最新バージョンにクローンできます。詳細については、「マイナーエンジンバージョンを更新する」をご参照ください。

• ソース RDS インスタンスのテーブルストレージエンジンは、InnoDB または X-Engine である必要があります。

• ソース ApsaraDB RDS for MySQL インスタンスでは、Transparent Data Encryption（TDE）と SSL が無効になっています。詳細については、「TDE」および「SSL」をご参照ください。TDE または SSL が有効になっている場合は、DTS で手動でデータ同期タスクを作成して、ソースインスタンスをターゲット PolarDB クラスタに移行できます。詳細については、「ApsaraDB RDS for MySQL インスタンスから PolarDB for MySQL クラスタにデータを移行する」をご参照ください。

• ApsaraDB RDS for MySQL インスタンスで Database Proxy（セーフモード）が有効になっている場合は、特権アカウントが作成されるか、ApsaraDB RDS for MySQL インスタンスのネットワーク接続モードがパフォーマンス専有型モードに切り替えられます。詳細については、「アカウントを作成する」および「[製品の変更/機能の変更] ApsaraDB RDS インスタンスのネットワーク接続モードがアップグレードされます」をご参照ください。

制限

• ApsaraDB RDS for MySQL インスタンスは、同じまたはそれ以降の MySQL バージョンの PolarDB for 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 クラスタにスペックアップしたりすることはできません。

• 物理移行方式には、次の制限があります。

  • リージョン間のデータ移行はサポートされていません。

  • データ移行中にソース ApsaraDB RDS for MySQL インスタンスのパラメータを構成することはできません。

• 論理移行方式には、次の制限があります。

  • リージョン間のデータ移行はサポートされていません。

  • データ移行中にソース ApsaraDB RDS for PostgreSQL インスタンスのパラメータを構成することはできません。

  • ソース ApsaraDB RDS for PostgreSQL インスタンスには、次の表に示す制限があります。

    項目

    説明

    ソースインスタンスの制限

    同期するテーブルには、PRIMARY KEY または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複するデータレコードが含まれる可能性があります。 同期対象としてテーブルを選択し、テーブルの名前変更や列の名前変更などの編集を行う場合は、1 つのデータ同期タスクで最大 1,000 個のテーブルを同期できます。1,000 個を超えるテーブルを同期するタスクを実行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してテーブルをバッチで同期するか、データベース全体を同期するタスクを構成することをお勧めします。 バイナリロギング: バイナリロギング機能を有効にする必要があります。バイナリロギングを有効にする方法の詳細については、「インスタンスパラメータを変更する」をご参照ください。また、binlog_row_image パラメータを full に設定する必要があります。そうでない場合、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。

  • 次の制限も適用されます。

    項目

    説明

    その他の制限

    データを同期する前に、データ同期がソースデータベースとターゲットデータベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータを同期することをお勧めします。初期完全同期中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 初期完全同期中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。したがって、初期完全同期が完了した後、ターゲットデータベースの使用済み表領域のサイズはソースデータベースのサイズよりも大きくなります。 データベース全体ではなく、1 つ以上のテーブルを同期対象として選択した場合は、データ同期中に gh-ost または pt-online-schema-change を使用してテーブルで DDL 操作を実行しないでください。そうしないと、データが同期されない可能性があります。 DTS のみを使用してターゲットデータベースにデータを書き込む場合は、データ管理（DMS）を使用して、データ同期中にソーステーブルでオンライン DDL 操作を実行できます。詳細については、「テーブルをロックせずにスキーマを変更する」をご参照ください。 データ同期の間に他のソースからのデータがターゲットデータベースに書き込まれると、ソースデータベースとターゲットデータベースの間でデータの不整合が発生します。たとえば、他のソースからのデータがターゲットデータベースに書き込まれている間に DMS を使用してオンライン DDL 文を実行すると、ターゲットデータベースでデータ損失が発生する可能性があります。 デフォルトでは、DTS はデータ同期タスクでターゲットデータベースの FOREIGN KEY 制約を無効にします。したがって、ソースデータベースのカスケード操作や削除操作などはターゲットデータベースに同期されません。

課金ルール

• 物理移行方式には、次の課金ルールが適用されます。

  ソース ApsaraDB RDS for MySQL インスタンスから PolarDB クラスタへのデータ移行は無料です。PolarDB クラスタの購入費用のみが発生します。詳細については、「課金項目の概要」をご参照ください。

• 論理移行方式には、次の課金ルールが適用されます。

  PolarDB クラスタの購入費用と DTS でのデータ同期タスクの作成費用が発生します。ただし、スペックアップ機能は無料トライアル段階です。作成後 30 日以内の同期タスクは無料です。無料トライアルは、仮想ネットワークオペレーター（VNO）アカウントと RAM ユーザーは利用できません。次の表は、論理移行方式の課金ルールを示しています。

  移行オブジェクト	課金ルール
  スキーマ同期と完全同期	タスク作成後 30 日以内の同期タスクは無料です。 30 日を超えると、同期タスクはキャンセルされます。 説明 [データ同期] ページ にアクセスして、同期タスクの残り時間を表示できます。

以下のセクションでは、ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスターにクローンする手順について説明します。

論理移行の事前チェック

ステップ 1: ソース ApsaraDB RDS for MySQL インスタンスからデータを移行する

このステップでは、PolarDB クラスタが作成されます。クラスタには、ソース ApsaraDB RDS for MySQL インスタンスと同じデータが格納されます。

1. PolarDB コンソール にログオンします。

2. 左上隅で、クラスタをデプロイするリージョンを選択します。

3. クラスターの作成 をクリックします。

4. [課金タイプ] として、[サブスクリプション]、[従量課金制]、[サーバーレス] などを選択します。

   • サブスクリプション: 計算ノードはクラスタ作成時に課金され、ストレージスペースは実際の使用量に基づいて時間単位で課金され、アカウントから時間単位で差し引かれます。

   • 従量課金制: 前払い金は不要です。計算ノードとストレージスペースの両方が、実際の使用量に基づいて時間単位で課金され、アカウントから時間単位で差し引かれます。

   • サーバーレス: 前払い金は不要です。計算ノード、ストレージスペース、データベースプロキシなどのリソースは、実際の需要に基づいて動的にスケーリングされ、実際の使用量に応じて課金されます。

5. 次のパラメータを構成します。

   説明

   以下で詳しく説明していないパラメータについては、「クラスタを購入する」の関連セクションをご参照ください。

   パラメータ	説明
   作成方法	[RDS からクローン] を選択します。
   リージョン	ソース ApsaraDB RDS for MySQL インスタンスがデプロイされているリージョン。 説明 ターゲット PolarDB クラスタもこのリージョンにデプロイする必要があります。
   ソース RDS バージョン	ソース RDS インスタンスのエンジンバージョン。[5.6]、[5.7]、または [8.0] を選択できます。
   ソース RDS インスタンス	ソース ApsaraDB RDS for MySQL インスタンス。読み取り専用の ApsaraDB RDS for MySQL インスタンスは表示されません。
   データベースエンジン	ターゲット PolarDB クラスタのデータベースエンジンバージョン。ソース ApsaraDB RDS for MySQL インスタンスと同じバージョンまたは異なるバージョンを選択できます。
   ノード仕様	クラスタのノード仕様。業務要件に基づいてノード仕様を指定できます。ソース ApsaraDB RDS for MySQL インスタンスの仕様と同じかそれ以上の仕様を選択することをお勧めします。PolarDB ノード仕様の詳細については、「PolarDB for MySQL Enterprise Edition の計算ノード仕様」をご参照ください。

6. ページの右上隅で、クラスタ構成を確認し、[期間]、、[自動更新] パラメータを構成します。[期間] パラメータは、サブスクリプション クラスタでのみ使用できます。

7. 利用規約を読んで選択します。[注文の確認] をクリックします。

8. [購入] ページで、注文と支払方法を確認し、[購入] をクリックします。

   説明

   • 支払いが完了したら、10 ～ 15 分待ちます。その後、[クラスタ] ページで新しく作成されたクラスタを表示できます。クラスタ

   • クラスタ内の特定のノードが [作成中] 状態の場合、クラスタはまだ作成中で、使用できません。クラスタは、[実行中] 状態の場合にのみ使用できます。

   • クラスタがデプロイされているリージョンを選択していることを確認してください。そうでない場合、クラスタを表示できません。

9. PolarDB コンソール にログオンし、新しい PolarDB クラスタのステータスを確認します。

   説明

   論理移行方式を使用する場合は、クラスタ ID をクリックして 概要 ページに移動し、移行ステータスを表示します。[RDS 移行] セクションの [ステータス] フィールドが [事前チェック失敗] の場合は、[エラーメッセージ] の指示に従って問題をトラブルシューティングします。

   たとえば、ソース RDS 内にトリガーが存在する場合、事前チェックは失敗し、「RDS インスタンスにトリガーがあります」 というエラーメッセージが表示されます。これを解決するには、ソース RDS からトリガーを削除してから、[移行を続行] をクリックするか、[移行を中止] をクリックして、DTS コンソールで手動で移行タスクを開始します。詳細については、「ソースデータベースにトリガーがある場合の同期または移行ジョブの構成方法」をご参照ください。

   [キャンセル] をクリックして、移行タスクをキャンセルすることもできます。詳細については、「よくある質問」をご参照ください。

ステップ 2: データ同期タスクの詳細を表示する（論理移行の場合のみ）

論理移行方式を使用する場合は、クラスタ ID をクリックして 概要 ページに移動し、移行ステータスを表示します。移行エラー（事前チェックの失敗など）またはその他の例外（レプリケーションの待ち時間が非常に長いなど）が発生した場合は、データ同期タスクの詳細ページに移動して詳細を表示できます。

1. PolarDB コンソール にログオンします。

2. ターゲットクラスタを見つけて、その ID をクリックします。

3. RDS 移行 セクションの 概要 ページで、DTS データ同期タスク の名前をクリックして、DTS コンソール内のデータ同期タスクリストに移動します。

   

4. データ同期タスクを見つけます。事前チェックの失敗の詳細、データ同期タスクの詳細、およびデータ同期タスクログを表示できます。

   

よくある質問

• 「ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにスペックアップする」と「ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにクローンする」の違いは何ですか？

  次の表に違いを示します。

  項目	ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにスペックアップする	ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにクローンする
  増分データ移行または同期がサポートされているかどうか	はい。	いいえ。
  ソースインスタンスの操作が影響を受けるかどうか	いいえ。	いいえ。
  ソースデータベースとターゲットデータベースで異なる MySQL バージョンを使用できるかどうか	はい。	はい。

• ApsaraDB RDS for MySQL インスタンスからデータをクローンすると、ソース ApsaraDB RDS for MySQL インスタンスは影響を受けますか？

  いいえ、データのクローニングはソース ApsaraDB RDS for MySQL インスタンスの実行を中断しませんが、ソースインスタンスのリソースをいくらか消費します。

• 移行をキャンセルするとどうなりますか？

  移行をキャンセルすると、次の影響が発生します。

  • ソースインスタンスからターゲットクラスタへの同期リンクが切断されます。ソースインスタンスはターゲットクラスタに関連付けられなくなります。

  • ターゲットクラスタは読み取り可能および書き込み可能になり、自動的に解放されません。ターゲットクラスタを使用しない場合は、追加費用が発生しないように、できるだけ早くクラスタを解放してください。

  • 移行を手動でキャンセルするときに、クラスタのバイナリロギング機能を無効にするかどうかを指定できます。移行が自動的にキャンセルされた場合、バイナリロギング機能は無効になりません。

    説明

    クラスタのバイナリロギング機能を無効にすると、クラスタの書き込みパフォーマンスがわずかに向上します。バイナリロギング機能を無効にした後も、既存のバイナリログは保持されます。バイナリログを削除するには、まずバイナリログの保存期間を短縮します。バイナリログが自動的に削除されたら、バイナリロギング機能を無効にできます。バイナリロギング機能を無効にすると、クラスタは自動的に再起動します。再起動タスクは 5 分以内に完了します。再起動中は、サービスが約 40 秒間中断されます。再起動時間は、データ量とテーブル数によって異なります。オフピーク時にバイナリロギング機能を無効にし、アプリケーションがデータベースサービスに自動的に再接続できることを確認することをお勧めします。

関連 API 操作