All Products
Search

This Product

    PolarDB:FAQ

    Document Center

    PolarDB:FAQ

    Last Updated:Sep 22, 2026

    This topic lists some frequently asked questions about the one-click upgrade from ApsaraDB RDS for MySQL to PolarDB for MySQL.

    • Q: What do I do if a check item in the Migration evaluation fails?

      Category

      Check item

      Solution

      Notice

      Event check

      The source RDS instance has events, but DTS does not support event synchronization. You must manually synchronize the events to the destination PolarDB cluster.

      Source instance basic information check

      Source instance running status

      The source RDS instance must be in the Running state.

      Source instance read/write status

      The source RDS instance must be in the Running state and be readable and writable.

      Source instance account mode

      If the source RDS instance is in high-security mode (database proxy mode), you must create a privileged account (see (Deprecated and redirected to Step 1) Create a database account) or switch to high-performance mode (see Switch to high-performance mode) to perform a one-click upgrade.

      PolarDB service-linked role

      You must create a service-linked role for PolarDB for your account.

      You can follow the instructions in Check whether a service-linked role for PolarDB is created or create one by using OpenAPI.

      Migration task dependency check

      DTS service permissions

      You must grant DTS permissions to access cloud resources.

      For instructions, see Grant DTS the permissions to access cloud resources.

      Check whether the source instance is empty

      The source RDS instance has no databases. You must create a database in the instance before you can start the migration.

      Source instance table engine check

      Only source RDS instances with tables that use the InnoDB or X-Engine storage engine support the one-click upgrade feature.

      Source instance trigger check

      If the source RDS instance has triggers, you must delete them first to prevent the migration from being interrupted.

      Note

      You can run the following statements to delete triggers from the source RDS instance based on your business requirements.

      -- View the triggers.
SHOW TRIGGERS;
-- Select and run the statement to delete a trigger.
DROP TRIGGER  trigger_name;

      After the migration is complete, you can manually create the triggers in the destination PolarDB cluster.

      Source instance tables without primary keys check

      If the source RDS instance contains tables without primary keys, duplicate data may occur in the destination database after synchronization.

      Connect to the database on the source RDS instance by using a privileged account and run the following SQL statement to find tables without primary keys:

      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");

      You can add primary keys to the tables returned by the query.

      If you determine that duplicate records are acceptable, you can ignore this check. When prompted during the one-click upgrade process, select Continue Upgrade.

      Source instance key information check

      Source instance root account check

      To ensure compatibility between the account systems of RDS MySQL and PolarDB and prevent system accounts of the destination PolarDB cluster from being overwritten after migration, the source RDS instance cannot have both the root and aliyun_root accounts. For more information, see Delete redundant system accounts from the source RDS instance.

    • Q: What is the difference between the one-click upgrade from ApsaraDB RDS for MySQL to PolarDB for MySQL and Clone an ApsaraDB RDS for MySQL instance to PolarDB for MySQL?

      A: The following table describes the differences:

      Item

      One-click upgrade from ApsaraDB RDS for MySQL to PolarDB for MySQL

      Clone an ApsaraDB RDS for MySQL instance to PolarDB for MySQL

      Whether incremental data migration or synchronization is supported

      Supported

      Not supported

      Whether operations on the source RDS instance are affected

      Not affected

      Not affected

      Whether the MySQL versions of the source and destination can be different

      Can be different

      Can be different

    • Q: Must the node specifications of the upgraded PolarDB for MySQL cluster be the same as the instance type of the source RDS for MySQL instance?

      A: Not necessarily. You can select the specifications of the PolarDB for MySQL cluster as needed. We recommend that the specifications be no lower than those of the source RDS instance.

    • Q: Do I need to purchase a PolarDB for MySQL cluster before the upgrade?

      A: No. You do not need to purchase a PolarDB for MySQL cluster in advance. During the upgrade, a PolarDB cluster with the same data as the source RDS instance is purchased and created.

    • Q: Does migrating data from RDS affect the source RDS instance?

      A: No. The normal operation of the source RDS instance is not affected.

    • Q: Does smooth migration affect the performance of the source RDS instance?

      A: Migration does not affect operations on the source RDS instance. However, data migration involves query operations, which consume some of the query performance of the source RDS instance.

    • Q: Does smooth migration affect my business?

      A: Smooth migration ensures that no data is lost during the migration. The downtime (during which your business is paused and no incremental data is generated, rather than the database being stopped) is less than 10 minutes. You can also roll back the migration if needed.

    • Q: What are the impacts of canceling the migration?

      A: Canceling the migration has the following impacts:

      • The synchronization link between the source cluster and the destination cluster is disconnected, and the two clusters are no longer associated.

      • The destination cluster is restored to the read/write state and is not automatically released. If you no longer need the cluster, release it as soon as possible to avoid additional fees.

      • When you manually cancel the migration, you can choose whether to disable binary logging (Binlog) for the cluster. When the migration is canceled automatically, Binlog is not disabled.

        Note

        Disabling Binlog slightly improves write performance. After Binlog is disabled, the existing Binlog files are retained. You can first shorten the retention period of the Binlog files, wait for the unnecessary files to be automatically deleted, and then disable Binlog. After Binlog is disabled, the cluster automatically restarts. The restart task is completed within 5 minutes, and the service is transiently disconnected for about 40 seconds during the restart. The exact duration depends on the data volume and the number of tables. We recommend that you perform this operation during off-peak hours and ensure that your application has a reconnection mechanism.

    • Q: After the upgrade is complete and my business is switched to PolarDB, do I need to modify the connection address on the application side?

      A: You can select Switch with Endpoints (Connection Changes Not Required) during the migration switchover. The system automatically exchanges the connection addresses on RDS and PolarDB. You do not need to modify any configuration on the application side to automatically connect to PolarDB.

    • Q: During the migration and upgrade, if the privileged account of the destination cluster lacks some permissions, can I modify the account permissions?

      A: Account permissions cannot be modified during the migration and upgrade. The permissions of the privileged account of the destination cluster are synchronized from the source instance. If some default permissions are missing after the migration and upgrade, you can reset the permissions of the privileged account on the Account Management page in the console.

    • Q: I selected Switch with Endpoints (Connection Changes Not Required) during the migration. After the migration is complete, why does the PolarDB cluster still use a new connection address?

      A: Only connection addresses that exist on both the source RDS instance and the destination PolarDB cluster can be switched with each other. By default, only the primary endpoint on the private network supports switching with endpoints. To switch other connection addresses, you must create the corresponding connection addresses before the switchover. Otherwise, they are not switched. For information about how to create connection addresses for a PolarDB cluster and an RDS instance, see Manage endpoints and Configure endpoints for an RDS instance.

    • Q: The source RDS instance also includes read-only instances. If I select Switch with Endpoints (Connection Changes Not Required), can the connection addresses of the read-only instances also be switched?

      A: When you select Switch with Endpoints (Connection Changes Not Required), if PolarDB has a corresponding cluster endpoint or custom endpoint, the endpoint can be switched with the connection address of the read-only instance in the source RDS instance.

    • Q: After my business is successfully switched, why can I not connect to the PolarDB database, or why is the connection successful but only read operations are supported and write operations cannot be performed?

      A: After the domain name is switched, a DNS resolution cache issue may exist. Before the cache expires, you may fail to connect to the database, or the database may support only read operations and cannot perform write operations. We recommend that you refresh the DNS cache on your server.

    • Q: Before the one-click upgrade to PolarDB, can I first perform a compatibility test and briefly evaluate the migration workload?

      A: You can first use the Clone an ApsaraDB RDS for MySQL instance to PolarDB for MySQL feature to clone data to PolarDB for compatibility testing and migration workload evaluation. After the test confirms that there are no issues, follow this topic to perform the one-click upgrade to PolarDB.

    • Q: In the PolarDB console, why is the Complete Migration button not visible after the migration switchover?

      A: If you have already performed the Complete Migration operation, the button disappears to prevent you from repeating the same operation.

    • Q: After the one-click upgrade to PolarDB, do I still need to create the same accounts and passwords as the source RDS instance in the destination PolarDB cluster?

      A: No. After the upgrade, the PolarDB cluster contains the accounts, passwords, databases, IP address whitelists, and necessary parameters of the source RDS instance.

    • Q: SSL is enabled on the source RDS instance. How do I migrate it to a PolarDB cluster?

      A: An RDS instance with SSL enabled supports the one-click upgrade to a PolarDB cluster. You can migrate the instance by using physical migration or logical migration.

      Note

      If SSL is enabled on the connection address of the RDS instance, and you select Switchover with Endpoints and switch the address, make sure that SSL is also enabled on the corresponding connection address of the PolarDB cluster.

    • Q: TDE is enabled on the source RDS instance. How do I migrate it to a PolarDB cluster?

      A: An RDS instance with TDE enabled supports the one-click upgrade to a PolarDB cluster. You can migrate the instance by using physical migration or logical migration.

    • Q: Does the one-click upgrade support cross-version upgrades? For example, can I upgrade RDS MySQL 5.6 to PolarDB for MySQL 8.0?

      A: The logical migration (DTS data synchronization) method of the one-click upgrade supports cross-version upgrades.

    • Q: If a DTS data synchronization task is already running on the source RDS instance before the one-click upgrade to PolarDB for MySQL, does the upgrade affect the task?

      A: No. When you migrate data by using the one-click upgrade, a full copy of data is first replicated from RDS to a new PolarDB cluster, and then incremental data is continuously synchronized to the PolarDB cluster. The data source of the DTS synchronization task on the source RDS instance remains the source RDS instance. Migrating data to PolarDB does not affect the running or operations of the source RDS instance.

      After the migration switchover, the source RDS instance becomes read-only. If it serves as the destination of a DTS synchronization task, write operations fail. You must change the destination of the DTS synchronization task to the new PolarDB cluster. If it serves as the source of a DTS synchronization task, we also recommend that you change the source of the DTS synchronization task to the new PolarDB cluster as soon as possible after the migration switchover.

      Currently, you can modify the source or destination database instance of a DTS task only by using OpenAPI. For more information, see ModifyDtsJobEndpoint.

    • Q: When I unsubscribe from (release) an RDS instance or change its zone, the message "The specified operation is disabled while the instance is undergoing an engine migration." appears. What do I do?

      A: The current RDS instance may be undergoing the process described in Solution overview. Go to the PolarDB console to check whether a PolarDB cluster is being migrated. You must, in the PolarDB cluster, complete all upgrade operations (including the migration switchover) before you can unsubscribe from (release) the RDS instance or change its zone.

    • Q: How long does it take to migrate 3 TB of data from RDS MySQL to PolarDB for MySQL?

      A: The migration duration is directly related to the data volume, so no fixed estimate can be provided. The actual duration depends on the following factors:

      • Instance specifications: The DTS instance class (small, medium, or large) directly affects transfer performance.

      • Network bandwidth: Transfers over the internal network between cloud instances are the fastest. Bandwidth varies when you connect over a public IP address, Express Connect, VPN Gateway, a self-managed database on ECS, Cloud Enterprise Network (CEN), or Database Gateway (DG). The connection method (unencrypted or SSL) also affects the effective bandwidth.

      • Database load: Read and write pressure on the source database affects the speed at which binary logs are read.

      To perform incremental migration, binary logging must be enabled on the source RDS instance and the binary logs must be retained for at least 24 hours. We recommend a retention period of three days or longer.

      We recommend that you first migrate a small test database (for example, 100 GB), record how long the full data synchronization takes, and then extrapolate the migration duration for the entire instance proportionally.