すべてのプロダクト
Search
ドキュメントセンター

PolarDB:ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにアップグレードする

最終更新日:May 28, 2025

PolarDB では、ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにシームレスにアップグレードできます。アップグレードプロセス中に、システムは RDS インスタンスから PolarDB クラスタにアカウント、データベース、IP ホワイトリスト、および必要なパラメータ構成を自動的に同期します。さらに、元のデータベースエンドポイントを保持するオプションがあり、アプリケーションが接続設定を変更することなく PolarDB クラスタにシームレスに接続できるようにします。このプロセスにより、移行の複雑さが大幅に軽減され、ビジネス運用がスムーズに移行されます。

RDS インスタンスは、同じバージョンまたはそれ以上のバージョンPolarDB クラスタにアップグレードできます。例:

  • ApsaraDB RDS for MySQL 5.6 インスタンスは、PolarDB for MySQL 5.6、5.7、8.0.1、または 8.0.2 クラスタにアップグレードできます。

  • ApsaraDB RDS for MySQL 5.7 インスタンスは、PolarDB for MySQL 5.7、8.0.1、または 8.0.2 クラスタにアップグレードできます。

  • ApsaraDB RDS for MySQL 8.0 インスタンスは、PolarDB for MySQL 8.0.1 または 8.0.2 クラスタにアップグレードできます。

    説明
    • PolarDB for MySQL 8.0.1 は、MySQL Community Edition 8.0.13 以前のバージョンと完全に互換性があります。PolarDB for MySQL 8.0.2 は、MySQL Community Edition 8.0.18 以前のバージョンと完全に互換性があります。

    • PolarDB for MySQL 8.0.1 と 8.0.2 で提供される機能には、いくつかの違いがあります。詳細については、「PolarDB for MySQL 5.6、5.7、および 8.0 の機能」をご参照ください。

移行方法

アップグレードでは、物理移行(物理レプリケーション)論理移行(DTS データ同期) の 2 つの移行方法がサポートされています。システムは、RDS インスタンスの MySQL のバージョン、エディション、およびストレージタイプに基づいて、適切な移行方法を自動的に選択します。移行方法を手動で変更することはできません。次の表は、2 つの移行方法を比較したものです。

比較項目

物理移行(物理レプリケーション)

論理移行(DTS データ同期)

ソースインスタンス

ApsaraDB RDS for MySQL 5.6 および 5.7 High-availability Edition インスタンスで、ローカル SSD ストレージタイプを使用しているもの。これらのインスタンスは、同じバージョンの PolarDB for MySQL クラスタにアップグレードできます

説明

ApsaraDB RDS for MySQL インスタンスのマイナーバージョンは、次の要件を満たしている必要があります。

  • ApsaraDB RDS for MySQL 5.6 High-availability Edition インスタンスの場合、マイナーバージョンは 20190815 以後でなければなりません。

  • ApsaraDB RDS for MySQL 5.7 High-availability Edition インスタンスの場合、マイナーバージョンは 20200331 以後でなければなりません。

物理移行をサポートするもの以外の ApsaraDB RDS for MySQL インスタンス。これらのインスタンスは、同じバージョンまたは異なるバージョンの PolarDB for MySQL クラスタにアップグレードできます。

説明

マイナーバージョンの制限はありません。

実装方法

まず、RDS インスタンスから PolarDB クラスタに完全データをコピーし、次に RDS インスタンスから PolarDB クラスタへの増分同期を維持します。

重要

増分同期中は、すべての非 InnoDB テーブルが自動的に InnoDB テーブルに変換されます。

DTS を使用してデータ同期タスクを作成します。タスクは最初に RDS インスタンスから PolarDB クラスタにスキーマと完全データを同期し、次に RDS インスタンスから PolarDB クラスタへの増分データ同期を維持します。

説明
  • 初期完全データ同期では、同時 INSERT 操作が実行され、PolarDB クラスタのテーブルで断片化が発生します。完全データ同期が完了すると、PolarDB データベースの表領域は RDS インスタンスの表領域よりも大きくなります。

  • 初期完全データ同期中、全体的なメモリ使用量が高くなる場合があります。これは、InnoDB のメモリバッファプールがデータを読み取り書き込み操作を高速化するためにキャッシュするためです。アップグレード後、コンソールで innodb_buffer_pool_size パラメータの値を調整して、メモリバッファプールのサイズを変更し、メモリ使用量を削減できます。

DTS が必要かどうか

いいえ。

はい。

MySQL バージョン移行

同じバージョンへの移行のみサポートします。

同じバージョンまたはそれ以上のバージョンへの移行をサポートします。

アップグレード期間

アップグレードは 30 日以内に完了する必要があります。30 日が経過すると、システムは自動的に移行プロセスを停止します。

アップグレードは 30 日以内に完了する必要があります。30 日が経過すると、システムは自動的に移行プロセスを停止します。

リージョン間の移行がサポートされているかどうか

いいえ。

いいえ。

増分同期がサポートされているかどうか

はい。

はい。

新しく追加されたデータベースを移行できるかどうか

はい。

いいえ。

説明

新しく追加されたデータベースを同期するには、DTS コンソール に移動して同期オブジェクトを変更し、転送タスクと逆転送タスクの両方で新しいデータベースを構成します。

スキーマを移行できるかどうか

はい。

データベース、テーブル、ビュー、ストアドプロシージャ、および関数のみを移行できます。

メリット

  • エンドポイントを使用したスイッチオーバー がサポートされています。元のデータベースエンドポイントを保持することを選択できます。これにより、アプリケーションは接続構成を変更することなく PolarDB クラスタに接続できます。

  • アップグレードプロセス中にデータが失われることはありません。

  • 増分移行がサポートされています。

  • オンラインホットマイグレーションがサポートされています。アップグレードプロセス中、ビジネスがスイッチオーバーされるときに発生する、10 分未満のダウンタイムを伴う短い中断が 1 回だけ発生します。

  • 移行が失敗した場合、または移行が不要になった場合は、移行をロールバックできます。ロールバックは 10 分以内に完了できます。

使用方法に関する注意事項

RDS instance インスタンスへの影響

アップグレードプロセス中は、RDS インスタンスに対する特定の操作が制限される場合があり、一部の操作によって短い中断が発生したり、RDS インスタンスの負荷が増加したりする場合があります。

  • アップグレードプロセス中は、インスタンスパラメータを変更できません。

  • スイッチオーバー を実行するときに [エンドポイントなしで切り替え] を選択すると、切り替え中にビジネスが 1 ~ 5 分中断される場合があります。[エンドポイントなしで切り替え] を選択した場合は、PolarDB クラスタに接続するためのアプリケーションの接続構成をすぐに変更する必要があります。

  • 論理移行(DTS データ同期)変更を保存 移行方法 を使用する場合は、次のガイドラインに従ってください。

    • RDS インスタンス用に作成されたトリガーを削除します。そうしないと、移行が中断されます。

    • 初期完全データ同期中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ同期タスクが失敗します。

    • 初期完全データ同期中は、RDS インスタンスと PolarDB クラスタの読み取りおよび書き込みリソース(CPU や IOPS など)が使用されるため、RDS インスタンスの負荷が増加する可能性があります。

前提条件

ソース RDS インスタンスは、次の要件を満たしている必要があります。

  • インスタンスの基本情報:

    MySQL バージョン

    Basic Edition

    High-availability Edition

    Cluster Edition

    5.6

    -

    ローカル SSD

    -

    5.7

    クラウドディスク

    ローカル SSDクラウドディスク

    クラウドディスク

    8.0

    クラウドディスク

    ローカル SSDクラウドディスク

    クラウドディスク

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

  • 条件物理移行(物理レプリケーション) メソッド を満たさない場合は、論理移行(DTS データ同期) メソッド が使用されます。RDS インスタンスが以下の要件を満たしていることを確認してください。

    • DTS 双方向同期タスクが存在しないこと。DTS 双方向同期タスクが存在する場合は、アップグレードを実行しないでください。そうしないと、アップグレード中にデータの不整合が発生する可能性があります。

    • RDS インスタンス用に作成されたトリガーを削除します。そうしないと、移行が中断されます。

    • デフォルトでは、RDS インスタンスでバイナリロギング機能が有効になっています。binlog_row_image パラメータの値が full である ことを確認してください。そうしないと、事前チェックフェーズでエラーが返され、データ同期タスクを正常に開始できません。

    • 移行プロセス中に DTS が増分データ同期のためにバイナリログファイルに確実にアクセスできるようにするには、RDS インスタンスの バイナリログファイル を少なくとも 7 日間保持する必要があります。そうしないと、同期タスクが失敗する可能性があります。極端な場合は、データの不整合または損失が発生する可能性があります。DTS のサービスレベル契約(SLA)は、binlog ファイルの保持期間を必要な 7 日間未満に設定することによって発生する問題を対象としていません。

  • 条件が満たされていない場合でも 物理マイグレーション(物理レプリケーション) マイグレーション方法 を使用する場合、RDS インスタンスのバージョンが以下の条件を満たしていることを確認してください。

    • ApsaraDB RDS for MySQL 5.6 High-availability Edition インスタンスの場合、マイナーバージョンは 20190815 以後でなければなりません。

    • ApsaraDB RDS for MySQL 5.7 High-availability Edition インスタンスの場合、マイナーバージョンは 20200331 以後でなければなりません。

    説明
    • RDS インスタンスの [マイナーバージョン] を表示するには、RDS コンソール > [インスタンス] > [基本情報] ページに移動します。[構成情報] セクションでマイナーバージョンの情報を確認できます。指定されたバージョンより前の場合は、更新 してください。

    • 物理移行(物理レプリケーション) を使用する場合は、バイナリログファイル の保持期間を少なくとも 24 時間に設定することをお勧めします。

制限

論理移行(DTS データ同期)オープンソースとの互換性 移行方法 を使用したアップグレードには、次の制限があります。

  • データ同期の間に、他のソースからのデータがターゲットデータベースに書き込まれた場合、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。たとえば、他のソースからのデータがターゲットデータベースに書き込まれている間に、DMS を使用してオンライン DDL 文を実行すると、ターゲットデータベースでデータ損失が発生する可能性があります。

  • デフォルトでは、DTS はデータ同期タスクにおいて、ターゲットデータベースの FOREIGN KEY 制約を無効にします。そのため、ソースデータベースのカスケード操作や削除操作などの特定の操作は、ターゲットデータベースに同期されません。

  • 増分同期でサポートされている SQL 文:

    操作タイプ

    SQL 文

    DML

    INSERTUPDATEDELETE

    DDL

    • ALTER TABLEALTER VIEW

    • CREATE FUNCTIONCREATE INDEXCREATE PROCEDURECREATE TABLECREATE VIEW

    • DROP INDEXDROP TABLE

    • RENAME TABLE

    • TRUNCATE TABLE

重要な考慮事項

移行フェーズ

説明

移行前

移行中

  • PolarDB クラスタの作成中 の完全データ同期には時間がかかります。消費される時間は、同期されるデータ量によって異なります。この期間中、宛先 PolarDB クラスタは作成中状態です。

  • エンドポイントを使用したスイッチオーバー機能は、ソース RDS インスタンスとデスティネーション PolarDB クラスタの両方にエンドポイントがある場合にのみ、エンドポイントを交換します。デフォルトでは、デスティネーション PolarDB クラスタには、非公開プライマリエンドポイントと非公開クラスターエンドポイントのみがあります。RDS インスタンスに 3 つ以上のエンドポイントがある場合、これらのエンドポイントを交換するには、デスティネーション PolarDB クラスタに 対応するエンドポイントを作成する必要があります。

  • エンドポイントの SSL 暗号化ステータスは一致している必要があります。

    • ソース インスタンスのエンドポイントで SSLRDS が有効になっていて、エンドポイントを 切り替えるSSL 場合は、PolarDB クラスタのエンドポイントでも SSL が有効になっていることを確認してください。

    • ソース インスタンスのエンドポイントで SSLRDSSSL が無効になっている場合は、PolarDB クラスタのエンドポイントでも SSL が無効になっていることを確認してください。

  • 論理移行(DTS データ同期):

    • DTS データ同期タスクを手動でリリースしないでください。

課金

論理移行(DTS データ同期) 方法

論理移行(DTS データ同期) 方法を使用する場合、DTS データ同期タスクと宛先 PolarDB クラスタに対して課金されます。

  • DTS データ同期タスク:

    アップグレードプロセス中に、システムは RDS インスタンスと PolarDB クラスタの間に DTS データ同期タスクを自動的に作成します。DTS タスクの課金ルールについては、「課金の概要」をご参照ください。

  • 宛先 PolarDB クラスタ:

    • 課金方法従量課金 の場合、移行プロセス全体でクラスタの料金は発生しません。次の操作の後、従量課金制で課金されます。

      • 移行完了(アップグレードプロセス中の 移行の完了 操作を含む)。

        説明
        • RDS インスタンスと PolarDB クラスタ間の同期リンクが中断されると、移行は完了です。

        • 移行は 30 日以内に完了する必要があります。30 日が経過すると、移行機能は無効になり、RDS インスタンスと PolarDB クラスタの両方が読み書き状態に戻り、レプリケーション関係が解除されます。

      • 移行停止(事前チェックが失敗したときの 移行のキャンセル 操作と、アップグレードプロセス中の 移行のキャンセル 操作を含む)。

        この場合、アップグレードが停止しても、PolarDB クラスタはすでに作成されています。不要になった場合は、クラスタをリリース してください。

    • 宛先 PolarDB クラスタがサーバーレスクラスタの場合、宛先クラスタは実行中状態になると課金が開始されます。

    • 宛先 PolarDB クラスタでサブスクリプション課金方法を使用する場合は、クラスタの作成時に支払いを完了する必要があります。

物理移行(物理レプリケーション) 方法

物理移行(物理レプリケーション) を使用する場合、アップグレードのデータ移行プロセスは無料です。宛先 PolarDB クラスタに対してのみ課金されます。

  • 宛先 PolarDB クラスタで従量課金制の課金方法を使用する場合は、移行プロセス全体でクラスタの料金は発生しません。次の操作の後、従量課金制で課金されます。

    • 移行完了(アップグレードプロセス中の 移行の完了 操作を含む)。

      説明
      • RDS インスタンスと PolarDB クラスタ間の同期リンクが中断されると、移行は完了です。

      • 移行は 30 日以内に完了する必要があります。30 日が経過すると、移行機能は無効になり、RDS インスタンスと PolarDB クラスタの両方が読み書き状態に戻ります。

    • 移行停止(事前チェックが失敗したときの 移行のキャンセル 操作と、アップグレードプロセス中の 移行のキャンセル 操作を含む)。

      この場合、アップグレードが停止しても、PolarDB クラスタはすでに作成されています。不要になった場合は、クラスタをリリース してください。

  • 宛先 PolarDB クラスタがサーバーレスクラスタの場合、宛先クラスタは実行中状態になると課金が開始されます。

  • 宛先 PolarDB クラスタでサブスクリプション課金方法を使用する場合は、クラスタの作成時に支払いを完了する必要があります。

手順

1. 移行を評価する

スムーズな移行プロセスとより良い移行エクスペリエンスを実現するために、PolarDB移行評価 機能を提供しています。この機能を使用すると、アップグレード前に、インスタンスステータス、移行タスクの依存関係、ソースインスタンスの属性などの前提条件を事前に確認できます。これにより、移行の進行に影響を与える可能性のある要因を特定し、事前に問題を解決して、移行中の処理とリソースコストを削減できます。

2. アップグレードを実行する

(推奨)コンソール操作

以下は、アップグレードプロセスの簡単な説明です。詳細な手順については、「アップグレード手順」をご参照ください。

  1. (オプション)ホワイトリストの構成を確認する

    ソース RDS インスタンスのプライマリノードと読み取り専用ノードのホワイトリストが異なる場合は、読み取り専用ノードのホワイトリストが宛先 PolarDB クラスタに同期されるように、事前にプライマリノードのホワイトリストに読み取り専用ノードのホワイトリストを追加する必要があります。

    説明

    PolarDB クラスタのホワイトリスト構成はクラスタ全体に適用され、ノードごとの個別の構成はサポートされていません。したがって、移行が完了したら、PolarDB クラスタの ホワイトリストデータベースアカウントの権限 を確認することをお勧めします。

  2. PolarDB クラスタを作成する

    PolarDB クラスタ購入ページ に移動し、[RDS から移行] 作成方法を選択し、ソース RDS のバージョンとインスタンスを指定して、PolarDB クラスタを購入します。購入が完了すると、システムは初期化、事前チェック、および完全データ同期の操作を実行します。この期間中、クラスタは [作成中] 状態です。作成が完了するまで待ちます。

    説明

    論理移行(DTS データ同期) を使用したアップグレードプロセス中に、[事前チェックの失敗] などのエラーが発生する場合があります。[エラーメッセージ] の情報に基づいて、これらのエラーに対処できます。エラーが解決したら、[移行を続行] をクリックして、アップグレードプロセスを続行できます。現在のエラーの解決がオンラインビジネスに影響を与える場合は、[移行を中止] をクリックして、アップグレードプロセスを終了することを選択できます。

  3. (オプション)エンドポイントを追加する

    エンドポイントを使用したスイッチオーバー機能を使用すると、元のデータベースエンドポイントを保持できます。これにより、アプリケーションは接続構成を変更することなく PolarDB クラスタに接続できます。ただし、RDS インスタンスと PolarDB クラスタの両方に同時に存在するエンドポイントのみを交換できます。

    1. 実際の状況に基づいて、PolarDB クラスタに関連するエンドポイントを追加するかどうかを選択できます。

    2. エンドポイントの SSL 暗号化ステータスを確認します。RDS インスタンスと PolarDB クラスタのエンドポイントの SSL 暗号化ステータスは一致している必要があります。

  4. サービスをスイッチオーバーする

    PolarDB クラスタの [レプリケーション遅延] が 60 秒未満の場合、ビジネスの切り替えを実行できます。[スイッチオーバー] をクリックして、RDS インスタンスと PolarDB クラスタの読み書きステータスを交換し(RDS インスタンスを 読み取り専用 に、PolarDB クラスタを 読み取り/書き込み に変更)、データレプリケーションの方向も変更します(PolarDB クラスタから RDS インスタンスに新しいデータを同期)。

    重要
    • スイッチオーバーの実行時に [エンドポイントを使用してスイッチオーバー] を選択した場合は、エンドポイント交換の使用方法に関する注意事項 をよくお読みください。切り替えプロセス中にビジネスが 1 ~ 5 分中断される場合があることに注意してください。

    • スイッチオーバーの完了後にデータエラーが発生した場合は、スイッチオーバーを ロールバック できます。これにより、データベースとデータをスイッチオーバーが実行される前の元の状態に復元できます。その後、[移行のキャンセル] を選択して、移行前の状態に復元できます。

  5. (オプション)DTS タスクをスイッチオーバーする

    ソース RDS インスタンスが DTS タスク(ワンクリック移行タスクではない)に含まれている場合は、スムーズなスイッチオーバーのために DTS タスクのソースデータベースまたは宛先データベースを変更できます。

  6. 移行を完了する

    データ移行が完了し、PolarDB クラスタが安定して実行されている場合は、データ同期が不要になった場合、[移行の完了] をクリックしてアップグレードプロセスを終了できます。

  7. ApsaraDB RDS インスタンスをリリースまたはサブスクライブ解除する

    ビジネスが PolarDB クラスタで安定して実行されていて、RDS インスタンスが不要になった場合は、RDS インスタンスのサブスクライブを解除またはリリースできます。

API 操作

以下は、アップグレードプロセスの簡単な説明です。詳細な手順については、「アップグレード手順」および関連する API ドキュメントをご参照ください。

  1. (オプション)ホワイトリストの構成を確認する

    ソース RDS インスタンスのプライマリノードと読み取り専用ノードのホワイトリストが異なる場合は、読み取り専用ノードのホワイトリストが宛先 PolarDB クラスタに同期されるように、事前にプライマリノードのホワイトリストに読み取り専用ノードのホワイトリストを追加する必要があります。

    説明

    PolarDB クラスタのホワイトリスト構成はクラスタ全体に適用され、ノードごとの個別の構成はサポートされていません。したがって、移行が完了したら、PolarDB クラスタの ホワイトリストデータベースアカウントの権限 を確認することをお勧めします。

  2. CreateDBCluster を呼び出して、PolarDB クラスタを作成します。

    API を呼び出して PolarDB クラスタを作成するときに、SourceResourceId をソース RDS インスタンスのリージョンに、CreationOptionMigrationFromRDS に、SourceResourceId をソース RDS インスタンス ID に設定します。呼び出しが完了すると、システムは初期化、事前チェック、および完全データ同期の操作を実行します。この期間中、クラスタは [作成中] 状態です。作成が完了するまで待ちます。

  3. DescribeDBClusterMigration を呼び出して、PolarDB クラスタのステータスをクエリします。

    戻りパラメータ MigrationStatusRDS2POLARDB_SYNCING の場合、システムは完全データの同期を完了し、増分同期を実行しています。

    説明

    論理移行(DTS データ同期) を使用したアップグレードプロセス中に、[事前チェックの失敗]MigrationStatusPRE_CHECK_FAIL)などのエラーが発生する場合があります。エラーメッセージ(Comment)の情報に基づいて、これらのエラーに対処できます。エラーが解決したら、[移行を続行] をクリックしてアップグレードプロセスを続行できます。現在のエラーの解決がオンラインビジネスに影響を与える場合は、[移行を中止] をクリックしてアップグレードプロセスを終了することを選択できます。

  4. ModifyDBClusterMigration を呼び出して、移行とスイッチオーバーを実行します。

    DescribeDBClusterMigration の戻りパラメータ DelayedSeconds が 60 秒未満の場合、スイッチオーバーを実行して RDS インスタンスと PolarDB クラスタの読み書きステータスを交換し(RDS インスタンスを 読み取り専用 に、PolarDB クラスタを 読み取り/書き込み に変更)、データレプリケーションの方向を変更します(PolarDB クラスタから RDS インスタンスに新しいデータを同期)。

    重要
    • スイッチオーバーの実行時に [エンドポイントを使用してスイッチオーバー] を選択した場合は、エンドポイント交換の使用方法に関する注意事項 をよくお読みください。切り替えプロセス中にビジネスが 1 ~ 5 分中断される場合があることに注意してください。

    • 移行の切り替えが完了した後、データの異常やその他の問題が見つかった場合は、ModifyDBClusterMigration を呼び出して移行タスクをロールバックし、アップグレード前の状態にすばやく復元できます。その後、CloseDBClusterMigration を呼び出して移行をキャンセルし、切り替え前の状態に復元することもできます。

    • スイッチオーバーの完了後にデータエラーが発生した場合は、ModifyDBClusterMigration を呼び出してスイッチオーバーをロールバックできます。これにより、データベースとデータをスイッチオーバーが実行される前の元の状態に復元できます。その後、CloseDBClusterMigration を選択して移行をキャンセルし、移行前の状態に復元できます。

  5. (オプション)ModifyDtsJobEndpoint を呼び出して、DTS stask のソースインスタンスまたは宛先インスタンスを変更します。

    ソース RDS インスタンスが DTS タスク(ワンクリック移行タスクではない)に含まれている場合は、スムーズなスイッチオーバーのために DTS タスクのソースデータベースまたは宛先データベースを変更できます。

  6. CloseDBClusterMigration を呼び出して、移行を完了します。

    データ移行が完了し、PolarDB クラスタが安定して実行されている場合は、データ同期が不要になった場合、[移行の完了] をクリックしてアップグレードプロセスを終了できます。

  7. ApsaraDB RDS インスタンスをリリースまたはサブスクライブ解除する

    ビジネスが PolarDB クラスタで安定して実行されていて、RDS インスタンスが不要になった場合は、RDS インスタンスのサブスクライブを解除またはリリースできます。

3. バックアップポリシーを調整する

RDS インスタンスと PolarDB クラスタの バックアップポリシー は、いくつかの点で異なります。移行が完了したら、実際の状況に応じて、コンソールで バックアップポリシーを変更 できます。

関連情報

バックアップ ポリシー

RDS インスタンスと PolarDB クラスタのバックアップポリシーは、いくつかの点で異なります。

  • RDS インスタンスと PolarDB クラスタの間で、定期バックアップサイクルと開始時刻は一致します。デフォルトでは、PolarDB クラスタは RDS インスタンスと同じバックアップサイクルと開始時刻を継承します。

  • バックアップの保持期間のマッピング:

    • RDS インスタンスのバックアップファイルの保持期間が 14 日以下の場合、PolarDB クラスタのレベル 1 バックアップファイルの保持期間は、RDS インスタンスの保持期間と同じです。

    • RDS インスタンスのバックアップファイルの保持期間が 14 日(排他)~ 30 日(包含)の場合、PolarDB クラスタのレベル 1 バックアップファイルの保持期間は 14 日に固定されます。PolarDB クラスタではレベル 2 バックアップ機能が有効になり、同じリージョン内のレベル 2 バックアップファイルの保持期間は 30 日に固定されます。RDS インスタンスのバックアップファイルの保持期間が 30 日を超える場合、PolarDB クラスタではレベル 2 バックアップ機能が有効になり、同じリージョン内のレベル 2 バックアップファイルの保持期間は RDS インスタンスの保持期間と同じです。

    • RDS バックアップが長期間保持される場合、PolarDB のレベル 1 バックアップの保持期間は 14 日に固定されます。レベル 2 バックアップは長期間保持されます。

  • RDS インスタンスで高頻度バックアップ機能が有効になっている場合、デフォルトでは PolarDB クラスタでも高頻度バックアップ機能が有効になります。RDS インスタンスと PolarDB クラスタの高頻度バックアップファイルの保持期間:

    • RDS インスタンスの高頻度バックアップファイルの保持期間が 120 分以下の場合、PolarDB クラスタの高頻度バックアップファイルの保持期間は 120 分に固定されます。

    • RDS インスタンスの高頻度バックアップファイルの保持期間が 120 分(排他)~ 180 分(包含)の場合、PolarDB クラスタの高頻度バックアップファイルの保持期間は 180 分に固定されます。

    • RDS インスタンスの高頻度バックアップファイルの保持期間が 180 分を超える場合、PolarDB クラスタの高頻度バックアップファイルの保持期間は 240 分に固定されます。

Switchover with endpointsエンドポイントを使用したスイッチオーバー

ワンクリックアップグレードプロセスでは、アドレス切り替え機能がサポートされています。選択すると、システムは RDS インスタンスと PolarDB クラスタの接続アドレスを自動的に交換し、アプリケーションが構成を変更することなく PolarDB クラスタに自動的に接続できるようにします。

以下は、RDS インスタンスと PolarDB クラスタのデフォルトの接続アドレス切り替え関係を示しています。実際の切り替えプロセス中に、コンソールで接続アドレス切り替え関係を調整できます。

説明

RDS インスタンスの読み取り専用エンドポイントには、プロキシ読み取り専用ポイントと読み取り専用インスタンスのエンドポイントが含まれます。

使用方法

  • エンドポイントを使用したスイッチオーバー機能では、IPv6 アドレスはサポートされていません。

  • エンドポイントを使用したスイッチオーバー機能では、RDS インスタンスと PolarDB クラスタのエンドポイントのみが交換され、vSwitch や仮想 IP アドレスなどの他の構成は交換されません。

  • エンドポイントは、ソース RDS インスタンスとデスティネーション PolarDB クラスタの両方にエンドポイントが存在する場合にのみ交換できます。デフォルトでは、デスティネーション PolarDB クラスタには、非公開プライマリエンドポイントと非公開クラスターエンドポイントのみが存在します。RDS インスタンスに 3 つ以上のエンドポイントがある場合は、これらのエンドポイントを交換する場合、デスティネーション PolarDB クラスタに 対応するエンドポイントを作成する必要があります。

  • ソース RDS インスタンスのプライマリエンドポイントを、宛先 PolarDB クラスタのプライマリエンドポイントまたはデフォルトのクラスタエンドポイントと交換することを選択できます。RDS インスタンスのプロキシエンドポイントは、PolarDB クラスタのデフォルトのクラスタエンドポイントまたはカスタムエンドポイントと交換できます。エンドポイントのスイッチオーバーを実行するかどうかを指定し、交換するエンドポイントペアを選択できます。PolarDB クラスタには最大 7 つのクラスタエンドポイントを含めることができます。したがって、RDS インスタンスの最大 7 つのプロキシエンドポイントを PolarDB クラスタのクラスタエンドポイントと交換できます。

  • RDS Cluster Edition インスタンスの [クラスタ読み取り専用エンドポイント][ダイレクトノード接続エンドポイント] は交換できません。

  • プライベートエンドポイントを切り替える前に、ソース RDS インスタンスと宛先 PolarDB クラスタが同じ VPC に属していることを確認してください。そうしないと、スイッチオーバー後に元のサービスに接続できなくなります。

  • 増分同期が完了すると、デスティネーション PolarDB クラスタは [実行中] 状態になります。エンドポイントを交換する前に、パラメータの構成、読み取り専用ノードの追加、アドレス設定の追加を行うことができます。

  • エンドポイントの交換後にデータ管理(DMS)を使用して PolarDB クラスタにログオンする場合は、正しいクラスタ ID とエンドポイントを指定してください。

  • エンドポイントが切り替えられた後、エントリが期限切れになるまで、元のエンドポイントエントリがドメインネームシステム(DNS)キャッシュに残っている場合があります。この期間中、PolarDB クラスタに接続できない場合や、インスタンスで読み取り操作のみが許可される場合があります。問題を解決するには、DNS キャッシュをリフレッシュすることをお勧めします。

FAQ

PolarDB クラスターのスペックアップ中、メモリ使用量が高いのはなぜですか?

初期完全同期中、InnoDB のメモリバッファープールはデータを読み取り/書き込み操作を高速化するためにキャッシュします。その結果、全体的なメモリ使用量が増加します。

スペックアップ後、コンソールで innodb_buffer_pool_size パラメーターの 値を調整 して、メモリバッファープールのサイズを変更し、メモリ使用量を削減できます。