What is the difference between a planned switchover and an unplanned failover in a primary/replica relational database setup, and how does each affect the risk of losing committed data?

## The two operations Both end with a different node accepting writes, but they differ in whether the outgoing primary cooperates. **Switchover (planned role swap).** The rough sequence: 1. Stop or drain application writes, or put the primary into a state where no new transactions start. 2. Wait for the target replica's replay position to equal the primary's flush position, i.e. lag reaches zero. 3. Cleanly shut down or demote the primary so its final changes are shipped and durable on the target. 4. Promote the target; it becomes writable. 5. Repoint the remaining replicas and the old primary at the new primary. 6. Repoint client traffic through the proxy or service layer. Because step 2 completes before step 4, no committed transaction is lost. The cost is a brief write outage, usually seconds, and it must be brief enough that connection pools and retry logic tolerate it. **Failover (reactive promotion).** The primary crashed, its host died, or it became unreachable. You cannot drain or wait for catch-up because the source of truth is gone. The manager or operator picks the replica with the furthest replay position, promotes it, and repoints everything else. Anything the dead primary had committed locally but not yet shipped is lost. ## Where data loss comes from Under asynchronous replication a transaction commits locally, returns success to the client, and only then are its changes streamed. The window between local durability and remote receipt is the exposure. If the primary dies inside that window, those commits exist only on its disk, so promotion loses them; if the disk survives you may be able to recover them later by hand, but the cluster has already moved on without them. Switchover eliminates the window by construction. Failover does not; it merely bounds it by how small you kept the lag and which promotion policy you use. ## What else differs operationally - **Other replicas.** In a switchover, they can be repointed calmly. After a failover, any replica that had received changes the new primary never got is ahead of it and cannot simply follow; it must be rewound or rebuilt. - **The old node.** After a switchover it rejoins as a replica immediately. After a failover it may have committed transactions the new primary does not have, so it has diverged and needs a rewind or full rebuild. - **Client impact.** A switchover can be sequenced with the routing layer, so clients see a short pause. A failover means in-flight transactions are aborted, connections are broken, and applications must reconnect and retry. - **Sequences and identity.** In both cases the new primary continues issuing surrogate keys, but after a failover an id range may have been consumed by lost transactions, so gaps appear. Gaps are normal; duplicates would mean split-brain. ## Confusion to avoid Candidates often use the words interchangeably or claim failover is lossless because replication is enabled. It is lossless only when the replica had every change at the moment of failure, which asynchronous replication cannot promise. Synchronous commit narrows this but changes write latency and introduces its own availability question when the standby is down. Similarly, a switchover is not merely a failover you happened to schedule. The difference is that the old primary is alive and cooperating, which is what allows the catch-up step and makes the old node reusable afterwards. ## Interview framing Define both in one sentence each, name the catch-up step as the reason a switchover is lossless, state that a failover's loss window comes from asynchronous replication, and mention the follow-up work: repointing other replicas and dealing with the returning old primary. Add that switchovers are the standard way to rehearse the machinery without waiting for an outage.