Migrate an OLTP database with minimal downtime
near-zero-downtime data migration.
take an initial bulk load, then use change data capture to replicate ongoing changes until source and target are in sync, validate, then cut over during a brief window with a rollback plan.
WHAT THIS TESTS This checks whether you can migrate a busy transactional database while keeping downtime to seconds or minutes, using continuous replication rather than a long outage.
A GOOD ANSWER COVERS A phased approach. First take an initial full load: a consistent snapshot of the source loaded into the cloud target. Because the source keeps changing, enable change data capture to read the database transaction log and stream every subsequent insert, update, and delete to the target, so it continuously catches up and then stays in near-real-time sync. While both run in parallel, validate with row counts, checksums, and ideally a read-traffic comparison. The cutover is a short, planned window: stop or quiesce writes to the source, let CDC drain the final changes so target equals source, repoint the application connection string or DNS to the cloud database, smoke-test, and resume writes. Crucially, keep the source intact and the replication reversible so you can roll back if the target misbehaves.
COMMON WRONG ANSWERS A stop-the-world export and import, causing hours of downtime unacceptable for high-uptime OLTP. No CDC, so changes during the long load are lost. No validation step. No rollback plan, so a bad cutover is irrecoverable. Forgetting to handle in-flight transactions and sequences.
LIKELY FOLLOW-UPS How does log-based CDC work? How do you verify data integrity? How do you handle schema differences? What is your rollback trigger and procedure?
ONE CONCRETE EXAMPLE Using AWS Database Migration Service, you run a full-load task into Aurora, then DMS switches to ongoing replication via CDC from the source transaction logs. You monitor replication lag near zero, validate with DMS data validation, then during a brief maintenance window pause application writes, confirm lag is zero, update the connection endpoint, and verify, keeping the on-premise database ready as a fallback.
Interview question
Why is change data capture central to migrating a live OLTP database with minimal downtime?
- a.It streams ongoing changes so the target stays in sync during the long initial load, shrinking cutover to a brief windowCorrect
- b.It lets you skip the initial bulk load entirely
- c.It compresses the database so the export finishes faster
- d.It eliminates the need to validate the migrated data
Why? this is the answer
CDC replicates every change made during and after the bulk load, keeping the target current so the actual cutover is short. It does not compress data, remove the need for validation, or replace the initial full load it builds upon.
Just read this? Test yourself on what you have been reading.
Read the original → eidosoft.co
- #database-migration
- #change-data-capture
- #zero-downtime
- #oltp
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles