PolarDB:アップグレード評価

カテゴリ

チェックアイテム

解決策

基本情報の検証

ソースインスタンスの実行ステータス

ソースPolarDBクラスターは [実行中] 状態である必要があります。

ソースインスタンスの読み取り /書き込みステータス

ソースPolarDBクラスターは、[実行中] 状態で、読み取り /書き込みモードである必要があります。

PolarDBのサービスにリンクされたロール

PolarDBのサービスにリンクされたロールがアカウントに対して作成されます。

PolarDBサービスにリンクされたロールを作成する方法の詳細については、「PolarDBのサービスにリンクされたロールが作成されているかどうかの事前確認」をご参照ください。 API操作を呼び出して、PolarDBサービスにリンクされたロールを作成することもできます。

移行タスクの依存関係の検証

DTS権限

Alibaba Cloudアカウントには、DTS経由でクラウドリソースにアクセスする権限が必要です。

詳細については、「DTSによるAlibaba Cloudリソースへのアクセス許可」をご参照ください。

ソースインスタンスのバイナリログの検証

メジャーバージョンのアップグレードを実行する前に、ソースPolarDBクラスターのバイナリログを有効にする必要があります。 詳細については、「バイナリログの有効化」をご参照ください。

ソースインスタンスが空かどうか

データベースはソースPolarDBクラスターに作成されます。 メジャーバージョンのアップグレードを実行する前に、クラスターにデータベースを作成する必要があります。

ソースインスタンストリガーの検証

ソースPolarDBクラスターに対してトリガーが作成されている場合は、まずトリガーを削除します。 それ以外の場合、アップグレードプロセスは中断されます。

アップグレードプロセスが完了した後、ターゲットPolarDBクラスターでトリガーを手動で作成できます。

ソースインスタンスの非プライマリキーテーブルの検証

ソースPolarDBクラスターにプライマリキーのないテーブルが含まれている場合、データの同期後にターゲットPolarDBクラスターで重複データが発生する可能性があります。

特権アカウントを使用してソースPolarDBクラスターのデータベースに接続し、次のSQL文を実行して、プライマリキーなしでテーブルをクエリできます。

SELECT t1.table_schema, t1.table_name
information_schema.TABLES t1 LEFT OUTERから
参加information_schema.TABLE_CONSTRAINTS t2 
  ON t1.table_schema = t2.TABLE_SCHEMA AND t1.table_name = t2.TABLE_NAME AND t2.CONSTRAINT_NAME 
  IN ("PRIMARY")
WHERE t2.table_name IS NULL AND t1.table_type = "BASE TABLE" AND t1.table_SCHEMA NOT IN ("information_schema" 、"performance_schema" 、"mysql" 、"sys") 

プライマリキーなしでテーブルにプライマリキーを追加できます。

重複データが許容されることを確認した場合は、この評価結果を無視して、メジャーバージョンのアップグレードを実行したときにエラーメッセージが返されるときに続行を選択します。

キー情報の検証

ソースインスタンスのルートアカウントの検証

アップグレード中にターゲットPolarDBクラスターのシステムアカウントが上書きされないようにするには、ソースPolarDBクラスターにrootアカウントとaliyun_rootアカウントが同時に存在しないようにします。 したがって、アップグレードを実行する前に、ソースクラスターの冗長なシステムアカウントを削除する必要があります。 詳細については、「ソースPolarDB For MySQLクラスターからの冗長システムアカウントの削除」をご参照ください。