All Products
Search

This Product

    PolarDB:FAQ

    Document Center

    PolarDB:FAQ

    Last Updated:Apr 11, 2024

    This topic provides answers to some frequently asked questions about upgrades of PolarDB for MySQL clusters.

    • What do I do if the check items in the Upgrade evaluation fail?

      Category

      Check item

      Solution

      Basic Information Verification

      Source Instance Running Status

      The source PolarDB cluster must be in the Running state.

      Source Instance Read/Write Status

      The source PolarDB cluster must be in the Running state and in Read/Write mode.

      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 Pre-check 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.

      Source Instance Binary Log Verification

      Before you perform the major version upgrade, you must enable binary logging for the source PolarDB cluster. For more information, see Enable binary logging.

      Whether Source Instance is Empty

      Databases are created in the source PolarDB cluster. You must create a database in the cluster before you perform the major version upgrade.

      Source Instance Trigger Verification

      If triggers are created for the source PolarDB cluster, delete the triggers first. Otherwise, the upgrade process will be interrupted.

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

      Verification for Non-primary-key Tables in Source Instance

      If the source PolarDB cluster 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 PolarDB cluster 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 perform the major version upgrade.

      Key Information Verification

      Source Instance Root Account Verification

      To prevent the system accounts of the destination PolarDB cluster from being overwritten during upgrade, make sure that the root and aliyun_root accounts do not exist in the source PolarDB cluster at the same time. Therefore, you must delete the redundant system accounts in the source cluster before you perform the upgrade. For more information, see Remove redundant system accounts from the source PolarDB for MySQL cluster.

    • Must the source and destination PolarDB for MySQL clusters use the same specifications?

      No. You can select the specifications of the destination PolarDB for MySQL cluster based on your needs. We recommend that you set specify a value that is greater than or equal to the specifications of the source cluster.

    • Do I need to purchase a cluster before the upgrade?

      No. During the upgrade, a cluster with the same data as the source PolarDB for MySQL cluster is created and purchased.

    • Does the upgrade affect the normal running of the source cluster?

      No.

    • Does data synchronization affect the performance of the source cluster?

      Data queries are involved in data synchronization, which results in a decrease in the query performance of the source cluster.

    • Does data synchronization affect my business?

      No data is lost during the synchronization. The business downtime is less than 10 minutes. During the downtime, the business is suspended and does not generate incremental data but the database is not stopped. You can roll back the migration if necessary.

    • What happens if I cancel the upgrade?

      If you cancel the upgrade, the following situations occur:

      • The synchronization link from the source cluster to the destination cluster is disconnected. The source cluster 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 cluster, release it at the earliest opportunity to prevent additional costs.

      • If you manually cancel the upgrade, you can specify whether to disable the binary logging feature for the cluster. The binary logging feature is not disabled if the migration is automatically canceled.

        Note

        If the binary logging feature is disabled for the cluster, the write performance of the cluster is slightly improved. After the binary logging feature is disabled, existing binary logs are retained. To delete the binary logs, you can enable the feature and specify a short retention period. After the retention period is reached, binary logs are automatically deleted. Then, you can disable the binary logging feature. After the binary logging feature is disabled, the cluster is automatically restarted. The restart task is completed within 5 minutes. The service interruption lasts approximately 40 seconds during the restart. The length of recovery time varies based on the data volume and the number of tables. We recommend that you perform this operation during off-peak hours and make sure that your application is configured to automatically reconnect to the database service.

    • Do I need to change the endpoint in my application after the business is switched over to the destination cluster?

      You can select Switch with Endpoints for the upgrade. The system automatically switches the endpoints of the source and destination clusters. You can connect to the destination cluster without the need to modify any configurations in the application.

    • I have selected Switch with Endpoints for the upgrade. Why does the destination cluster still use the new endpoint after the upgrade is complete?

      Only when the source and destination clusters both have endpoints, their endpoints can be switched. By default, only the primary endpoints of the internal network can be switched. To switch other types of endpoints, you must create the endpoints in advance. For more information about how to create endpoints for a cluster, see Apply for a cluster endpoint or a primary endpoint.

    • Why is the PolarDB cluster unable to be connected after the business is switched over or data cannot be written to the cluster after it is connected?

      After the endpoints are switched, issues may occur due to the expiration of the DNS cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. To resolve the issue, we recommend that you refresh the DNS cache.

    • Why is Complete Upgrade not displayed in the PolarDB console after the upgrade is complete and the business is switched over?

      If you have pressed Complete Upgrade, this button is hidden to prevent repeated operations.

    • Do I need to create the same accounts and passwords in the destination cluster as those in the source cluster after the upgrade?

      No. After the upgrade, the destination cluster retains the account settings, databases, IP whitelists, and required parameters of the source cluster.

    • If SSL is enabled for the source cluster, can I upgrade it?

      Yes, you can upgrade the source cluster with SSL enabled.

      Note

      If SSL is enabled for the source cluster, ensure that SSL is also enabled on the endpoint of the destination cluster.

    • If transparent data encryption (TDE) is enabled for the source cluster, can I upgrade it?

      Yes, you can upgrade the source cluster with TDE enabled.

    • If SSL is enabled for the source cluster, can I upgrade it to a cluster of Multi-master Cluster (Database/Table) Edition?

      Yes. However, SSL cannot be enabled for the destination cluster of Multi-master Cluster (Database/Table) Edition.

    • If TDE is enabled for the source PolarDB for MySQL cluster, can I upgrade it to a cluster of Multi-master Cluster (Database/Table) Edition?

      Yes. However, TDE cannot be enabled for the destination cluster of Multi-master Cluster (Database/Table) Edition.

    • If a DTS data synchronization task is started for the source PolarDB for MySQL cluster before the major engine version upgrade, is the task affected during the upgrade?

      No. During the major engine version upgrade, the system replicates full data from the source cluster to a new PolarDB for MySQL cluster. Then, incremental data is synchronized from the source cluster to the new cluster. The data source of the DTS data synchronization task is the source cluster. The data migration to the new PolarDB for MySQL cluster does not affect the operations on the source cluster.

      After the migration is complete, if you switch the workloads to the new PolarDB cluster and stop using the source cluster, the data source of the DTS data synchronization task is not automatically changed to the new PolarDB cluster. You must manually change the synchronization object of the DTS synchronization task to the new PolarDB cluster. For more information, see Modify the objects to be synchronized.