PolarDB:概要

概要

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

• ApsaraDB RDS for MySQLインスタンスを、同じまたは異なるMySQLバージョンを実行するPolarDB 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クラスターへのアップグレード、ApsaraDB RDS for MySQLインスタンスの異なるバージョンを実行するPolarDB for MySQLクラスターへのアップグレードのシナリオで使用されます。 この方法は、データ伝送サービス (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に切り替えることができます。

• アップグレードは30日以内に無料です。 仮想ネットワークオペレーター (VNO) アカウントとRAMユーザーは、無料トライアルを利用できません。

• 移行中にデータの損失は発生しません。

• 増分データ移行をサポートしています。 サービスのダウンタイムは 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インスタンスでデータベースプロキシ (セーフモード) が有効になっている場合、特権アカウントが作成されるか、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アドレスは、エンドポイントとの切り替えではサポートされません。

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

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

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

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

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

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

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

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

    項目

    説明

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

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

  • 次の表に、SQL文の制限を示します。

    タイプ	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テーブル TRUNCATEテーブル

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

    項目

    説明

    その他の制限

    データを同期する前に、ソースデータベースとターゲットデータベースのパフォーマンスに対するデータ同期の影響を評価します。 オフピーク時にデータを同期することを推奨します。 最初の完全データ同期中、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クラスターに対してのみ課金されます。

• ターゲットPolarDBクラスターで従量課金が使用されている場合、クラスターの料金は発生しません移行プロセスを通じて課金されます。 次の操作の後、従量課金制で課金されます。

  • ステップ4: 移行の完了が完了しました。

    説明

    • 移行元インスタンスと移行先クラスター間の同期リンクが中断されると、移行が完了します。

    • 移行は30日以内に完了する必要があります。

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

    この場合、アップグレードを停止しても、移行先クラスターは既に作成されています。 クラスターが不要になった場合は、クラスターをリリースします。 詳細については、「クラスターのリリース」をご参照ください。

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

論理的移行

論理移行方法が使用されている場合、データ移行およびデータ同期タスクに対しては課金されません。 ターゲットPolarDBクラスターに対してのみ課金されます。 仮想ネットワークオペレーター (VNO) アカウントとRAMユーザーは、無料トライアルを利用できません。

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

  • ステップ4: 移行の完了が完了しました。

    説明

    • 移行元インスタンスと移行先クラスター間の同期リンクが中断されると、移行が完了します。

    • 移行は30日以内に完了する必要があります。 30日後にDTSを使用して実装されたデータ移行と同期に対して課金されます。

  • 移行が停止した後 (事前チェックが失敗した場合の移行のキャンセル、および移行中のアップグレードのキャンセルを含む) 。

    この場合、アップグレードを停止しても、移行先クラスターは既に作成されています。 クラスターが不要になった場合は、クラスターをリリースします。 詳細については、「クラスターのリリース」をご参照ください。

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

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

バックアップポリシー

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

• ApsaraDB RDSおよびPolarDB上のバックアップファイルの保持期間:

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

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

  • RDSバックアップが長期間保持される場合、レベル1バックアップのPolarDB保持期間は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) に属していることを確認してください。 それ以外の場合、切り替え後に元のサービスを接続できません。

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

移行評価

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

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

関連する API 操作