Two. Run one in warm/hot standby, optionally with synchronous commits if you want (nearly) guaranteed zero data loss, and can tolerate the increased write latency.
Technically you’ll need a third server to perform the failover, but it doesn’t need to be nearly as big, as it’s just watching heartbeats and issuing commands.
How many servers are needed to bounce back from a server failure in a few minutes? Should we consider 3 VMs instead of 1 physical?
Two. Run one in warm/hot standby, optionally with synchronous commits if you want (nearly) guaranteed zero data loss, and can tolerate the increased write latency.
Technically you’ll need a third server to perform the failover, but it doesn’t need to be nearly as big, as it’s just watching heartbeats and issuing commands.
Server failures are rare. Its still usually going to be cheaper to have physical servers even with spare capacity for failures.
I think these days it's more: were do we find the grey old unix guy who confidently will host your db for you on bare metal.
Which these days seems to mean a 35+ year old who has ever worked on anything other than a big-three cloud.
1 reply →