このトピックでは、RDS for MySQL インスタンスを PolarDB for MySQL クラスターにアップグレードする際によくある質問について説明します。
Q：移行評価のチェック項目が失敗した場合はどうすればよいですか。
カテゴリ
チェック項目
解決策
注意事項
イベントチェック
ソース RDS インスタンスにイベントがありますが、DTS はイベントの同期をサポートしていません。宛先 PolarDB クラスターに手動でイベントを同期する必要があります。
基本情報検証
ソースインスタンスの実行ステータス
ソース 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 インスタンスにトリガーが作成されている場合、まずトリガーを削除してください。そうしないと、移行プロセスが中断されます。
説明ビジネス要件に応じて、次の文を実行してソース ApsaraDB RDS インスタンスのトリガーを削除できます。
-- ソース ApsaraDB RDS インスタンスに存在するすべてのトリガーを表示します。 SHOW TRIGGERS; -- ソース ApsaraDB RDS インスタンスから特定のトリガーを削除します。 DROP TRIGGER trigger_name;移行プロセスが完了した後、宛先 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 クラスターのシステムアカウントが上書きされるのを防ぐため、ソース ApsaraDB RDS インスタンスに root アカウントと aliyun_root アカウントが同時に存在しないことを確認してください。詳細については、「ソース ApsaraDB RDS インスタンスからの冗長なシステムアカウントの削除」をご参照ください。
Q：ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスターにアップグレードする場合と、ApsaraDB RDS for MySQL インスタンスを PolarDB for MySQL クラスターにクローン作成する場合の違いは何ですか。
A：違いは次の表のとおりです。
項目
RDS for MySQL インスタンスの PolarDB for MySQL クラスターへのアップグレード
ApsaraDB RDS for MySQL インスタンスの PolarDB for MySQL クラスターへのクローン作成
増分データの移行または同期をサポート
サポート
いいえ
ソース RDS インスタンスの操作への影響
影響なし
影響なし
ソースとターゲットの MySQL バージョンは異なっていてもよいか
異なっていてもよい
異なっていてもよい
Q：宛先 PolarDB for MySQL クラスターのノード仕様は、ソース RDS for MySQL インスタンスのインスタンスタイプと同じである必要がありますか。
A：必ずしも同じである必要はありません。必要に応じて PolarDB for MySQL クラスターの仕様を選択できます。仕様はソース RDS インスタンスのインスタンスタイプを下回らないようにすることを推奨します。
Q：アップグレード前に PolarDB for MySQL クラスターを購入する必要がありますか。
A：事前に PolarDB for MySQL クラスターを購入する必要はありません。アップグレードプロセスにより、ソース RDS インスタンスと同じデータを持つ PolarDB クラスターが作成されます。
Q：RDS からの移行はソース RDS インスタンスに影響しますか。
A：いいえ、影響しません。ソース RDS インスタンスの通常運用に影響はありません。
Q：スムーズな移行はソース RDS インスタンスのパフォーマンスに影響しますか。
A：移行はソース RDS インスタンスの可用性には影響しません。ただし、データ移行にはクエリ操作が含まれるため、ソース RDS インスタンスのクエリパフォーマンスの一部を消費します。
Q：スムーズな移行はビジネスに影響しますか。
A：スムーズな移行では、データが失われることはありません。ダウンタイムは 10 分未満です。ダウンタイム中、新しいデータが生成されないようにビジネスアプリケーションは一時停止されますが、データベースは停止しません。必要に応じて移行をロールバックすることもできます。
Q：移行をキャンセルするとどうなりますか。
A：移行をキャンセルすると、次の影響があります。
ソースクラスターと宛先クラスター間の同期リンクが切断され、クラスターは関連付けられなくなります。
宛先クラスターは読み書き可能になり、自動的にはリリースされません。このクラスターが不要になった場合は、不要な料金が発生しないように、できるだけ早くリリースしてください。
手動で移行をキャンセルする場合、クラスターのバイナリログ記録を無効にするかどうかを選択できます。移行が自動的にキャンセルされた場合、バイナリログ記録は無効になりません。
説明バイナリログ記録を無効にすると、書き込みパフォーマンスがわずかに向上します。バイナリログ記録を無効にした後も、既存のバイナリログファイルは保持されます。バイナリログ記録を無効にする前に、バイナリログファイルの保持期間を短縮し、不要なファイルが自動的に削除されるのを待つことができます。バイナリログ記録を無効にすると、クラスターは自動的に再起動します。再起動は 5 分以内に完了します。再起動中、約 40 秒の瞬断が発生します。具体的な時間は、データ量とテーブル数によって異なります。この操作はオフピーク時に実行し、アプリケーションに再接続メカニズムがあることを確認することを推奨します。
Q：アップグレードが完了し、ビジネスを PolarDB に切り替えた後、アプリケーションのエンドポイントを変更する必要がありますか。
A：スイッチオーバー中に エンドポイントの切り替え (接続変更が不要な場合) を選択できます。システムは RDS と PolarDB のエンドポイントを自動的に交換します。これにより、アプリケーションは構成を変更することなく自動的に PolarDB に接続します。
Q：移行とアップグレード中に宛先クラスターの特権アカウントに一部の権限が不足している場合、プロセス中にアカウントの権限を変更できますか。
A：いいえ、できません。移行とアップグレードのプロセス中にアカウントの権限を変更することはできません。宛先クラスターの特権アカウントの権限は、ソースインスタンスから同期されます。アップグレード後に特権アカウントにデフォルトの権限が不足している場合は、コンソールのアカウント管理ページで権限をリセットできます。
Q：移行で エンドポイントの切り替え (接続変更が不要な場合) を選択しました。移行完了後、なぜ PolarDB クラスターは新しいエンドポイントを使用しているのですか。
A：エンドポイントの交換は、ソース RDS インスタンスと宛先 PolarDB クラスターの両方に対応するエンドポイントが存在する場合にのみ可能です。デフォルトでは、プライベートネットワークのプライマリエンドポイントのみが切り替え可能です。他のエンドポイントを切り替えるには、スイッチオーバー前に宛先クラスターに対応するエンドポイントを作成する必要があります。そうしないと、エンドポイントは切り替えられません。PolarDB クラスターと RDS インスタンスのエンドポイントの作成方法の詳細については、「エンドポイントの管理」および「エンドポイントの設定」をご参照ください。
Q：ソース RDS インスタンスに読み取り専用インスタンスも含まれています。エンドポイントの切り替え (接続変更が不要な場合) を選択した場合、読み取り専用インスタンスのエンドポイントも切り替えられますか。
A：はい。[エンドポイントで切り替え (接続の変更は不要)] を選択すると、PolarDB クラスターに対応するクラスターエンドポイントまたはカスタムエンドポイントがある場合、読み取り専用 RDS インスタンスのエンドポイントを切り替えることができます。
Q：スイッチオーバーが成功した後、なぜ PolarDB データベースに接続できない、または接続が読み取り専用になるのですか。
A：ドメイン名が切り替えられた後、サーバーのローカル DNS キャッシュが原因で接続の問題が発生することがあります。キャッシュの TTL (Time To Live) の間、アプリケーションがデータベースに接続できない、または読み取り専用接続を確立する可能性があります。サーバーの DNS キャッシュをリフレッシュすることを推奨します。
Q：PolarDB への一括アップグレードの前に、まず互換性テストと簡単な移行ワークロード評価を実行できますか。
A：はい、できます。データを PolarDB クラスターにクローンして、互換性テストとワークロード評価を実行できます。詳細については、「ApsaraDB RDS for MySQL インスタンスの PolarDB for MySQL クラスターへのクローン作成」をご参照ください。問題がないことを確認した後、このトピックの手順に従って PolarDB への一括アップグレードを実行できます。
Q：移行のスイッチオーバー後、なぜ PolarDB コンソールに 完全な移行 ボタンが表示されないのですか。
A：すでに 完全な移行 ボタンをクリックした場合、再度操作を実行できないようにボタンは非表示になります。
Q：PolarDB への一括アップグレード後、ソース RDS インスタンスと同じアカウントとパスワードを宛先 PolarDB クラスターに再度作成する必要がありますか。
A：いいえ、その必要はありません。アップグレード後、PolarDB クラスターには、ソース RDS インスタンスのアカウント、パスワード、データベース、IP ホワイトリスト、および必須パラメーターが含まれます。
Q：ソース RDS インスタンスで SSL が有効になっています。これを PolarDB クラスターに移行するにはどうすればよいですか。
A：はい、SSL が有効になっている RDS インスタンスは、一括アップグレード機能を使用して PolarDB クラスターにアップグレードできます。物理移行または論理移行のいずれかの方法で移行を実行できます。
説明[エンドポイントで切り替え] を選択して SSL が有効になっているエンドポイントを切り替える場合は、PolarDB クラスターの対応するエンドポイントでも SSL が有効になっていることを確認してください。
Q：ソース RDS インスタンスで TDE (透過的データ暗号化) が有効になっています。これを PolarDB クラスターに移行するにはどうすればよいですか。
A：はい、TDE が有効になっている RDS インスタンスは、一括アップグレード機能を使用して PolarDB クラスターにアップグレードできます。物理移行または論理移行のいずれかの方法で移行を実行できます。
Q：一括アップグレードはクロスバージョンアップグレードをサポートしていますか。たとえば、RDS MySQL 5.6 インスタンスを PolarDB for MySQL 8.0 クラスターにアップグレードするなどです。
A：論理移行 (DTS データ同期) 方式は、一括アップグレード機能のクロスバージョンアップグレードをサポートしています。
Q：PolarDB for MySQL への一括アップグレードの前に、ソース RDS インスタンスで DTS データ同期タスクがすでに実行されている場合、アップグレードはこのタスクに影響しますか。
A：いいえ、影響しません。一括アップグレード中、まず RDS インスタンスから新しい PolarDB クラスターに完全データコピーが複製されます。その後、増分データが継続的に PolarDB クラスターに同期されます。既存の DTS タスクのデータソースはソース RDS インスタンスのままであり、PolarDB へのアップグレードはソース RDS インスタンスの操作に影響しません。
移行のスイッチオーバー後、ソース RDS インスタンスは読み取り専用になります。RDS インスタンスが DTS データ同期タスクの宛先である場合、インスタンスへの書き込み操作は失敗します。この場合、DTS タスクの宛先を新しい PolarDB クラスターに変更する必要があります。RDS インスタンスが DTS タスクのソースである場合は、スイッチオーバー後できるだけ早く DTS タスクのソースも新しい PolarDB クラスターに変更することを推奨します。
現在、DTS タスクのソースインスタンスまたは宛先インスタンスは OpenAPI を使用してのみ変更できます。詳細については、「DTS タスクのソースインスタンスまたは宛先インスタンスの変更」をご参照ください。
Q：RDS インスタンスをリリースまたはゾーン変更しようとすると、「The specified operation is disabled while the instance is undergoing an engine migration」というエラーメッセージが返されます。どうすればよいですか。
A：このエラーは、RDS インスタンスが「RDS for MySQL から PolarDB for MySQL への一括アップグレード」機能を使用してアップグレード中であるために発生します。PolarDB コンソールに移動して、移行中の PolarDB クラスターがあるかどうかを確認してください。RDS インスタンスをリリースまたはゾーン変更する前に、移行のスイッチオーバーを含む、すべてのアップグレード操作を PolarDB クラスターに対して完了する必要があります。