概要 - PolarDB - Alibaba Cloud ドキュメントセンター

このトピックでは、PolarDB for MySQLクラスターのアップグレードのソリューション、前提条件、制限、および課金ルールについて説明します。

ソリューションの概要

PolarDB for MySQLでは、PolarDB for MySQLクラスターをさまざまなメジャーバージョンとエディション間でアップグレードできます。アップグレード中、システムは自動的にターゲットPolarDBクラスターを作成し、ソースクラスターからデータを同期します。移行先のPolarDB for MySQLクラスターは、移行元のPolarDB for MySQLクラスターのアカウント、データベース、IPホワイトリスト、および必要なパラメーターを保持します。

バージョンアップ
たとえば、PolarDB For MySQL 5.6クラスターをPolarDB for MySQL 5.7クラスターにアップグレードしたり、PolarDB for MySQL 5.6クラスターをPolarDB for MySQL 8.0.1クラスターにアップグレードしたりできます。
エディションのアップグレード
cluster EditionのPolarDB for MySQLクラスターをMulti-master Cluster (Database/Table) EditionのPolarDB for MySQLクラスターにアップグレードできます。
仕様が定義されたクラスターをサーバーレスクラスターにアップグレードできます。

詳細については、「手順」をご参照ください。

メリット

ソースクラスターのエンドポイントは保持されます。アプリケーションの接続設定を変更することなく、新しいバージョンに切り替えることができます。
アップグレードは30日以内に無料です。仮想ネットワークオペレーター (VNO) アカウントとRAMユーザーは、無料トライアルを利用できません。
アップグレード中にデータの損失は発生しません。
増分データ移行をサポートしています。これにより、サービスのダウンタイムが10分未満でデータを移行できます。
ホットアップグレードがサポートされています。アップグレード中に一時的な接続が1つだけ発生します。
ロールバックをサポートしています。アップグレードが失敗した場合、クラスターは10分以内に復元できます。

前提条件

お使いのクラスターは、cluster EditionのPolarDB for MySQL Enterprise Editionクラスターです。

制限事項

カテゴリ	説明
ソースデータベースの制限	ソースデータベースが属するサーバーには、十分な出力帯域幅が必要です。そうでない場合、アップグレード速度が影響を受けます。移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースは重複するデータレコードを含み得ます。増分移行を実行するには、バイナリログ機能を有効にする必要があります。また、PolarDBコンソールで`loose_polar_log_bin`パラメーターをONに設定する必要があります。それ以外の場合、事前チェック中にエラーメッセージが返され、アップグレードタスクを開始できません。説明完全データ移行タスクと増分データ移行タスクの両方で、ソースデータベースのバイナリログを少なくとも7日間保存する必要があります。完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。そうしないと、Data Transmission Service (DTS) がバイナリログの取得に失敗し、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生します。上記の要件に基づいて、必ずバイナリログの保持期間を指定してください。そうしないと、DTSのサービスレベル契約 (SLA) に記載されているサービスの信頼性とパフォーマンスを達成できません。ソースデータベースで実行する操作の制限: スキーマ移行中および完全データ移行中は、DDL操作を実行してデータベースまたはテーブルのスキーマを変更しないでください。それ以外の場合、データ移行タスクは失敗します。
SQL文の制限	次のDML操作がサポートされています。インサート更新削除次のDDL操作がサポートされています。 ALTER TABLEとALTER VIEW CREATE FUNCTION、CREATE INDEX、CREATE PROCEDURE、CREATE TABLE、およびCREATE VIEW ドロップインデックスとドロップテーブル RENAMEテーブル TRUNCATEテーブル
その他の制限	新しいデータベースは移行できません。新しいデータベースを移行するには、DTSコンソールに移動し、同期オブジェクトを変更し、新しいデータベースを順方向および逆方向同期タスクに追加します。データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。オフピーク時にデータを移行することを推奨します。完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。完全データ移行中、INSERTの同時操作により、ターゲットデータベースのテーブルが断片化されます。完全データ移行が完了すると、移行先データベースの使用表領域のサイズは移行元データベースのサイズよりも大きくなります。 FLOATまたはDOUBLEデータ型の列の精度設定がビジネス要件を満たしていることを確認します。 DTSは`ROUND(COLUMN,PRECISION)` 関数を使用して、FLOATまたはDOUBLEデータ型の列から値を取得します。精度値を指定しない場合、DTSはFLOATデータ型の精度を38桁に設定し、DOUBLEデータ型の精度を308桁に設定します。 DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。ワークロードを移行先クラスターに切り替える前に、データ移行タスクを停止またはリリースします。 `revoke`コマンドを実行して、移行先クラスターへのアクセスにDTSが使用するアカウントの書き込み権限を取り消すこともできます。それ以外の場合、タスクの再開後、ソースデータベースのデータがターゲットクラスターのデータを上書きします。
その他の問題	DTSは、ソースデータベースで`CREATE DATABASE IF NOT EXISTS 'test'` ステートメントを定期的に実行して、バイナリログファイルの位置を移動します。

使用上の注意

ソースクラスターのエンドポイントでSSLが有効になっていて、[エンドポイントで切り替える] を選択した場合、ターゲットクラスターのエンドポイントでSSLが有効になっていることを確認します。
グローバルデータベースネットワーク (GDN) に追加されたクラスターのバージョンをアップグレードすることはできません。
SSLは、マルチマスタークラスター (データベース /テーブル) エディションのPolarDB for MySQLクラスターのエンドポイントではサポートされていません。したがって、エンドポイントでSSLが有効になっているソースクラスターのエディションアップグレードをMulti-master cluster (Database/Table) editionのクラスターに実行する場合、エンドポイントとの切り替えはサポートされません。
アップグレード中、最初の完全データ同期では、ソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースが使用されます。これにより、データベースの負荷が増加する可能性があります。
アップグレード中、最初の完全データ同期は同時INSERT操作を実行し、ターゲットデータベースのテーブルに断片化が発生します。完全なデータ同期が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースのテーブルスペースよりも大きくなります。
アップグレード中にDTSタスクを手動でリリースしないでください。
完全なデータ同期を完了するには時間がかかります。消費時間は、データの量に基づいて変化する。完全データ同期中、宛先は [作成中] 状態になります。
アップグレードするPolarDBクラスターが既存のDTSタスクの送信元または送信先である場合、クラスターがアップグレードされた後、DTSタスクの送信元または送信先クラスターをアップグレードされたPolarDBクラスターに変更する必要があります。このようなタスクには、データ同期タスク、データ移行タスク、および変更追跡タスクが含まれます。詳細については、「同期するオブジェクトの変更」をご参照ください。

課金ルール

次のルールに基づいて、30日以内のクラスターのメジャーバージョンのアップグレード中に、特定のサービスに追加料金は請求されません。仮想ネットワークオペレーター (VNO) アカウントとRAMユーザーは、無料トライアルを利用できません。
- アップグレード中に、システムは自動的に移行元クラスターから移行先クラスターへのDTSデータ同期タスクを作成します。アップグレードが30日以内に完了した場合、DTSタスクの料金は発生しません。それ以外の場合は、DTSタスクに対して課金されます。
- 次のルールに基づいて、ターゲットPolarDBクラスターに対して課金されます。
  - 従量課金クラスターの場合、アップグレード中にクラスターの料金は発生しません。次のシナリオでは、従量課金の課金方法に基づいてクラスターに対して課金されます。
    - アップグレードが完了しました。 詳細については、「手順」をご参照ください。
      説明
      ソースクラスターとターゲットクラスター間のデータ同期が停止すると、アップグレードが完了します。
    - アップグレードが停止しました。たとえば、事前チェックが失敗した場合、またはクラスターがアップグレード中の場合、アップグレードはキャンセルされます。
  - サーバーレスクラスターの場合、クラスターは [実行中] 状態になった後に課金されます。
  - サブスクリプションクラスターの場合、クラスターの作成時に支払いを完了する必要があります。
    説明
    コストを削減するために、従量課金方法を使用するPolarDBクラスターを送信先として選択することを推奨します。
メジャーバージョンをアップグレードしたサブスクリプションクラスターが不要になった場合は、サブスクリプション解除の払い戻しを申請して、リソースとコストを削減できます。詳細については、「アップグレード後のサブスクリプション解除」をご参照ください。

エンドポイントの切り替えSwitch with endpoints

PolarDB for MySQLクラスターをアップグレードすると、エンドポイント付きスイッチ機能がサポートされます。システムは、ソースクラスタと宛先クラスタのエンドポイントを自動的に切り替えます。次の図は、エンドポイントマッピングを示しています。

バージョンアップグレードのエンドポイントマッピング
Cluster editionからMulti-master Cluster (Database/Table) Editionへのエディションアップグレードのエンドポイントマッピング
エディションアップグレードでは、切り替え元クラスターと移行先クラスターのエンドポイントを指定できます。たとえば、ソースクラスターのプライマリエンドポイントと宛先クラスターのクラスターエンドポイント、ソースクラスターのプライマリエンドポイントと宛先クラスターのカスタムエンドポイント、およびソースクラスターのクラスターエンドポイントと宛先クラスターのカスタムエンドポイントを切り替えることができます。次の図は、エンドポイントの内部マッピングを示しています。

エンドポイント付きスイッチ機能を使用する場合は、次の点に注意してください。

ソースおよび宛先クラスターのエンドポイントのみが切り替えられます。 vSwitchや仮想IPアドレスなどのその他の設定は変更されません。
ソースクラスタと宛先クラスタの両方にエンドポイントがある場合にのみ、エンドポイントを切り替えることができます。デフォルトでは、内部ネットワークのプライマリエンドポイントのみが切り替えられます。
バージョンアップグレードでエンドポイントを使用する切り替えを選択した場合、移行元クラスターと移行先クラスターのプライマリエンドポイントが切り替えられます。複数のエンドポイントグループを切り替えるかどうかを選択できます。
エディションのアップグレードでエンドポイントの切り替えを選択した場合、切り替え元クラスターと切り替え先クラスターのエンドポイントを指定できます。複数のエンドポイントグループを切り替えるかどうかを選択できます。
別のエンドポイントに切り替える場合は、切り替え前にエンドポイントを作成する必要があります。 PolarDBクラスターのエンドポイントを作成する方法の詳細については、「クラスターのエンドポイントの管理」をご参照ください。
エンドポイントが切り替えられるとき、ポートは切り替えられません。送信元クラスターのポートが送信先クラスターのポートと同じであることを確認します。デフォルトでは、ポート3306はPolarDBクラスターに使用されます。ポートを変更する方法の詳細については、「エンドポイントとポート番号の変更」をご参照ください。
エンドポイントの切り替え後、DNSキャッシュデータの有効期限が切れたために問題が発生する可能性があります。 PolarDBクラスター内のデータベースが接続に失敗したり、読み取り操作のみをサポートしたりする場合があります。この問題を解決するには、DNSキャッシュを更新することを推奨します。

アップグレード評価

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

詳細については、「アップグレード評価」をご参照ください。