All Products
Search

This Product

    PolarDB:FAQ

    Document Center

    PolarDB:FAQ

    Last Updated:Apr 28, 2024

    This topic provides answers to some frequently asked questions about upgrading an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

    • How do I handle failed check items in a migration evaluation task?

      Category

      Check item

      Solution

      Basic Information Verification

      Source Instance Running Status

      The source ApsaraDB RDS instance must be in the Running state.

      Source Instance Read/Write Status

      The source ApsaraDB RDS instance must be in the Running state and in Read/Write mode.

      Source Instance Account Mode

      If Database Proxy (Safe Mode) is enabled for the ApsaraDB RDS for MySQL instance, a privileged account is created or the network connection mode of the ApsaraDB RDS for MySQL instance is switched to high-performance mode. For more information, see Create an account and [Product changes/Feature changes] The network connection mode of an ApsaraDB RDS instance is upgraded.

      Service-linked Role for PolarDB

      The service-linked role for PolarDB is created for the account.

      For more information about how to create a PolarDB service-linked role, see Precheck whether the service-linked role for PolarDB is created. You can also create a PolarDB service-linked role by calling the API operation.

      Migration Task Dependency Verification

      DTS Permissions

      Your Alibaba Cloud account must have the permissions to access cloud resources over DTS.

      For more information, see Authorize DTS to access Alibaba Cloud resources.

      Whether Source Instance is Empty

      Databases are created in the source ApsaraDB RDS instance. You must create a database in the instance before you can migrate data.

      Source Instance Table Engine Verification

      The table storage engine for the source RDS instance must be InnoDB or X-Engine.

      Source Instance Trigger Verification

      If triggers are created for the source ApsaraDB RDS instance, delete the triggers first. Otherwise, the migration process will be interrupted.

      You can manually create triggers in the destination PolarDB cluster after the migration process is complete.

      Verification for Non-primary-key Tables in Source Instance

      If the source ApsaraDB RDS instance contains tables without primary keys, duplicate data may occur in the destination PolarDB cluster after data is synchronized.

      You can connect to the database on the source ApsaraDB RDS instance by using a privileged account and execute the following SQL statement to query 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 without primary keys.

      If you confirm that duplicate data is acceptable, you can ignore this evaluation result and select Continue when the error message is returned when you Upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

      Key Information Verification

      Source Instance Root Account Verification

      To ensure compatibility between ApsaraDB RDS for MySQL and PolarDB in terms of the system account structure and to prevent the system accounts of the destination PolarDB cluster from being overwritten during migration, make sure that the root and aliyun_root accounts do not exist in the source ApsaraDB for RDS instance at the same time. For more information, see Remove redundant system accounts from the source ApsaraDB for RDS instance.

    • What are the differences between upgrading an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster and cloning an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster (Clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster)?

      The following table describes the differences.

      Item

      Upgrade an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster

      Clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster

      Whether incremental data migration or synchronization is supported

      Yes

      No

      Whether operations on the source ApsaraDB RDS for MySQL instance are affected

      No

      No

      Whether the source and destination databases can use different MySQL versions

      Yes

      Yes

    • Do the node specifications of the destination PolarDB for MySQL cluster need to be the same as the node specifications of the source ApsaraDB RDS for MySQL instance?

      You can select the node specifications of the destination PolarDB for MySQL cluster based on your business requirements. We recommend that you select node specifications that are the same as or higher than the node specifications of the source ApsaraDB RDS for MySQL instance.

    • Do I need to purchase a PolarDB for MySQL cluster before I upgrade an ApsaraDB RDS for MySQL instance to a PolarDB cluster?

      You do not need to purchase a PolarDB for MySQL cluster in advance. You can purchase and create a PolarDB for MySQL cluster that has the same data as the source ApsaraDB RDS for MySQL instance when you perform the upgrade.

    • Is the source ApsaraDB RDS for MySQL instance affected when I migrate data from the instance?

      No, the source ApsaraDB RDS for MySQL instance is not affected when you migrate data from the RDS instance.

    • What are the impacts of a smooth migration on the source ApsaraDB RDS for MySQL instance?

      A smooth migration does not affect the operations on the source ApsaraDB RDS for MySQL instance. However, data migration involves read operations, and read operations affect query performance on the source ApsaraDB RDS for MySQL instance.

    • What are the impacts of a smooth migration on my workloads that run on the databases?

      A smooth migration ensures that no data is lost when you perform the migration. The service downtime is no more than 10 minutes. During service downtime, the service is suspended and does not generate incremental data, but the database is not stopped. You can roll back the migration based on your business requirements.

    • What happens when I cancel the migration?

      After you cancel the migration, the following impacts occur:

      • The synchronization link from the source instance to the destination cluster is disconnected. The source instance is no longer associated with the destination cluster.

      • The destination cluster becomes readable and writable and is not automatically released. If you no longer use the destination cluster, release the cluster at the earliest opportunity to prevent additional costs.

      • You can specify whether to disable the binary logging feature for the cluster when you manually cancel the migration. The binary logging feature is not disabled when the migration is automatically canceled.

        Note

        If you disable the binary logging feature for the cluster, the write performance of the cluster is slightly improved. After you disable the binary logging feature, existing binary logs are retained. To delete the binary logs, you can first reduce the retention period for the binary logs. After the binary logs have been automatically deleted, you can then disable the binary logging feature. After you disable the binary logging feature, the cluster automatically restarts. The restart task is completed within 5 minutes. The service is interrupted for approximately 40 seconds during the restart. The restart duration varies based on the amount of data and the number of tables. We recommend that you disable the binary logging feature during off-peak hours and make sure that your application can automatically reconnect to the database service.

    • Do I need to change the endpoint in my applications after the service is switched over to the PolarDB cluster?

      If you select Switch with Endpoints (Connection Changes Not Required), the system automatically exchanges the endpoints between the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster. In this case, you do not need to modify the configurations of your applications to connect to the PolarDB cluster.

    • I selected Switch with Endpoints (Connection Changes Not Required) when I switched over services. Why do I need to use the new endpoint to connect to the PolarDB cluster?

      Endpoints can be exchanged only if the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster have the endpoints. By default, only the primary endpoint in the internal network is exchanged. If you want to use a different endpoint, you must create the endpoint before the switchover. For information about how to create endpoints for a PolarDB cluster, see Manage the endpoints of a cluster. For information about how to create endpoints for an ApsaraDB RDS for MySQL instance, see Configure endpoints for an RDS instance.

    • The source ApsaraDB RDS for MySQL instance contains read-only instances. Can I exchange the endpoints of read-only instances between the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster when I select Switch with Endpoints (Connection Changes Not Required)?

      If cluster endpoints and custom endpoints exist in the destination PolarDB cluster, you can exchange the endpoints of read-only instances between the source ApsaraDB RDS for MySQL instance and the destination PolarDB cluster when you select Switch with Endpoints (Connection Changes Not Required).

    • Why do connections to PolarDB databases or data write operations fail after the switchover?

      After the endpoints are exchanged, issues may occur due to the expiration of the Domain Name System (DNS) cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. We recommend that you refresh the DNS cache to resolve the issue.

    • Can I perform a compatibility test and evaluate the workloads before I upgrade an ApsaraDB RDS for MySQL instance to a PolarDB cluster?

      You can perform the operations described in Clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster to clone data from an ApsaraDB RDS for MySQL instance to a PolarDB cluster for compatibility tests and workload evaluation. Then, perform the operations in this topic to upgrade the ApsaraDB RDS for MySQL instance to the PolarDB cluster.

    • Why is the Complete Migration button not displayed in the PolarDB console after I switch over services?

      If you complete the Complete Migration step, the Complete Migration button is hidden to avoid repeated operations.

    • Do I need to replicate the same username and password from the source ApsaraDB RDS for MySQL instance in the destination PolarDB cluster after the upgrade to the PolarDB cluster?

      No. The destination PolarDB cluster contains the accounts, passwords, databases, IP address whitelists, and required parameters of the source ApsaraDB RDS for MySQL instance.

    • How do I migrate data from a source ApsaraDB RDS for MySQL instance that has SSL enabled to a PolarDB cluster?

      You can physically or logically migrate data from a source ApsaraDB RDS for MySQL instance that has SSL enabled to a PolarDB cluster.

      Note

      If SSL is enabled for the endpoints of the ApsaraDB RDS for MySQL instance and you select Switch with Endpoints to switch the endpoints, make sure that SSL is enabled for the endpoints of the PolarDB cluster.

    • How do I migrate data from a source ApsaraDB RDS for MySQL instance for which transparent data encryption (TDE) is enabled to a PolarDB cluster?

      You can physically or logically migrate data from a source ApsaraDB RDS for MySQL instance for which TDE is enabled to a PolarDB cluster.

    • Can I perform a cross-version upgrade? For example, can I upgrade an ApsaraDB RDS for MySQL 5.6 instance to a PolarDB for MySQL 8.0 cluster?

      If you use the logical migration method, the PolarDB cluster can run a different MySQL version.

    • If a Data Transmission Service (DTS) data synchronization task is started for the source ApsaraDB RDS for MySQL instance before I upgrade the instance to a PolarDB for MySQL cluster, is the task affected when I perform the upgrade?

      No. When you perform the operations described in this topic, full data is first cloned from the source ApsaraDB RDS for MySQL instance to the new PolarDB cluster. Then, incremental data is synchronized from the source ApsaraDB RDS for MySQL instance to the PolarDB cluster in real time. The source ApsaraDB RDS for MySQL instance remains the data source or destination of the DTS task. The upgrade to the PolarDB cluster does not affect the operations on the source ApsaraDB RDS for MySQL instance.

      After the upgrade, the source ApsaraDB RDS for MySQL instance becomes read-only. If the source ApsaraDB RDS for MySQL instance is used as the data destination of the DTS data synchronization task, you cannot write data to the instance. You must change the destination database of the DTS data synchronization task to the new PolarDB cluster. If the source ApsaraDB RDS for MySQL instance is used as the data source of the DTS data synchronization task, we recommend that you change the data source of the DTS data synchronization task to the new PolarDB cluster at the earliest opportunity after the data migration.

      You can change the source or destination database instance of a DTS task only by calling the ModifyDtsJobEndpoint operation. For information about the API operation, see ModifyDtsJobEndpoint.