Specification changes — including changes to the RDS edition, instance type, and storage capacity — can take anywhere from seconds to an extended period depending on your instance's storage type and workload. The primary driver is whether the change triggers a cross-instance data migration.
To minimize the time required, schedule specification changes during low-write periods or stop writing data to the instance beforehand.
How storage type determines migration path
Your instance's storage type determines whether a specification change requires migrating data to a new instance:
| Storage type | Cross-instance data migration | Time required |
|---|---|---|
| Local SSD | May be required | Long (if migration is triggered) or short (if not) |
| Standard or enhanced SSD | Not required | Short |
For instances using standard or enhanced SSDs, no data migration occurs. The specification change completes quickly, and the factors in the next section do not apply.
For instances using local SSDs, a specification change may trigger a migration from the original instance to a new instance. When migration is triggered, ApsaraDB RDS backs up the data on the original instance and restores it to the new instance — a process that can take considerable time.
Factors that affect migration time (local SSDs only)
When a cross-instance data migration is triggered, the following factors determine how long it takes.
Full data size
The total size of your data directly affects how long the initial backup and restore take. Network bandwidth and backup speed also contribute — larger datasets over constrained bandwidth take proportionally longer.
Redo log size
If redo logs are large, the actual amount of data to back up exceeds the initial estimate. This extends the time needed to restore data to the new instance.
Locks
ApsaraDB RDS locks related objects during the backup phase. Heavy locking activity slows the backup and extends overall migration time.
Number of tables
The number of tables in the instance is a factor that affects migration time.
Incremental data size
After the full data migration completes, ApsaraDB RDS migrates the incremental data generated during the migration window. The larger this incremental dataset, the longer the overall specification change takes.
Incremental data write speed
The rate at which incremental data is replayed affects how quickly the new instance catches up. This rate depends on:
The speed at which logged SQL statements are replayed
Whether SQL statements are executed on individual tables
Whether data definition language (DDL) statements are executed on the original instance during migration
Data synchronization latency
Before switching traffic to the new instance, ApsaraDB RDS must establish a synchronization link and wait for data synchronization to complete. Higher latency delays the switchover. Latency is influenced by:
Write loads on the original instance
DDL statements executed on the original instance during synchronization
Joint queries running across multiple tables