Why is this a problem? A typical deployment will have multiple replicas, with (hopefully) small replication lag. Those should be able to be promoted to be the new primary within a minute.
Why is this a problem? A typical deployment will have multiple replicas, with (hopefully) small replication lag. Those should be able to be promoted to be the new primary within a minute.
What happens within that minute to database writes?
In my example, I will get a page for large replication lag. But not for an unplanned failover. That will be an alert, but not a page.
You cannot build operational procedures based on “hope”.
High replication lag occurs for many many reasons (and they are not a rare event, or something that you can prevent). As well as network partitions.
Replication and binary logs can get corrupted, there can be deadlocks, duplicated row errors, etc.
The thing is that database administration is a broad and complicated topic, a small mistake or the lack of understanding how these systems work can easily lead to huge data losses.
Ah yes, HN. You know there are billions of sites(wp mostly), LoB apps etc that run on 1 mysql/pg/etc instance right? Replicas are not typical and a tiny minority.
Tech is rife with people who have never set up an old school HA solution proffering advice on how a miasma of cloud services makes theirs better.