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のバージョンとストレージタイプを示します。

物理移行は、ApsaraDB RDS for MySQL 5.6、またはローカルSSDを使用するHigh-availability Editionの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インスタンスでは、透過的データ暗号化 (TDE) とSSLが無効になっています。 詳細については、「TDE」および「SSL」をご参照ください。 TDEまたはSSLが有効になっている場合、DTSでデータ同期タスクを手動で作成して、ソースインスタンスをターゲットPolarDBクラスターに移行できます。 詳細については、「ApsaraDB RDS For MySQLインスタンスからPolarDB for MySQLクラスターへのデータの移行」をご参照ください。

• ApsaraDB RDS for MySQLインスタンスでデータベースプロキシ (セーフモード) が有効になっている場合、特権アカウントが作成されるか、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 MySQLインスタンスのパラメーターを設定できません。

  • ソースApsaraDB RDS for MySQLインスタンスには、次の表に示す制限が適用されます。

    項目

    説明

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

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

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

    項目

    説明

    その他の制限

    データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。 完全データ同期中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全なデータ同期が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。 同期するオブジェクトとしてデータベース全体ではなく1つ以上のテーブルを選択した場合、データ同期中にテーブルに対してDDL操作を実行するためにgh-ostまたはpt-online-schema-changeを使用しないでください。 そうしないと、データの同期に失敗する可能性があります。 DTSのみを使用してターゲットデータベースにデータを書き込む場合、データ同期中にdata Management (DMS) を使用してソーステーブルに対してオンラインDDL操作を実行できます。 詳細については、「ロックテーブルなしでスキーマを変更する」をご参照ください。 データ同期中は、DTSのみを使用してデータを宛先に書き込むことを推奨します。 これにより、ソースと宛先間のデータの不一致が防止されます。 たとえば、DTS以外のツールを使用して宛先にデータを書き込む場合、DMSを使用してオンラインDDL操作を実行すると、宛先でデータが失われることがあります。 デフォルトでは、DTSはデータ同期タスクのターゲットデータベースのFOREIGN KEY制約を無効にします。 したがって、ソースデータベースのカスケードおよび削除操作は、ターゲットデータベースと同期されません。

課金ルール

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

  ソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターへのデータ移行は課金されません。 PolarDBクラスターの購入に対してのみ課金されます。 詳細については、「請求項目の概要」をご参照ください。

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

  PolarDBクラスターの購入とDTSでのデータ同期タスクの作成の両方に対して課金されます。 ただし、アップグレード機能は無料トライアルフェーズにあります。 同期タスクが作成されてから30日以内には料金はかかりません。 仮想ネットワークオペレーター (VNO) アカウントとRAMユーザーは、無料トライアルを利用できません。 次の表に、論理的な移行方法の課金ルールを示します。

  移行オブジェクト	課金ルール
  スキーマ同期と完全データ同期	同期タスクが作成されてから30日以内には料金はかかりません。 30日を超えると、同期タスクはキャンセルされます。 説明 節約プランがどのように適用されるか (割引額、プランの詳細、使用状況、対象範囲を含む) に関する詳細を表示するには、 新しいDTSコンソールのデータ同期ページで、同期タスクの残り時間を表示します。

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

PolarDBのサービスにリンクされたロールが作成されているかどうかの事前確認 (論理的移行のみ)

論理移行 (DTS経由のデータ同期) メソッドを使用してワンクリッククローンを実行する前に、現在のAlibaba Cloudアカウントに対してPolarDBのサービスにリンクされたロールが作成されているかどうかを確認します。 以下の手順を実行します。

1. RAMコンソールにログインします。

2. 左側のナビゲーションウィンドウで、[アイデンティティ] > [ロール] を選択します。

3. 次の図に示すように、AliyunServiceRoleForPolarDBという名前のサービスにリンクされたロールがリストに既に存在するかどうかを確認します。

   • サービスにリンクされたロールがリストに存在する場合は、このセクションをスキップして、「ステップ1: ソースApsaraDB RDS for MySQLインスタンスからデータを移行する」で説明されている操作を実行します。

   • サービスにリンクされたロールがリストに存在しない場合は、次の手順を続行します。

4. 左上隅で、ロールの作成をクリックします。

5. ロールの作成パネルのロールタイプの選択ステップで、Alibaba Cloudサービスを選択して次へをクリックします。

   

6. [ロールの設定] ステップで、ロールの種類をサービスにリンクされた役割に設定し、[サービスの選択] ドロップダウンリストからApsaraDB for POLARDBを選択します。

   

7. [OK] をクリックします。 ロールリストに戻り、ロールが作成されたことを確認します。

冗長システムアカウントがソースApsaraDB for RDSインスタンスから削除されているかどうかを事前に確認

システムアカウント構造の観点からApsaraDB RDS for MySQLとPolarDB間の互換性を確保し、移行中に移行先PolarDBクラスターのシステムアカウントが上書きされないようにするには、rootアカウントとaliyun_rootアカウントが移行元ApsaraDB for RDSインスタンスに同時に存在しないようにします。 移行プロセスを開始する前に、ソースApsaraDB for RDSインスタンスから冗長システムアカウントを削除することを推奨します。

次の表に、ApsaraDB RDS for MySQLの各バージョンの正しいシステムアカウント名を示します。

上記の表に記載されている各バージョンの対応するシステムアカウントとは別に、他のすべてのシステムアカウントを削除する必要があります。

次の例は、ApsaraDB RDS for MySQL 5.6インスタンスから冗長システムアカウントを削除する方法を示しています。

1. 特権アカウントを使用してインスタンスに接続します。

2. すべてのrootおよびaliyun_rootシステムアカウントを検索します。

   select * from mysql.user where user in ('root', 'aliyun_root');

3. 冗長なシステムアカウントを削除します。 ApsaraDB RDS for MySQL 5.6の正しいシステムアカウント名はrootです。 したがって、aliyun_rootアカウントを削除する必要があります。

   delete from mysql.user where user = 'aliyun_root' limit n; 

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

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

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

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

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

4. 課金方法をサブスクリプション、従量課金、またはサーバーレスに設定します。

   • サブスクリプション: クラスターを作成するときは、コンピュートノードの前払いが必要です。 ストレージは実際の1時間ごとの使用量に基づいて課金され、料金は1時間ごとにアカウントから差し引かれます。

   • 従量課金: 前払いは必要ありません。 計算ノードと、データによって消費されるストレージの量に対して料金が請求されます。 これらの料金は、1時間ごとにアカウントから差し引かれます。

   • サーバーレス: 前払いは必要ありません。 計算ノード、ストレージスペース、PolarProxyなどのリソースは、実際の需要に基づいて動的にスケーリングされます。 これらのスケーリングされたリソースの実際の使用量に基づいて料金が請求されます。

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. ページの右上隅で、クラスター設定を確認し、[期間] 、[数量] 、およびの [自動更新] パラメーターを設定します。 Durationパラメーターは、サブスクリプションクラスターでのみ使用できます。

7. 利用規約を読んで選択します。 [今すぐ購入] をクリックします。

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

   説明

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

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

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

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

   説明

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

   たとえば、ソースApsaraDB RDS For MySQLインスタンスでトリガーが作成された場合、事前チェックは失敗し、"the RDS instance has a trigger." というエラーメッセージが表示されます。 トリガーを削除し、[続行] をクリックします。 または、[キャンセル] をクリックして、DTSコンソールでデータ同期タスクを手動で作成することもできます。 詳細については、「トリガーを含むソースデータベースのデータ同期タスクの設定」をご参照ください。

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

手順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クラスターへのクローン
  増分データ移行または同期がサポートされているかどうか	はい	いいえ
  ソースApsaraDB RDS for MySQLインスタンスでの操作が影響を受けるかどうか	いいえ	いいえ
  ソースと宛先が異なるMySQLバージョンを実行できるかどうか	はい	はい

• ApsaraDB RDS for MySQLインスタンスからデータを複製すると、ソースApsaraDB RDS for MySQLインスタンスが影響を受けますか。

  いいえ。ApsaraDB RDS for MySQLインスタンスからデータを移行しても、ソースApsaraDB RDS for MySQLインスタンスは影響を受けません。

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

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

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

  • 移行先クラスターは読み書き可能になり、自動的にリリースされません。 ターゲットクラスターを使用しなくなった場合は、できるだけ早い機会にクラスターをリリースして、追加コストを回避します。

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

    説明

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

関連する API 操作