Creating Clone Instances
TDSQL Boundless supports the instance cloning feature. Users can restore an instance to any point in time within the log backup retention period or to a specified backup set by cloning. The cloning operation creates a new instance based on the backup data, according to the point in time or backup set selected by the user. After the new instance is verified, users can migrate data back to the source instance via DTS or directly use the cloned new instance.
Cloning Methods
TDSQL Boundless supports the following two cloning and recovery methods:
By time point: Restores an instance to any point in time. The selectable range of time points is determined by the log retention duration.
By backup set: Restores an instance to a specified backup set. The selectable range of backup sets is determined by the data backup retention duration. Users can select a backup set from existing physical backups or snapshot backups for recovery.
Costs for New Instances
The billing mode for the new cloned instance supports selecting pay-as-you-go on the cloning page. For detailed billing information, see Billing Overview.
Billing for the new cloned instance starts only after the cloning process is fully completed.
Prerequisites
The source instance must be in the Running state.
If you select Backup Set Cloning as the cloning method, the source instance must have completed physical backups or snapshot backups. You can view the backup status in the Data Backup List on the TDSQL Boundless console.
The account balance must be greater than 0.
Limitations
The specification of the new cloned instance must be greater than or equal to that of the source instance.
The total disk capacity of the new cloned instance must be greater than the size of the data to be cloned; otherwise, the cloning operation fails.
When cloning is performed via snapshot backup, the number of nodes and disk capacity of the new instance must not be less than the corresponding values of the source instance.
The database version, SQL Mode, and parameter template of the new cloned instance are automatically inherited from the source instance's configuration, so users do not need to configure them manually.
During the cloning process, the new instance is not displayed in the console instance list and becomes visible only after the cloning is successful.
During the cloning process, operations such as restarting, migrating, or upgrading the version cannot be performed on the source instance. It is recommended to perform these operations after the cloning is completed.
Deploy the cloned instance in the same VPC and subnet as the source instance to reduce network latency and configuration complexity.
Cloning is not supported between instances with different replica configurations. The number of log replicas in the new cloned instance must match that of the source instance (for example, a 2+1 replica instance can only be cloned as a 2+1 replica instance).
Steps
1. Log in to the TDSQL Boundless Console. In the Instance List, click Instance ID or click Manage in the Operation column to enter the Instance Management page.
2. Go to the Backup and Restoration > Clone Instance List tab, and click Create Clone Instance.
3. On the TDSQL Clone Instance page, complete the following configurations:
Clone Recovery Settings
Parameter | Description |
Clone Recovery Method | Select a clone recovery method: By time point: Restores to any point in time within the log backup retention period. By backup set: Restores to the backup set of a specified physical backup or snapshot backup. |
Recovery point in time | When By time point is selected, specify the specific time point to restore to. The selectable range is determined by the log backup retention period. |
Backup Set | When By backup set is selected, select the backup set to restore to from the list. The backup set originates from the physical backup or snapshot backup of the source instance. |
Basic Configuration
Parameter | Description |
Engine | TDSQL Boundless by default. |
Region | Consistent with the source instance's region by default and cannot be modified. |
Billing Mode | Currently supports Pay as You Go. The cloned instance is billed only after it is fully created. |
Network | Select the VPC and subnet for the new instance. It is recommended to select the same network environment as the source instance to reduce network latency. |
Specs Configuration
Parameter | Description |
Instance type | Select the architecture type for the cloned instance. |
Deployment Mode | Users can select the number of AZs to deploy. Single-AZ: All resources reside in the same AZ, offering the lowest network latency. Two AZs: The application runs across two AZs and can withstand a single AZ failure. Three AZs: Resources are distributed across three AZs, enabling service continuity and reduced recovery time in the event of a single AZ failure. |
AZ | For instances deployed across multiple AZs, you can set a primary AZ. After a primary AZ is set, the weight of the TDSQL Boundless nodes in that AZ will be increased to 99%, meaning 99% of requests will be routed to those nodes for processing. You can choose not to set a primary AZ, or you can cancel / adjust the primary AZ configuration via the console. After a primary AZ is set, the configuration adjustment feature cannot be used unless the user temporarily cancels the primary AZ setting. This is because after a primary AZ is set, TDSQL cannot proactively switch the Leader to a different AZ on demand to ensure business continuity during configuration changes. If you need to perform this operation, confirm the potential business performance impact of removing the primary AZ setting, then remove the setting before proceeding with the configuration change. |
Storage Class | Cloud Disk: offers higher availability and data durability, and supports larger single-node capacity and fast backup. Local Disk: offers better throughput and IOPS, but has a longer recovery time compared to Cloud Disk. |
Hybrid Node Specs | Set the specification for each peer node. |
Hybrid Node Disk Capacity | Set the hard disk capacity for each peer node. The total hard disk capacity of the new instance must be greater than the backup file size multiplied by the number of replicas; otherwise, the cloning will fail. |
Hybrid Nodes | Set the number of peer nodes. The default is 3. If a larger specification is required, contact Tencent Cloud Technical Support. Note: In snapshot cloning scenarios, the number of nodes and disk capacity of the new instance must not be less than the corresponding values of the source instance; otherwise, the cloning will fail. |
Others
Parameter | Description |
Tag | Optional. Add tags to new instances for resource classification management in key-value pairs. Supports adding multiple tags. |
Instance Name | Select an instance naming method: Name After Creation: Name the instance in the console after it is successfully created. Name Immediately: Enter the instance name in the input box, and it takes effect upon creation. |
4. After it is confirmed that all configurations are correct, click Buy Now.
After a successful purchase, you can view the cloning progress and results in the following ways:
View the cloning details and progress on the Backup and Restoration > Clone Instance List page of the source instance.
After cloning is successful, view the newly created clone instance on the Instance List page.
Next Steps
After the clone instance is created, you can perform the following operations:
Directly use the clone instance as a new business instance.
Migrate data from the clone instance back to the source instance via DTS. Applicable scenarios are as follows:
Partial Data Recovery: If a user mistakenly updates a large amount of data in Table A and the UNDO logs have been purged, the user can recover the data on the clone instance and then migrate it back to the source instance via DTS.
Source Instance Failure Recovery: When the source instance is damaged, you can clone it to a new instance. After the source instance recovers, use DTS to migrate the data generated during the recovery period back to the source instance.
FAQs
Does Cloning Affect Access to the Source Instance?
No. The cloning operation uses existing backup data for restoration and does not affect normal access to the source instance. The source instance can continue to provide read and write services normally during the cloning process.
Are Database Parameters of the Clone Instance Consistent with Those of the Source Instance?
Yes. The clone instance automatically inherits the SQL Mode and parameter template configurations from the source instance. Users do not need to manually configure database parameters.
What Are Common Causes of Clone Failures?
Common causes include:
The total disk capacity of the new instance is insufficient (it must be greater than the backup file size multiplied by the number of replicas).
In snapshot cloning scenarios, the number of nodes or disk capacity is lower than that of the source instance.
Cloning between 2+1 replica and 3 replica instances is not supported (due to inconsistent log replica counts).
The source instance is in an abnormal or unavailable state.
The account has insufficient balance or is in arrears.
When Does Billing Start for a Clone Instance?
Billing for the clone instance starts only after the cloning process is fully completed. No charges are incurred during the cloning process. The billing start time is determined by the time when the cloning succeeds.
How Is the Available Time Range Determined for Point-in-Time Cloning?
The selectable time range is determined by the log backup retention period (7 days by default).
Is the Backup Policy of the Clone Instance Consistent with That of the Source Instance?
The backup policy for the clone instance is not automatically inherited from the source instance's configuration. After the cloning succeeds, users need to configure a backup policy separately for the clone instance.
Does the Clone Instance Support Specification Change?
Yes. After the clone instance is successfully created, you can modify its specifications based on business requirements, such as scaling out nodes or expanding disk capacity.
Is There a Limit on the Number of Clone Operations?
There is no limit on the number of times. Users can clone the same source instance multiple times as needed.
피드백