Four migration steps, and the one that is right twice for opposite reasons
A large database is moving with DMS: a full load, then change data capture to keep the target current, then a cutover. Every step below is one the team has to do, and every one of them is written somewhere in the plan.
The plan has them in the wrong order. The consequence is not an error message — it is a full load that takes a weekend it did not need to, or a CDC phase that never catches up because every change is a table scan.
Put the four steps in the order they must run.
?Secondary indexes are the trap. They are wrong during one phase and required during the next, and the phases are adjacent.
Outside every boundary: Target database (being built), Replication instance (reads and applies), Source database (still serving) Connections: Source database calls Replication instance — load, then changes Replication instance calls Target database — applies
Target databasebeing built
Replication instancereads and applies
Source databasestill serving
The order the migration must run in
Your order
- Nothing yet. Tap them on the left, best first.
Order them by the order the migration must run in. Tap to place, tap again to take back.