How does a database survive a machine catching fire?

A database survives a machine catching fire by never keeping its only copy on that machine. It uses replication: keeping several copies of the data on different machines, so that if one is lost, another takes over. This lets a system carry on when parts fail, which is called failover, and it also lets users be served from nearby places and the work be spread across machines. A backup is different, because its saved copy stays unchanged for a long time, while replicas are updated constantly.

The common setup is single-leader replication. One database, the leader, handles all the writes and records them in a log, and the changes then travel to the replicas. Replicas mostly answer reads, though they may serve slightly stale data, because there is a delay, called replication lag, between a change on the leader and its arrival. If the leader dies, a replica steps up, and ideally users barely notice.

The big choice is when a write counts as done. With synchronous replication, it isn't finished until the remote copy also confirms it, so no data is lost, but every write waits, and distance hurts: the speed of light means even 10 km needs at least 67 millionths of a second for a round trip. With asynchronous replication, a write finishes as soon as the local copy has it. That is much faster, but if the machine dies at the wrong moment, the newest data may be lost. Fast and safe pull in opposite directions.