Single-Node (Formerly Basic Edition) Migration Guide
ダウンロード
フォーカスモード
フォントサイズ
This document describes the instructions and operation guide for migrating TencentDB for MySQL from the single-node (formerly Basic Edition) architecture to the single-node (cloud disk) architecture through DTS. It aims to provide a standard path for migrating Basic Edition instances to the new single-node (cloud disk) architecture through DTS, helping businesses complete the architecture upgrade.
Background
To provide you with more stable and higher-quality cloud database services, TencentDB for MySQL has upgraded and optimized the single-node architecture. The single-node (formerly Basic Edition) architecture has been gradually taken offline and replaced by the new-generation single-node (cloud disk) architecture. With the architecture upgrade, some features of the old architecture have been gradually restricted and can no longer provide a complete product experience. To guide you to migrate to the new single-node architecture with a better experience as soon as possible, Tencent plans to disable the renewal feature for single-node (formerly Basic Edition) instances and will fully take them offline. Therefore, this document guides you to migrate your old-version single-node instances to the new version to obtain a complete product experience and instance features. For instructions on stopping renewal, migration, and taking instances offline, see Announcement.
New Single-Node Description
All single-node instances provided by default in the TencentDB for MySQL console, APIs, and various sales channels now use the new single-node architecture, namely the single-node (cloud disk) architecture. The new architecture is based on MySQL cloud disk edition, offering higher elasticity and flexibility, along with multiple kernel optimizations that deliver significant performance improvements.
Applicable Scenarios
You are still using TencentDB for MySQL single-node (formerly Basic Edition) instances, and the instances are still running on the old architecture.
We recommend using online migration to minimize business interruption and smoothly move existing data to instances with the new architecture.
Note:
If your business requires high availability, such as automatic failover and cross-AZ disaster recovery, we recommend that you choose a multi-node architecture, such as dual-node or three-node, when you migrate.
Migration Solution Overview
This migration uses DTS as the migration tool. The overall path is: create a new instance first, then migrate data, and finally switch traffic and retire the old instance.
[Old architecture] TencentDB for MySQL single-node (formerly Basic Edition)││ DTS migration task (full + incremental)│ Access type: VPC│ Connection address: private IP address of the instance▼[New architecture] TencentDB for MySQL single-node (cloud disk)││ After data verification is consistent▼Switch the business connection string, and then unsubscribe from the old architecture instance.
Precautions
High availability recommendations: If your business requires high availability, such as automatic failover and cross-AZ disaster recovery, we recommend that you choose a multi-node architecture, such as dual-node or three-node. The single-node (cloud disk) architecture offers better cost-effectiveness and performance, but its availability level is lower than that of the multi-node architecture.
Impact of migration on the source database: During the DTS full migration phase, a certain read load is generated on the source instance, so it is recommended to start the migration during off-peak hours. The incremental phase is implemented through Binlog subscription and has minimal impact.
When to unsubscribe: Unsubscribe from the old architecture instance only after the business traffic has been switched over, the system is running stably, and data consistency is confirmed. Before unsubscribing, make sure that a final backup has been completed to avoid irreversible data loss caused by accidental deletion.
lower_case_table_names: The lower_case_table_names parameter values of the old and new architecture instances must be set to the same value before migration.
Pre-Migration Notes
As DTS already provides complete migration preparations, business impacts, and usage instructions, you can refer to Migrating MySQL to MySQL for detailed pre-migration instructions.
Operation Steps
Step 1: Purchase a Single-Node (Cloud Disk) Instance with the New Architecture
1. Log in to the TencentDB for MySQL purchase page.
2. Under Instance Architecture, choose Cluster edition > Single-Node.
3. Configure other options on the page as needed, and then complete the purchase.
Note:
For configuration of other options on the purchase page and complete purchase steps, see Creating a MySQL Instance.
Step 2: Purchase and Configure a DTS Migration Task
1. Log in to the DTS console, select Data Migration in the left sidebar, and then click Create Migration Task to go to the migration task creation page.
2. On the migration task creation page, select the source instance type and region as well as the target instance type, region, and specification for migration, and then click Buy Now.
Configuration Item | Description |
Creation Mode | Select Create task. |
Billing Mode | Only pay-as-you-go is supported. After purchase, no fees are charged during the task configuration and full migration phases. Fees are charged only during the incremental migration phase. However, due to the unified requirements of Tencent Cloud pay-as-you-go billing, a one-hour fee is frozen after purchase. For detailed billing rules, see Billing Items and Rules. |
Source Instance Type | Select MySQL here. |
Source Instance Region | This refers to the source region of the DTS data migration service. Select the region where the source instance resides. |
Target Instance Type | Select MySQL here. |
Target Instance Region | Select the region where the target instance resides. |
Specification | Select the specifications for the migration link based on your business needs. For performance and billing details of different specifications, see Billing Overview. |
Quantity | A maximum of 10 migration tasks can be purchased in a single purchase. |
3. After the purchase is completed, you are redirected to the data migration task list. Select the task you just purchased for the configuration.
4. On the page for setting the source and target databases, complete the settings for the task, the source database, and the target database. After the connectivity test between the source and target databases passes, click Save.
Note:
If the connectivity test fails, troubleshoot and resolve the issue based on the prompts and the repair guide, and then try again.
Task Configuration
Parameter | Description |
Task Name | DTS automatically generates a task name. It is recommended to change it to a business-meaningful name for easier identification. |
Running Mode | Immediate execution: The task will be started immediately once the pre-check passes. Scheduled execution: Set a start time for the task. After the pre-check passes, the task is not started immediately, but is started at the scheduled time. |
Automatic Retry | After this configuration is set, if a synchronization task is temporarily interrupted due to network exceptions or other issues, DTS will automatically retry and resume the task within the configured time range, eliminating the need for manual intervention. The supported time range for automatic retries is 5–720 minutes. |
Source Database Settings
Parameter | Description |
Source Instance Type | Source instance type selected during creation. It cannot be modified. |
Source Instance Region | Source instance region selected during purchase. It cannot be modified. |
Service Provider | Select General. |
Access Type | Select VPC as the access type. |
VPC | After selecting VPC as the access type, configure the VPC by selecting the source instance's VPC, host address, and port. |
Account/Password | Account and password of the source database. |
Connection Method | Secure Sockets Layer (SSL) connection refers to the use of SSL to establish a secure connection between DTS and the database, encrypting the transfer link. Selecting an SSL secure connection may increase the database connection response time. Generally, Tencent Cloud private network links are relatively secure, so you do not need to enable SSL secure connections. |
Target Database Settings
The target database parameter settings are similar to those of the source database. Select cloud database as the access type. No further details are provided here.
5. On the migration option and object setting page, configure the migration type and migration objects, and then click Save.
Note:
If you plan to rename a table during migration (for example, renaming table A to table B), you must select the entire database (or the entire instance) where table A resides rather than only table A as the migration object; otherwise, after the rename operation, data from table B will not be synchronized to the target database.
Configuration Item | Description |
Migration Type | Select the migration type based on your scenario. Structure migration: Structured data, such as databases and tables, will be migrated. Full migration: Migrates the schema and data of the entire database. The migration content only includes data that already exists in the source database when the task starts, and does not include new data written to the source database in real time after the task starts. Full + incremental migration: Migrates the schema and data of the entire database. The migration content includes existing data in the source database when the task starts, as well as new data written to the source database in real time after the task starts. Select this scenario if data is written to the source database during migration and you need smooth migration without downtime. |
Data Consistency Check | When you select Full+incremental migration, data consistency check is supported, which performs a detailed comparison of data between the source and target databases after migration. After you select Full check of migration objects, and when the migration task proceeds to the incremental synchronization phase with the data gap and latency between the target and source databases being 0 MB and 0s respectively, DTS automatically triggers a consistency check task. If you do not select Full check of migration objects, you can also manually trigger a consistency check when the migration task proceeds to the incremental synchronization phase. For details, see Creating a Data Consistency Check Task. |
Migration Object | Entire instance: Migrate the entire instance, excluding system databases such as information_schema, mysql, performance_schema, and sys. Specified objects: Migrate the specified objects. |
Advanced Migration Object | The migration of stored procedures (Procedure), functions (Function), triggers (Trigger), and events (Event) is supported. The migration of advanced objects is a one-time operation. It only migrates advanced objects that already exist in the source database before the task starts. Any new advanced objects created after the task starts will not be synchronized to the target database. Stored procedures and functions are migrated during the source database export phase. Triggers and events are migrated at the end of the task if no incremental task exists, or after you click Complete if an incremental task exists. Therefore, after you click Complete, the transition time of the task will increase slightly. |
Selected Object | Database and table mapping (database and table renaming) is supported. Hover over a database/table name to display the Edit button. Click the button and fill in a new name in the popup. When you select advanced objects for migration, it is recommended not to rename databases or tables, as this may cause the migration of advanced objects to fail. |
Sync Online DDL Temp Table | If the gh-ost or pt-osc tool is used to perform online DDL operations on tables in the source database, DTS supports migrating the temporary tables generated by online DDL changes to the target database. If you select gh-ost, DTS will migrate the temporary table names generated by the gh-ost tool (_table_name_ghc, _table_name_gho, and _table_name_del) to the target database. If you select pt-osc, DTS will migrate the temporary table names generated by the pt-osc tool (_table_name_new and _table_name_old) to the target database. |
6. On the check task page, run the check. After the check passes, click Start Task.
7. Return to the data migration task list. The task enters the Ready-to-run status. After running for 1 to 2 minutes, the data migration task will officially start.
Select Structural migration or Full migration: The task automatically ends upon completion and does not need to be manually ended.
Select Full + Incremental migration: After full migration is completed, the task automatically enters the incremental data synchronization phase. Incremental data migration does not end automatically. You need to manually click Complete to end incremental data migration.
Select an appropriate time to manually complete incremental data migration and complete the service cutover.
Observe that the migration phase is incremental migration and no latency is displayed. Then stop writes to the source database for a few minutes.
When the data gap between the target and source databases is 0 KB and the latency between the target and source databases is 0 seconds, manually complete the incremental migration.
Step 3: Switching Business Traffic and Unsubscribing from the Old Architecture Instance
1. When the status of the migration task changes to Task successful, you can formally perform service cutover. For details, see Cutover Instructions.
2. After confirming that the business is running stably without abnormal errors and the new instance remains running normally, terminate the old architecture Basic Edition instance. For details about how to terminate an instance, see Terminate Instance.
Note:
Before the cutover, back up the source instance. After the cutover, retain the old instance for a period of time for emergency rollback. Unsubscribe from the old instance only after confirming that the system is stable.
FAQs
Q1: How Do I Determine Whether My Instance Uses the Old Basic Edition Architecture or the New Cloud Disk Edition Architecture?
A: Log in to the TencentDB for MySQL console and view the architecture and specification identifiers of the instance. An instance that is single-node, basic, and does not support enabling the public network is the old architecture Basic Edition.
Q2: Do I Need to Stop My Services During DTS Migration?
A: Full service downtime is not required. DTS supports full + incremental migration. Only a brief write pause or an off-peak switchover is required at the final cutover moment, so the overall downtime window is very small.
Q3: Can I Delete the Old Instance Directly After the Migration Is Completed?
A: We recommend that you first perform the cutover, observe stability, and then unsubscribe, while retaining the final backup. Release the old instance only after confirming that no rollback is required.
Q4: My business has high availability requirements. Can I still use this process?
A: The process remains unchanged, but for the target instance, select the new multi-node architecture instead of the single-node (cloud disk) architecture to gain automatic failover capabilities. In addition, for the complete configuration of the migration task, see Migrating MySQL to MySQL.
フィードバック