ApsaraDB RDS:ApsaraDB RDS for MySQLインスタンスをゾーン間で移行する

同じリージョンのゾーン間で異なるデータベースエンジンを実行するRDSインスタンスを移行する方法の詳細については、以下のトピックを参照してください。

• 同じリージョンのゾーン間でApsaraDB RDS for PostgreSQLインスタンスを移行する

• 同じリージョンのゾーン間でApsaraDB RDS for SQL Serverインスタンスを移行する

課金ルール

クロスゾーン移行の料金は発生しません。 これは、RDSインスタンスを1つのゾーンから複数のゾーンに移行する場合にも適用されます。

影響

• 移行中に、インスタンスの切り替えが発生します。 RDS インスタンスに自動的に再接続するようにアプリケーションが設定されていることを確認してください。 詳細については、「インスタンスの切り替えの影響」をご参照ください。

• クロスゾーン移行により、RDSインスタンスの仮想IPアドレスが変更されます。 アプリケーションをRDSインスタンスに接続するには、RDSインスタンスのIPアドレスではなくエンドポイントを使用することを推奨します。

• クロスゾーン移行後、キャッシュされたDNSレコードをデータベースクライアントから直ちに削除する必要があります。 データベースクライアントがJava仮想マシン (JVM) で実行されている場合は、JVM構成の有効期間 (TTL) を60秒以下に設定することを推奨します。 これにより、RDSインスタンスの使用中のエンドポイントにバインドされているVIPが変更された場合、アプリケーションは関連するDNSレコードを再度クエリして新しいVIPを取得できます。 その後、アプリケーションは新しいVIPに接続できます。

  説明

  JVM構成でTTLを設定する方法の詳細については、「クラスInetAddress」をご参照ください。

• RDSインスタンスが PolarDB-X 1.0インスタンスの場合、VIPの変更はRDSインスタンスと PolarDB-X 1.0インスタンス。 できるだけ早い機会に接続の問題を修正することを推奨します。 詳細については、「データベースシャード接続の修正」をご参照ください。

• RDSインスタンスに進行中のData Transmission Service (DTS) タスクがある場合、移行が完了した後にDTSタスクを再起動する必要があります。

• RDSインスタンスを移行するゾーンのリソースインベントリが不十分な場合、移行が失敗する可能性があります。

• ゾーン間の移行を実行すると、テーブルが再作成されます。 その結果、テーブルの作成時刻が変更され、INFORMATION_SCHEMAテーブルのCREATE_TIMEフィールドの値が変更されます。

手順

1. [インスタンス] ページへ移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。

2. 表示されるページの 基本情報 セクションで、RDSインスタンスのリージョンとゾーンを表示します。

   • シングルゾーン展開の リージョンとゾーン パラメーターの値の例

     

   • マルチゾーン展開方法のリージョンとゾーンパラメーターの値の例

     

3. ゾーンの移行 をクリックします。

   説明

   ゾーンの移行 が表示されない場合、RDSインスタンスが前提条件を満たしているかどうかを確認する必要があります。

4. インスタンスを別のゾーンに移行する ダイアログボックスで、[プライマリゾーンの設定] 、[プライマリゾーンのvSwitch] 、および [切り替え時間] のパラメーターを設定します。 次に、OK をクリックします。

   移行シナリオ	説明
   あるゾーンから別のゾーンへの移行	移行先のプライマリゾーン と セカンダリゾーンへの移行 を同じ値に設定する必要があります。 たとえば、プライマリRDSインスタンスとセカンダリRDSインスタンスはシンガポールゾーンCにあり、インスタンスをシンガポールゾーンAに移行したとします。
   1つのゾーンから複数のゾーンへの移行	プライマリゾーンへの移行とセカンダリゾーンへの移行パラメーターを異なる値に設定する必要があります。 たとえば、プライマリRDSインスタンスとセカンダリRDSインスタンスはシンガポールゾーンCにあり、プライマリRDSインスタンスはシンガポールゾーンBに、セカンダリRDSインスタンスはシンガポールゾーンAに移行します。 説明 移行後、プライマリRDSインスタンスとセカンダリRDSインスタンスは異なるゾーンに配置され、クロスゾーンディザスタリカバリを実現します。 マルチゾーン展開方式は、シングルゾーン展開方式よりも高いディザスタリカバリ機能を提供します。 シングルゾーン展開方法を選択した場合、データベースシステムはサーバーとラックの障害に耐えることができます。 マルチゾーン展開方法を選択した場合、データベースシステムはデータセンターの障害に耐えることができます。 データベースシステムにプライマリおよびセカンダリRDSインスタンスが含まれている場合、RDSインスタンスを複数のゾーンに移行して、ゾーン間のディザスタリカバリを実装することを推奨します。
   複数のゾーンから1つのゾーンへの移行	プライマリゾーンへの移行とセカンダリゾーンへの移行を同じ値に設定する必要があります。 たとえば、プライマリRDSインスタンスはシンガポールゾーンBにあり、セカンダリRDSインスタンスはシンガポールゾーンAにあり、インスタンスをシンガポールゾーンCに移行するとします。

   重要

   • 移行後、システムは [切り替え時間] パラメーターの値に基づいてワークロードを切り替えます。 切り替え時間パラメーターを [すぐに切り替える] または メンテナンスウィンドウ内に切り替える に設定できます。 切り替え中にRDSインスタンスのvSwitchが変更された場合、RDSインスタンスは新しい接続を介して接続されます。 RDSインスタンスに自動的に再接続するようにアプリケーションが設定されていることを確認します。 それ以外の場合は、アプリケーションをRDSインスタンスに手動で再接続する必要があります。

   • データベースクライアントにキャッシュされたDNSレコードが移行後すぐに更新されない場合、一部のワークロードは10分後に移行先プライマリゾーンに切り替えられる可能性があります。 その結果、RDSインスタンスに別のインスタンス切り替えが発生します。 RDSインスタンスに自動的に再接続するようにアプリケーションが設定されていることを確認します。 それ以外の場合は、アプリケーションをRDSインスタンスに手動で再接続する必要があります。 データベースクライアントがJVM上で実行されている場合は、JVM構成のTTLを60秒以下に設定することを推奨します。 この場合、RDSインスタンスの使用中のエンドポイントにバインドされている仮想IPアドレスが変更された場合、アプリケーションは関連するDNSレコードを再度クエリして、新しい仮想IPアドレスを取得できます。 その後、アプリケーションは新しい仮想IPアドレスに接続できます。 詳細については、このトピックの影響セクションを参照してください。

   • インスタンスの切り替えの影響の詳細については、「インスタンスの切り替えの影響」をご参照ください。

関連する API 操作

よくある質問

• クロスゾーン移行中にRDSインスタンスにデータが書き込まれた場合、ワークロードの切り替え後にRDSインスタンスの元のデータが影響を受けますか。 新しく書き込まれたデータは保持されますか?

  元のデータは影響を受けず、新しく書き込まれたデータは保持されます。

  重要

  移行中にインスタンスの切り替えが発生します。 RDSインスタンスに自動的に再接続するようにアプリケーションが設定されていることを確認します。 それ以外の場合は、アプリケーションをRDSインスタンスに手動で再接続する必要があります。 インスタンスの切り替えの影響の詳細については、「インスタンスの切り替えの影響」をご参照ください。

• クロスゾーン移行に必要な時間に影響する要因は何ですか?

  クロスゾーン移行に必要な時間は、RDSインスタンスのデータ量によって異なります。 RDSインスタンスに大量のデータが存在する場合は、長時間が必要です。