このトピックでは、ApsaraDB RDS for MySQLインスタンスのPolarDB for MySQLクラスターへのアップグレードに関するよくある質問に対する回答を提供します。
移行評価タスクで失敗したチェックアイテムを処理する方法を教えてください。
カテゴリ
チェックアイテム
解決策
基本情報の検証
ソースインスタンスの実行ステータス
ソースApsaraDB RDSインスタンスが [実行中] 状態である必要があります。
ソースインスタンスの読み取り /書き込みステータス
ソースApsaraDB RDSインスタンスは、[実行中] 状態および読み取り /書き込みモードである必要があります。
ソースインスタンスアカウントモード
ApsaraDB RDS for MySQLインスタンスでデータベースプロキシ (セーフモード) が有効になっている場合、特権アカウントが作成されるか、ApsaraDB RDS for MySQLインスタンスのネットワーク接続モードが高性能モードに切り替えられます。 詳細については、アカウントの作成および [製品の変更 /機能の変更] ApsaraDB RDSインスタンスのネットワーク接続モードのアップグレードをご参照ください。
PolarDBのサービスにリンクされたロール
PolarDBのサービスにリンクされたロールがアカウントに対して作成されます。
PolarDBサービスにリンクされたロールを作成する方法の詳細については、「PolarDBのサービスにリンクされたロールが作成されているかどうかの事前確認」をご参照ください。 API操作を呼び出して、PolarDBサービスにリンクされたロールを作成することもできます。
移行タスクの依存関係の検証
DTS権限
Alibaba Cloudアカウントには、DTS経由でクラウドリソースにアクセスする権限が必要です。
詳細については、「DTSによるAlibaba Cloudリソースへのアクセス許可」をご参照ください。
ソースインスタンスが空かどうか
データベースは、ソースApsaraDB RDSインスタンスに作成されます。 データを移行する前に、インスタンスにデータベースを作成する必要があります。
ソースインスタンステーブルエンジンの検証
ソースRDSインスタンスのテーブルストレージエンジンは、InnoDBまたはX-engineである必要があります。
ソースインスタンストリガーの検証
ソースApsaraDB RDSインスタンスに対してトリガーが作成されている場合は、まずトリガーを削除します。 それ以外の場合、移行プロセスは中断されます。
移行プロセスが完了した後、ターゲットPolarDBクラスターでトリガーを手動で作成できます。
ソースインスタンスの非プライマリキーテーブルの検証
ソースApsaraDB RDSインスタンスにプライマリキーのないテーブルが含まれている場合、データの同期後にターゲットPolarDBクラスターで重複データが発生する可能性があります。
特権アカウントを使用してソースApsaraDB RDSインスタンスのデータベースに接続し、次のSQL文を実行してプライマリキーなしでテーブルを照会できます。
SELECT t1.table_schema, t1.table_name FROM information_schema.TABLES t1 LEFT OUTER JOIN 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")プライマリキーなしでテーブルにプライマリキーを追加できます。
重複データが許容されることを確認した場合は、この評価結果を無視し、ApsaraDB RDS for MySQLインスタンスをPolarDB for MySQLクラスターにアップグレードしたときにエラーメッセージが返されたら、[続行] を選択します。
キー情報の検証
ソースインスタンスのルートアカウントの検証
システムアカウント構造の観点からApsaraDB RDS for MySQLとPolarDB間の互換性を確保し、移行中に移行先PolarDBクラスターのシステムアカウントが上書きされないようにするには、rootアカウントとaliyun_rootアカウントが移行元ApsaraDB for RDSインスタンスに同時に存在しないようにします。 詳細については、「ソースApsaraDB For RDSインスタンスからの冗長システムアカウントの削除」をご参照ください。
ApsaraDB RDS for MySQLインスタンスのPolarDB for MySQLクラスターへのアップグレードと、ApsaraDB RDS for MySQLインスタンスのPolarDB for MySQLクラスターへのクローンの違いは何ですか。
下表に違いを示します。
項目
ApsaraDB RDS for MySQLインスタンスをPolarDB for MySQLクラスターにアップグレードする
増分データ移行または同期がサポートされているかどうか
はい
いいえ
ソースApsaraDB RDS for MySQLインスタンスでの操作が影響を受けるかどうか
いいえ
いいえ
ソースデータベースとターゲットデータベースが異なるMySQLバージョンを使用できるかどうか
はい
はい
ターゲットPolarDB for MySQLクラスターのノード仕様は、ソースApsaraDB RDS for MySQLインスタンスのノード仕様と同じである必要がありますか。
ビジネス要件に基づいて、移行先PolarDB for MySQLクラスターのノード仕様を選択できます。 ソースApsaraDB RDS for MySQLインスタンスのノード仕様と同じかそれ以上のノード仕様を選択することを推奨します。
ApsaraDB RDS for MySQLインスタンスをPolarDBクラスターにアップグレードする前に、PolarDB for MySQLクラスターを購入する必要がありますか。
事前にPolarDB for MySQLクラスターを購入する必要はありません。 アップグレード時に、ソースApsaraDB RDS for MySQLインスタンスと同じデータを持つPolarDB for MySQLクラスターを購入して作成できます。
インスタンスからデータを移行すると、ソースApsaraDB RDS for MySQLインスタンスが影響を受けますか。
RDSインスタンスからデータを移行する場合、ソースApsaraDB RDS for MySQLインスタンスは影響を受けません。
スムーズな移行がソースApsaraDB RDS for MySQLインスタンスに与える影響は何ですか?
スムーズな移行は、ソースApsaraDB RDS for MySQLインスタンスの操作には影響しません。 ただし、データ移行には読み取り操作が含まれ、読み取り操作はソースApsaraDB RDS for MySQLインスタンスのクエリパフォーマンスに影響します。
スムーズな移行がデータベースで実行されるワークロードに与える影響は何ですか?
スムーズな移行により、移行の実行時にデータが失われることがなくなります。 サービスのダウンタイムは10分以下です。 サービスのダウンタイム中、サービスは一時停止され、増分データは生成されませんが、データベースは停止されません。 ビジネス要件に基づいて移行をロールバックできます。
移行をキャンセルするとどうなりますか?
移行をキャンセルすると、次の影響が発生します。
ソースインスタンスからターゲットクラスターへの同期リンクが切断されています。 ソースインスタンスは、ターゲットクラスターに関連付けられなくなりました。
移行先クラスターは読み書き可能になり、自動的にリリースされません。 ターゲットクラスターを使用しなくなった場合は、できるだけ早い機会にクラスターをリリースして、追加コストを回避します。
移行を手動でキャンセルするときに、クラスターのバイナリログ機能を無効にするかどうかを指定できます。 移行が自動的にキャンセルされると、バイナリログ機能は無効になりません。
説明クラスターのバイナリログ機能を無効にすると、クラスターの書き込みパフォーマンスがわずかに向上します。 バイナリログ機能を無効にすると、既存のバイナリログが保持されます。 バイナリログを削除するには、まずバイナリログの保持期間を短縮します。 バイナリログが自動的に削除されたら、バイナリログ機能を無効にできます。 バイナリログ機能を無効にすると、クラスターは自動的に再起動します。 再起動タスクは5分以内に完了します。 再起動中、サービスは約40秒間中断されます。 再起動時間は、データ量とテーブル数によって異なります。 オフピーク時にはバイナリログ機能を無効にし、アプリケーションがデータベースサービスに自動的に再接続できるようにすることをお勧めします。
ビジネスをPolarDBクラスターに切り替えた後、アプリケーションのエンドポイントを変更する必要がありますか。
エンドポイントの切り替え (接続変更が不要な場合) を選択した場合、ソースApsaraDB RDS for MySQLインスタンスとターゲットPolarDBクラスター間でエンドポイントが自動的に交換されます。 この場合、PolarDBクラスターに接続するためにアプリケーションの設定を変更する必要はありません。
移行またはアップグレード中に、移行先クラスターの特権アカウントに特定の権限がない場合、移行またはアップグレード中にアカウントの権限を変更できますか。
いいえ、移行またはアップグレード中に特権アカウントの権限を変更することはできません。 移行先クラスターの特権アカウントの権限は、移行元インスタンスから同期されます。 移行またはアップグレード後に特定のデフォルト権限がない場合は、PolarDBコンソールの [アカウント] ページで特権アカウントの権限をリセットできます。
ビジネスを切り替えたときに、エンドポイントの切り替え (接続変更が不要な場合) を選択しました。 新しいエンドポイントを使用してPolarDBクラスターに接続する必要があるのはなぜですか。
エンドポイントは、ソースApsaraDB RDS for MySQLインスタンスとターゲットPolarDBクラスターにエンドポイントがある場合にのみ交換できます。 デフォルトでは、内部ネットワーク内のプライマリエンドポイントのみが交換されます。 他のエンドポイントに切り替える場合は、切り替え前にエンドポイントを作成する必要があります。 PolarDBクラスターのエンドポイントを作成する方法については、「エンドポイントの管理」をご参照ください。 ApsaraDB RDS For MySQLインスタンスのエンドポイントを作成する方法については、「RDSインスタンスのエンドポイントの設定」をご参照ください。
ソースApsaraDB RDS for MySQLインスタンスには読み取り専用インスタンスが含まれています。 エンドポイントの切り替え (接続変更が不要な場合) を選択した場合、ソースApsaraDB RDS for MySQLインスタンスとターゲットPolarDBクラスター間で読み取り専用インスタンスのエンドポイントを交換できますか。
クラスターエンドポイントとカスタムエンドポイントが移行先PolarDBクラスターに存在する場合、[エンドポイントで切り替える (接続変更不要)] を選択すると、移行元ApsaraDB RDS for MySQLインスタンスと移行先PolarDBクラスターの間で読み取り専用インスタンスのエンドポイントを交換できます。
切り替え後、PolarDBデータベースへの接続またはデータのデータベースへの書き込みはできません。 これはなぜですか。
エンドポイントが交換された後、ドメインネームシステム (DNS) キャッシュデータの有効期限が切れたために問題が発生する可能性があります。 PolarDBクラスター内のデータベースが接続に失敗したり、読み取り操作のみをサポートしたりする場合があります。 問題を解決するには、DNSキャッシュを更新することを推奨します。
ApsaraDB RDS for MySQLインスタンスをPolarDBクラスターにアップグレードする前に、互換性テストを実行してワークロードを評価できますか。
互換性テストとワークロード評価のために、「ApsaraDB RDS for MySQLインスタンスをPolarDB for MySQLクラスターにクローンする」で説明されている操作を実行して、ApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにデータをクローンすることができます。 次に、このトピックの操作を実行して、ApsaraDB RDS for MySQLインスタンスをPolarDBクラスターにアップグレードします。
ビジネスを切り替えた後、PolarDBコンソールに 完全な移行 ボタンが表示されないのはなぜですか。
完全な移行 ステップを完了すると、繰り返し操作を防ぐために [移行の完了] ボタンは表示されません。
PolarDBクラスターへのアップグレード後、移行先PolarDBクラスターの移行元ApsaraDB RDS for MySQLインスタンスから同じユーザー名とパスワードを複製する必要がありますか。
いいえ。 移行先のPolarDBクラスターには、移行元ApsaraDB RDS for MySQLインスタンスのアカウント、パスワード、データベース、IPアドレスホワイトリスト、および必要なパラメーターが含まれています。
SSLが有効になっているソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにデータを移行するにはどうすればよいですか。
SSLが有効になっているソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにデータを物理的または論理的に移行できます。
説明ApsaraDB RDS for MySQLインスタンスのエンドポイントでSSLが有効になっており、[エンドポイントで切り替える] を選択してエンドポイントを切り替える場合は、PolarDBクラスターのエンドポイントでSSLが有効になっていることを確認してください。
透過的データ暗号化 (TDE) が有効になっているソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにデータを移行するにはどうすればよいですか。
TDEが有効になっているソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにデータを物理的または論理的に移行できます。
クロスバージョンのアップグレードを実行できますか? たとえば、ApsaraDB RDS For MySQL 5.6インスタンスをPolarDB for MySQL 8.0クラスターにアップグレードできますか。
論理的な移行方法を使用する場合、PolarDBクラスターは別のMySQLバージョンを実行できます。
インスタンスをPolarDB for MySQLクラスターにアップグレードする前に、ソースApsaraDB RDS for MySQLインスタンスのData Transmission Service (DTS) データ同期タスクが開始された場合、アップグレードの実行時にタスクが影響を受けますか。
いいえ。 このトピックで説明する操作を実行すると、最初に完全なデータがソースApsaraDB RDS for MySQLインスタンスから新しいPolarDBクラスターにクローンされます。 次に、増分データがソースApsaraDB RDS for MySQLインスタンスからPolarDBクラスターにリアルタイムで同期されます。 PolarDBクラスターへのアップグレードは、ソースApsaraDB RDS for MySQLインスタンスの操作には影響しません。 ApsaraDB RDS for MySQLインスタンスは、DTSデータ同期タスクのデータソースまたは宛先のままです。
アップグレード後、ソースApsaraDB RDS for MySQLインスタンスは読み取り専用になります。 ソースApsaraDB RDS for MySQLインスタンスがDTSデータ同期タスクのデータデスティネーションとして使用されている場合、インスタンスにデータを書き込むことはできません。 DTSデータ同期タスクのターゲットデータベースを新しいPolarDBクラスターに変更する必要があります。 ソースApsaraDB RDS for MySQLインスタンスがDTSデータ同期タスクのデータソースとして使用されている場合、アップグレード後の早い機会にDTSデータ同期タスクのデータソースを新しいPolarDBクラスターに変更することを推奨します。
DTSタスクのソースまたはターゲットデータベースインスタンスは、ModifyDtsJobEndpoint操作を呼び出すことによってのみ変更できます。 操作の詳細については、「ModifyDtsJobEndpoint」をご参照ください。