すべてのプロダクト
Search

このプロダクト

    PolarDB:よくある質問

    ドキュメントセンター

    PolarDB:よくある質問

    最終更新日:Sep 23, 2026

    このトピックでは、ApsaraDB RDS for MySQL から PolarDB for MySQL へのワンクリックアップグレードに関するよくある質問をいくつか紹介します。

    • Q：移行評価のチェック項目が失敗した場合はどうすればよいですか。

      カテゴリ

      チェック項目

      解決策

      通知

      イベントチェック

      ソース RDS インスタンスにはイベントがありますが、DTS はイベントの同期をサポートしていません。手動でイベントを移行先の PolarDB クラスターに同期する必要があります。

      ソースインスタンスの基本情報チェック

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

      ソース RDS インスタンスは 実行中 状態である必要があります。

      ソースインスタンスの読み書きステータス

      ソース RDS インスタンスは 実行中 状態であり、読み取りおよび書き込みが可能である必要があります。

      ソースインスタンスのアカウントモード

      ソース RDS インスタンスが高セキュリティモード (データベースプロキシモード) の場合、ワンクリックアップグレードを実行するには、特権アカウントを作成する (「データベースアカウントの作成」をご参照) か、高性能モードに切り替える (「高性能モードへの切り替え」をご参照) 必要があります。

      PolarDB サービスリンクロール

      アカウント用に PolarDB のサービスリンクロールを作成する必要があります。

      「PolarDB のサービスリンクロールが作成されているかどうかの確認」の手順に従うか、OpenAPI を使用して作成できます。

      移行タスクの依存関係チェック

      DTS サービスの権限

      DTS にクラウドリソースへのアクセス権限を付与する必要があります。

      手順については、「DTS にクラウドリソースへのアクセス権限を付与する」をご参照ください。

      ソースインスタンスが空かどうかのチェック

      ソース RDS インスタンスにはデータベースがありません。移行を開始する前に、インスタンスにデータベースを作成する必要があります。

      ソースインスタンスのテーブルエンジンチェック

      ワンクリックアップグレード機能は、InnoDB または X-Engine ストレージエンジンを使用するテーブルを持つソース RDS インスタンスでのみサポートされます。

      ソースインスタンスのトリガーチェック

      ソース RDS インスタンスにトリガーがある場合、移行が中断されるのを防ぐために、まずトリガーを削除する必要があります。

      説明

      ビジネス要件に基づいて、次のステートメントを実行してソース RDS インスタンスからトリガーを削除できます。

      -- トリガーを表示します。
SHOW TRIGGERS;
-- トリガーを削除するステートメントを選択して実行します。
DROP TRIGGER  trigger_name;

      移行が完了した後、移行先の PolarDB クラスターに手動でトリガーを作成できます。

      プライマリーキーのないソースインスタンスのテーブルのチェック

      ソース RDS インスタンスにプライマリーキーのないテーブルが含まれている場合、同期後に移行先データベースでデータが重複する可能性があります。

      特権アカウントを使用してソース 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");

      クエリによって返されたテーブルにプライマリーキーを追加できます。

      重複レコードが許容できると判断した場合は、このチェックを無視できます。ワンクリックアップグレードプロセス中にプロンプトが表示されたら、[アップグレードを続行] を選択してください。

      ソースインスタンスのキー情報チェック

      ソースインスタンスの root アカウントチェック

      RDS MySQL と PolarDB のアカウントシステムの互換性を確保し、移行後に移行先の PolarDB クラスターのシステムアカウントが上書きされるのを防ぐために、移行元の RDS インスタンスに root アカウントと aliyun_root アカウントの両方を含めることはできません。 詳細については、「移行元の RDS インスタンスから冗長なシステムアカウントを削除する」をご参照ください。

    • Q：ApsaraDB RDS for MySQL から PolarDB for MySQL へのワンクリックアップグレードと、「ApsaraDB RDS for MySQL インスタンスの PolarDB for MySQL へのクローン作成」の違いは何ですか。

      A：次の表に違いを示します：

      項目

      ApsaraDB 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：移行をキャンセルすると、次のような影響があります：

      • ソースクラスターと移行先クラスター間の同期リンクが切断され、2 つのクラスターは関連付けられなくなります。

      • 移行先クラスターは読み書き可能状態に復元され、自動的にはリリースされません。クラスターが不要になった場合は、追加料金を避けるために、できるだけ早くリリースしてください。

      • 手動で移行をキャンセルする場合、クラスターのバイナリログ (Binlog) を無効にするかどうかを選択できます。移行が自動的にキャンセルされた場合、Binlog は無効になりません。

        説明

        Binlog を無効にすると、書き込みパフォーマンスがわずかに向上します。Binlog を無効にしても、既存の Binlog ファイルは保持されます。最初に Binlog ファイルの保持期間を短縮し、不要なファイルが自動的に削除されるのを待ってから、Binlog を無効にすることができます。Binlog を無効にすると、クラスターは自動的に再起動します。再起動タスクは 5 分以内に完了し、再起動中にサービスが約 40 秒間一時的に切断されます。正確な時間は、データ量とテーブル数によって異なります。この操作はオフピーク時に実行し、アプリケーションに再接続メカニズムがあることを確認することを推奨します。

    • Q：アップグレードが完了し、ビジネスが PolarDB に切り替わった後、アプリケーション側で接続アドレスを変更する必要がありますか。

      A：移行の切り替え時に エンドポイントの切り替え (接続変更が不要な場合) を選択できます。システムは RDS と PolarDB の接続アドレスを自動的に交換します。アプリケーション側で設定を変更しなくても、自動的に PolarDB に接続できます。

    • Q：移行とアップグレード中に、移行先クラスターの特権アカウントに一部の権限がない場合、アカウントの権限を変更できますか。

      A：移行とアップグレード中は、アカウントの権限を変更できません。移行先クラスターの特権アカウントの権限は、ソースインスタンスから同期されます。移行とアップグレード後に一部のデフォルト権限が欠落している場合は、コンソールの [アカウント管理] ページで特権アカウントの権限をリセットできます。

    • Q：移行中に エンドポイントの切り替え (接続変更が不要な場合) を選択しました。移行完了後、PolarDB クラスターが新しい接続アドレスを使用しているのはなぜですか。

      A：ソース RDS インスタンスと移行先 PolarDB クラスターの両方に存在する接続アドレスのみが相互に切り替え可能です。デフォルトでは、プライベートネットワーク上のプライマリエンドポイントのみがエンドポイントとの切り替えをサポートしています。他の接続アドレスを切り替えるには、切り替え前に対応する接続アドレスを作成する必要があります。そうしないと、切り替えられません。PolarDB クラスターと RDS インスタンスの接続アドレスの作成方法については、「エンドポイントの管理」および「RDS インスタンスのエンドポイントの設定」をご参照ください。

    • Q：ソース RDS インスタンスには読み取り専用インスタンスも含まれています。エンドポイントの切り替え (接続変更が不要な場合) を選択した場合、読み取り専用インスタンスの接続アドレスも切り替えられますか。

      A：[エンドポイントで切り替え (接続の変更は不要)] を選択したときに、PolarDB に対応するクラスターエンドポイントまたはカスタムエンドポイントがある場合、そのエンドポイントをソース RDS インスタンスの読み取り専用インスタンスの接続アドレスと切り替えることができます。

    • Q：ビジネスの切り替えが成功した後、PolarDB データベースに接続できない、または接続は成功したものの、読み取り操作のみ可能で書き込み操作が実行できないのはなぜですか。

      A：ドメイン名の切り替え後、DNS 解決キャッシュの問題が存在する可能性があります。キャッシュが期限切れになる前に、データベースへの接続に失敗したり、データベースが読み取り専用になり、書き込み操作を実行できなくなったりすることがあります。サーバーの DNS キャッシュを更新することを推奨します。

    • Q：PolarDB へのワンクリックアップグレードの前に、まず互換性テストを実行し、移行のワークロードを簡単に評価できますか。

      A：まず「ApsaraDB RDS for MySQL インスタンスの PolarDB for MySQL へのクローン作成」機能を使用して、データを PolarDB にクローンし、互換性テストと移行ワークロードの評価を行うことができます。テストで問題がないことを確認した後、このトピックに従って PolarDB へのワンクリックアップグレードを実行します。

    • Q：PolarDB コンソールで、移行の切り替え後に 完全な移行 ボタンが表示されないのはなぜですか。

      A：すでに 完全な移行 操作を実行した場合、同じ操作を繰り返さないようにボタンは表示されなくなります。

    • Q：PolarDB へのワンクリックアップグレード後、移行先の PolarDB クラスターにソース RDS インスタンスと同じアカウントとパスワードを作成する必要がありますか。

      A：いいえ。アップグレード後、PolarDB クラスターには、ソース RDS インスタンスのアカウント、パスワード、データベース、IP アドレスホワイトリスト、および必要なパラメーターが含まれます。

    • Q：ソース RDS インスタンスで SSL が有効になっています。これを PolarDB クラスターに移行するにはどうすればよいですか。

      A：SSL が有効になっている RDS インスタンスは、PolarDB クラスターへのワンクリックアップグレードをサポートしています。物理移行または論理移行を使用してインスタンスを移行できます。

      説明

      RDS インスタンスの接続アドレスで 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 クラスターに同期されます。ソース RDS インスタンス上の DTS 同期タスクのデータソースは、ソース RDS インスタンスのままです。PolarDB へのデータ移行は、ソース RDS インスタンスの実行や操作には影響しません。

      移行の切り替え後、ソース RDS インスタンスは読み取り専用になります。DTS 同期タスクの移行先として機能する場合、書き込み操作は失敗します。DTS 同期タスクの移行先を新しい PolarDB クラスターに変更する必要があります。DTS 同期タスクのソースとして機能する場合も、移行の切り替え後できるだけ早く DTS 同期タスクのソースを新しい PolarDB クラスターに変更することを推奨します。

      現在、DTS タスクのソースまたは移行先データベースインスタンスは、OpenAPI を使用してのみ変更できます。詳細については、「ModifyDtsJobEndpoint」をご参照ください。

    • Q：RDS インスタンスを登録解除またはリリースするか、そのゾーンを変更すると、"The specified operation is disabled while the instance is undergoing an engine migration." というメッセージが表示されます。どうすればよいですか。

      A：現在の RDS インスタンスは、「ソリューション概要」で説明されているプロセスを実行中の可能性があります。PolarDB コンソールに移動して、PolarDB クラスターが移行中かどうかを確認します。RDS インスタンスを登録解除またはリリースする前に、PolarDB クラスターですべてのアップグレード操作 (移行の切り替えを含む)を完了する必要があります。

    • Q：RDS MySQL から PolarDB for MySQL に 3 TB のデータを移行するにはどのくらい時間がかかりますか。

      A：移行時間はデータ量に直接関係するため、固定の見積もりは提供できません。実際の時間は、次の要因によって異なります：

      • インスタンス仕様：DTS インスタンスクラス (小、中、または大) は、転送パフォーマンスに直接影響します。

      • ネットワーク帯域幅：クラウドインスタンス間の内部ネットワークを介した転送が最も高速です。パブリック IP アドレス、Express Connect、VPN Gateway、ECS 上のセルフマネージドデータベース、Cloud Enterprise Network (CEN)、または Database Gateway (DG) を介して接続する場合、帯域幅は異なります。接続方法 (暗号化なしまたは SSL) も実効帯域幅に影響します。

      • データベースの負荷：ソースデータベースの読み書きの負荷は、バイナリログの読み取り速度に影響します。

      増分移行を実行するには、ソース RDS インスタンスでバイナリログを有効にし、バイナリログを少なくとも 24 時間保持する必要があります。3 日以上の保持期間を推奨します。

      最初に小さなテストデータベース (たとえば 100 GB) を移行し、完全なデータ同期にかかる時間を記録してから、インスタンス全体の移行時間を比例的に推定することを推奨します。