PolarDB:FAQ

What should I do if a check item in the migration evaluation fails?

The following table lists each check item and the required action.

-- List all triggers
SHOW TRIGGERS;
-- Delete a specific trigger
DROP TRIGGER trigger_name;

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

Do I need to purchase a PolarDB cluster before upgrading?

No. The upgrade process automatically creates a PolarDB for MySQL cluster with the same data as the source RDS instance.

Must the PolarDB cluster nodes match the source RDS instance type?

Not necessarily. Select the node specifications that fit your workload. Use specifications no lower than the source RDS instance type as a baseline.

Does the migration affect the source RDS instance?

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

Does smooth migration consume resources from the source RDS instance?

Smooth migration does not affect the availability of the source RDS instance. However, data migration involves query operations that consume some of the source RDS instance's query capacity.

How much downtime does a smooth migration cause?

A smooth migration ensures that no data is lost. Downtime is under 10 minutes. During the downtime window, your application is paused to prevent new writes, but the database itself is not stopped. If needed, you can roll back the migration.

What happens if I cancel the migration?

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

• The destination cluster becomes read-write and is not automatically released. Release it immediately if you no longer need it to avoid unnecessary charges.

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

About disabling binary logging:

Disabling binary logging slightly improves write performance. Existing binary log files are retained after you disable binary logging. Before disabling, shorten the retention period of binary log files and wait for the files to be automatically deleted. After you disable binary logging, the cluster automatically restarts. The restart completes within 5 minutes, during which a transient disconnection of about 40 seconds occurs (the exact duration depends on data volume and number of tables). Perform this operation during off-peak hours and make sure your application has a reconnection mechanism.

Do I need to update connection strings in my application after switching to PolarDB?

Not if you select Switch with Endpoints (Connection Changes Not Required) during the switchover. The system automatically exchanges the RDS and PolarDB endpoints, so your application connects to PolarDB without any configuration changes.

I selected "Switch with Endpoints (Connection Changes Not Required)" but the PolarDB cluster is still using a new endpoint. Why?

Endpoints are exchanged only when a matching endpoint exists on both the source RDS instance and the destination PolarDB cluster. By default, only the primary endpoint on the private network is switched.

To switch other endpoints, create the corresponding endpoints on the destination cluster before the switchover. See Manage connection addresses and Set connection addresses.

Can the endpoints of read-only RDS instances also be switched?

Yes. When you select Switch with Endpoints (Connection Changes Not Required), the endpoint of a read-only RDS instance is switched if the destination PolarDB cluster has a corresponding cluster endpoint or custom endpoint.

After the switchover, why can't I connect to the PolarDB database, or why is the connection read-only?

This is likely caused by the local DNS cache on your server. During the time-to-live (TTL) of the cache, your application may fail to connect or may establish a read-only connection. Refresh the DNS cache on your server to resolve this.

After the upgrade, do I need to recreate accounts and passwords from the source RDS instance?

No. After the upgrade, the PolarDB cluster automatically inherits accounts, passwords, databases, IP whitelists, and required parameters from the source RDS instance.

Can I modify account permissions during the migration and upgrade?

No. Account permissions cannot be modified during an active migration. Permissions of the privileged account on the destination cluster are synchronized from the source instance. If the privileged account is missing default permissions after the upgrade, reset them on the Account Management page in the console.

The source RDS instance has SSL enabled. Can I still use the one-click upgrade?

Yes. Both Physical Migration and Logical Migration support Secure Sockets Layer (SSL)-enabled RDS instances.

The source RDS instance has TDE (Transparent Data Encryption) enabled. Can I still use the one-click upgrade?

Yes. Both Physical Migration and Logical Migration support Transparent Data Encryption (TDE)-enabled RDS instances.

Does the one-click upgrade support cross-version upgrades?

Yes. Logical Migration (DTS data synchronization) supports cross-version upgrades, such as upgrading from RDS MySQL 5.6 to PolarDB for MySQL 8.0.

I already have a DTS synchronization task running on the source RDS instance. Will the one-click upgrade affect it?

No. During the one-click upgrade, a full data copy is first replicated to the new PolarDB cluster, and then incremental data is continuously synchronized. The existing DTS task continues using the source RDS instance as its data source and is not affected.

After the migration switchover, the source RDS instance becomes read-only. At that point:

• If the RDS instance is the destination of a DTS task, write operations will fail. Change the DTS task destination to the new PolarDB cluster.

• If the RDS instance is the source of a DTS task, change the DTS task source to the new PolarDB cluster as soon as possible.

DTS task source or destination can only be modified using OpenAPI. See Modify the source or destination instance of a DTS task.

The Complete Migration button is no longer visible in the PolarDB console. What happened?

The button is hidden after you click it once to prevent accidental duplicate operations.

When I try to release or change the zone of the RDS instance, I get the error "The specified operation is disabled while the instance is undergoing an engine migration." What should I do?

This error means the RDS instance is currently being upgraded using the one-click upgrade from RDS for MySQL to PolarDB for MySQL feature. Go to the PolarDB console and check whether a cluster is undergoing migration. Complete all upgrade operations, including the migration switchover, before releasing or changing the zone of the RDS instance.

What is the difference between upgrading and cloning an RDS for MySQL instance to PolarDB?

Can I run a compatibility test before the one-click upgrade?

Yes. Clone your data to a PolarDB cluster to run compatibility tests and workload evaluations. See Clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster. After confirming there are no issues, proceed with the one-click upgrade.