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

はじめに

PolarDB では、ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスタにアップグレードできます。PolarDB for MySQL クラスタが自動的に作成され、データがクラスタに同期されます。PolarDB クラスタは、ApsaraDB RDS for MySQL インスタンスのアカウント、データベース、IP アドレスホワイトリスト、および必須パラメータを使用します。

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

  説明

  論理移行方式は、ApsaraDB RDS for MySQL 8.0 インスタンスのクローン作成、クラウドディスクを使用する ApsaraDB RDS for MySQL インスタンスの PolarDB for MySQL クラスタへのアップグレード、および異なる MySQL バージョンを実行する PolarDB for MySQL クラスタへの ApsaraDB RDS for MySQL インスタンスのアップグレードのシナリオで使用されます。この方式は、Data Transmission Service (DTS) のデータ同期機能に基づいて実装されています。詳細については、「物理移行と論理移行の比較」をご参照ください。

• サブスクリプションまたは従量課金方式のいずれかを使用するソース ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL にアップグレードできます。デスティネーション PolarDB for MySQL クラスタは、サブスクリプション、従量課金、またはサーバーレス課金方式を使用できます。

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

アップグレード機能は、物理移行（物理レプリケーション）と論理移行（DTS を介したデータ同期）の 2 つの方式をサポートしています。

物理移行

物理移行方式を使用して、ソース ApsaraDB RDS for MySQL インスタンスから完全データをコピーできます。その後、増分データがデスティネーション PolarDB for MySQL クラスタに同期されます。

論理移行

DTS でデータ同期タスクを作成して、ソース ApsaraDB RDS for MySQL インスタンスのスキーマと完全データをデスティネーション PolarDB for MySQL クラスタに移行できます。その後、増分データがデスティネーションクラスタに同期されます。

比較

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

メリット

アップグレード機能には、次のメリットがあります。

• ソースデータベースのエンドポイントは保持されます。アプリケーションの接続設定を変更せずに PolarDB に切り替えることができます。

• 移行中にデータが失われることはありません。

• 増分データ移行がサポートされています。サービスのダウンタイムは 10 分未満です。

• ホットマイグレーションがサポートされています。データ移行プロセス中は、一時的な接続が 1 回だけ発生します（ビジネスが ApsaraDB RDS for MySQL インスタンスから PolarDB クラスタに切り替えられるとき）。

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

前提条件

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

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

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

  説明

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

  • 物理移行を使用する場合は、ローカルバイナリログの保存期間を 24 時間以上に設定することをお勧めします。

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

• DTS データ同期タスクを使用してアップグレードを実行する場合は、ソース ApsaraDB RDS 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 クラスタにアップグレードしたりすることはできません。

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

• DTS 双方向データ同期タスクで使用されている PolarDB for MySQL クラスタに ApsaraDB RDS for MySQL インスタンスを移行することはできません。

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

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

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

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

  説明

  データベーススキーマと完全データの同期プロセス中は、データベースまたはテーブルスキーマを変更するデータ定義言語 (DDL) 操作を実行しないでください。このような DDL 操作を実行すると、データ同期タスクが失敗する可能性があります。

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

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

  • データベース、テーブル、ビュー、ストアドプロシージャ、関数のみを移行できます。イベントは移行できません。

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

    項目

    説明

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

    バイナリログについては、次の要件を満たしている必要があります。 バイナリログ機能が有効になっている必要があります。バイナリログを有効にする方法の詳細については、「インスタンスパラメータを変更する」をご参照ください。また、binlog_row_image パラメータを full に設定する必要があります。そうしないと、事前チェック中にエラーメッセージが返され、データ同期タスクを開始できません。 増分データ同期タスクの場合、ソースデータベースのバイナリログは少なくとも 24 時間保持されます。完全および増分データ同期タスクの場合、ソースデータベースのバイナリログは少なくとも 7 日間保持されます。完全データ同期が完了したら、保存期間を 24 時間以上に設定できます。そうしないと、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に従ってバイナリログの保存期間を設定してください。そうしないと、DTS の SLA はサービスの信頼性とパフォーマンスを保証しません。ApsaraDB RDS for MySQL インスタンスのバイナリログファイルの詳細については、「バイナリログファイルを管理する」をご参照ください。

  • 次の表は、SQL 文の制限について説明しています。

    説明

    PolarDB for MySQL のキーワードは、MySQL のキーワードと 100% 互換性があります。

    タイプ	SQL 文
    DML	INSERT、UPDATE、および DELETE
    DDL	ALTER TABLE および ALTER VIEW CREATE FUNCTION、CREATE INDEX、CREATE PROCEDURE、CREATE TABLE、および CREATE VIEW DROP INDEX および DROP TABLE RENAME TABLE TRUNCATE TABLE

  • 次の表は、その他の制限について説明しています。

    項目

    説明

    その他の制限

    データを同期する前に、データ同期がソースデータベースとデスティネーションデータベースのパフォーマンスに与える影響を評価します。オフピーク時にデータを同期することをお勧めします。初期完全同期中、DTS はソースデータベースとデスティネーションデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。 完全データ同期中、同時 INSERT 操作を実行すると、デスティネーションデータベースのテーブルで断片化が発生します。完全データ同期が完了すると、デスティネーションデータベースで使用される表領域のサイズは、ソースデータベースで使用される表領域のサイズよりも大きくなります。 データ同期中は、DTS のみを使用してデスティネーションにデータを書き込むことをお勧めします。これにより、ソースとデスティネーション間でデータの不整合が発生しなくなります。たとえば、DTS 以外のツールを使用してデスティネーションにデータを書き込むと、DMS を使用してオンライン DDL 操作を実行するときに、デスティネーションでデータ損失が発生する可能性があります。 デフォルトでは、DTS はデータ同期タスクでデスティネーションデータベースの FOREIGN KEY 制約を無効にします。したがって、ソースデータベースのカスケード操作と削除操作は、デスティネーションデータベースに同期されません。

注意事項

• SSL が有効になっているかどうかは、ソース ApsaraDB RDS for MySQL インスタンスのエンドポイントとデスティネーション PolarDB クラスタで一致している必要があります。

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

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

• ソース ApsaraDB RDS for MySQL インスタンスのプライマリノードと読み取り専用ノードのホワイトリストが異なる場合は、読み取り専用ノードのホワイトリストをプライマリノードのホワイトリストに事前に追加して、読み取り専用ノードのホワイトリストをデスティネーション PolarDB クラスタに同期できるようにする必要があります。

• 論理移行方式による初期完全データ同期中、DTS はソースデータベースとデスティネーションデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

• 論理マイグレーション方式による完全同期中は、同時実行される INSERT 操作によって、ターゲットデータベースのテーブルで断片化が発生します。完全同期が完了すると、ターゲットデータベースの表領域は、ソースデータベースの表領域よりも大きくなります。

• 論理移行方式を使用する場合は、DTS タスクを手動で解放しないでください。

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

課金ルール

バックアップポリシー

• PolarDB の自動データバックアップのサイクルと開始時刻は、ApsaraDB RDS と同じです。

• ApsaraDB RDS と PolarDB のバックアップファイルの保存期間：

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

  • ApsaraDB RDS のバックアップファイルの保存期間が 14 日（除く）から 30 日（含む）の間の場合、PolarDB のレベル 1 バックアップファイルの保存期間は 14 日に固定されます。PolarDB ではレベル 2 バックアップ機能が有効になり、同じリージョン内のレベル 2 バックアップファイルの保存期間は 30 日に固定されます。ApsaraDB RDS のバックアップファイルの保存期間が 30 日を超える場合、PolarDB ではレベル 2 バックアップ機能が有効になり、同じリージョン内のレベル 2 バックアップファイルの保存期間は ApsaraDB RDS と同じです。

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

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

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

  • ApsaraDB RDS の高頻度バックアップファイルの保存期間が 120 分（除く）から 180 分（含む）の間の場合、PolarDB の高頻度バックアップファイルの保存期間は 180 分に固定されます。

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

移行が完了したら、「バックアップ設定を構成する」に記載されているように、コンソールでバックアップポリシーを変更できます。

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

ApsaraDB RDS for PostgreSQL インスタンスを PolarDB クラスタにアップグレードする場合、[エンドポイントで切り替え（接続の変更は不要）] を選択できます。その後、システムは ApsaraDB RDS for PostgreSQL インスタンスと PolarDB クラスタ間でエンドポイントを交換します。この場合、PolarDB クラスタに接続するためにアプリケーションの構成を変更する必要はありません。次の図は、ApsaraDB RDS for MySQL インスタンスと PolarDB クラスタ間のエンドポイント交換のルールを示しています。

エンドポイントを使用したスイッチオーバーを実行するには、次の制限事項に注意してください。

• ApsaraDB RDS for MySQL インスタンスと PolarDB クラスタのエンドポイントのみが交換されます。vSwitch や仮想 IP アドレスなどの他の構成は交換されません。

• ソース ApsaraDB RDS for MySQL インスタンスとデスティネーション PolarDB クラスタの両方にエンドポイントがある場合にのみ、エンドポイントを交換できます。デフォルトでは、デスティネーション PolarDB クラスタには、プライベートプライマリエンドポイントとプライベートクラスタエンドポイントのみがあります。ソース ApsaraDB RDS for MySQL インスタンスにさらにエンドポイントがある場合は、これらのエンドポイントを交換する場合、デスティネーション PolarDB クラスタに対応するエンドポイントを作成する必要があります。PolarDB クラスタと ApsaraDB RDS for MySQL インスタンスのエンドポイントを作成する方法については、「クラスタのエンドポイントを管理する」および「RDS インスタンスのエンドポイントを構成する」をご参照ください。

• ソース ApsaraDB RDS for MySQL インスタンスのプライマリエンドポイントは、エンドポイントのスイッチオーバープロセス中に常に切り替えられます。ソース ApsaraDB RDS for MySQL インスタンスのプライマリエンドポイントを、デスティネーション PolarDB クラスタのプライマリエンドポイントまたはデフォルトクラスタエンドポイントと交換することを選択できます。ApsaraDB RDS for MySQL インスタンスの専用プロキシエンドポイントと読み取り専用エンドポイントは、PolarDB クラスタのデフォルトクラスタエンドポイントとカスタムエンドポイントと交換できます。エンドポイントのスイッチオーバーを実行するかどうかを指定し、交換するエンドポイントペアを選択できます。PolarDB クラスタは最大 7 つのクラスタエンドポイントを持つことができます。したがって、ApsaraDB RDS for PostgreSQL インスタンスの最大 7 つの専用プロキシエンドポイントまたは読み取り専用エンドポイントを、PolarDB クラスタのクラスタエンドポイントと交換できます。

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

• プライベートエンドポイントを切り替える前に、ソース ApsaraDB RDS for PostgreSQL インスタンスとデスティネーション PolarDB クラスタが同じ仮想プライベートクラウド (VPC) に属していることを確認してください。そうしないと、スイッチオーバー後に元のサービスに接続できなくなります。

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

移行評価

移行評価機能は、PolarDB によって提供され、移行タスクの正常な実行と高い移行効率を保証します。この機能を使用すると、ApsaraDB RDS for MySQL インスタンスを PolarDB クラスタにアップグレードする前に、インスタンスステータス、移行タスクの依存関係、ソースインスタンスの属性などの前提条件を事前にチェックできます。これにより、移行の進行に影響を与える可能性のある要因を特定し、事前に問題を解決して、移行中の処理とリソースコストを削減できます。

詳細については、「移行評価」をご参照ください。

関連 API 操作