# rds-migration

Part of **RDS**

# ApsaraDB RDS Data Migration Troubleshooting Guide

## Problem Index

| Problem | Symptom | Severity | Solution Summary |
|--------|--------|---------|------------------|
| Completed count exceeds total count in DTS migration | `Completed count > Total count` shown in migration progress UI or API | Low | Understand that total count is an initial estimate; actual value updates after migration completes |
| Misinterpretation of migration progress metrics | User assumes migration is stuck or corrupted due to count mismatch | Medium | Review migration details post-completion for accurate final counts |
| Confusion about DTS migration status reporting | Inconsistent expectations about real-time accuracy of progress indicators | Low | Refer to official documentation on DTS estimation behavior |

## Problem Details

### Problem 1: Completed Count Exceeds Total Count During DTS Migration

**Symptoms**
- Error message: Not an error — but observable behavior: `Completed count exceeds total count` in DTS migration monitoring interface
- Behavior: The "Completed" row shows a higher number than the "Total" row during an ongoing migration
- Context: Typically observed during full data migration phase for MySQL-compatible databases via DTS

**Root Cause**
- The "Total count" displayed at the start of migration is an **initial estimate** generated by MySQL’s internal table statistics
- This estimate may be inaccurate due to concurrent writes, table fragmentation, or outdated optimizer statistics
- After migration completes, DTS updates the "Total count" to reflect the **actual number of records processed**, which can be lower than the completed count temporarily shown during migration

**Solution**
1. Do not interpret the count discrepancy as a failure or data inconsistency
2. Allow the migration task to complete fully
3. After completion, check the final migration report in the DTS console:
   - Navigate to **Data Transmission Service (DTS) Console** → **Migration Tasks** → Select your task → **Migration Details**
4. Verify that both source and destination record counts match in the final summary

**Verification**
- Post-completion, the "Total count" will reflect the true number of migrated records
- Expected behavior: `Completed count == Total count` in the final report
- Use the following SQL on source and destination to validate (example for MySQL):
```sql
SELECT COUNT(*) FROM your_table_name;
```

### Problem 2: Misinterpretation of Real-Time Migration Progress

**Symptoms**
- User observes fluctuating or non-monotonic progress percentages
- Belief that migration is stalled or looping due to counterintuitive count updates
- No explicit error, but operational concern about reliability

**Root Cause**
- DTS uses dynamic estimation during full data migration; initial totals are not guaranteed to be precise
- As new rows are written to the source during migration (in full + incremental mode), the effective dataset size changes
- The UI prioritizes real-time visibility over static accuracy during the process

**Solution**
1. Avoid making decisions based on intermediate progress metrics
2. Monitor task status instead of raw counts:
   - Status should transition from `Migrating` → `Incremental Data Migration` → `Completed`
3. Enable detailed logging if available:
   - In DTS task configuration, ensure **Detailed Log** or **Monitoring Metrics** are enabled
4. Use CloudMonitor or DTS built-in alerts for actual failures (e.g., connection loss, permission errors)

**Verification**
- Confirm task status is `Completed` with no error logs
- Cross-check data consistency using checksum or row count validation post-migration

### Problem 3: Unexpected Behavior Due to Outdated Table Statistics

**Symptoms**
- Large discrepancy between estimated and actual row counts (e.g., estimate: 10K, actual: 1M)
- Migration takes significantly longer than expected based on initial progress rate

**Root Cause**
- MySQL’s `INFORMATION_SCHEMA.TABLES.TABLE_ROWS` provides approximate values based on storage engine statistics
- These statistics are not updated in real time and can be stale, especially on busy tables
- DTS relies on this value for initial total estimation

**Solution**
1. (Pre-migration best practice) Update table statistics on the source database:
```sql
ANALYZE TABLE your_table_name;
```
2. For MyISAM tables, statistics are more accurate; for InnoDB, they remain estimates
3. If migration is already running, no action is needed — DTS will self-correct upon completion

**Verification**
- After `ANALYZE TABLE`, query the estimate:
```sql
SELECT TABLE_ROWS 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table';
```
- Compare with actual `COUNT(*)` — closer alignment indicates better estimation

## FAQ

**Q: Is it normal for the completed count to be higher than the total count during DTS migration?**  
A: Yes. The "total count" is an initial estimate from MySQL and is updated to the actual value only after migration completes. The temporary discrepancy is expected and does not indicate data corruption.

**Q: How can I verify that my data migration was successful?**  
A: After the DTS task shows "Completed" status, compare row counts and checksums between source and destination databases. Use `SELECT COUNT(*)` and, if supported, `CHECKSUM TABLE` for critical tables.

**Q: Why does the migration progress percentage sometimes decrease or stall?**  
A: Because the denominator (total count) may be adjusted as DTS discovers the true dataset size. Progress is recalculated dynamically, which can cause non-linear percentage changes.

**Q: Can I trust the DTS migration if the counts don’t match during the process?**  
A: Yes. DTS ensures data consistency regardless of interim count displays. Final validation occurs after all data (full + incremental) is synchronized.

**Q: Should I run ANALYZE TABLE before starting a migration?**  
A: It is recommended for large or frequently updated tables to improve initial estimation accuracy, though it is not required for migration correctness.