4 ms·
Most heroku users are using relational databases like postgres, and relational databases don't failover transparently. If client apps can't failover to other AZ
by stickfigure 5y ago
Most heroku users are using relational databases like postgres, and relational databases don't failover transparently. If client apps can't failover to other AZs, why does it matter for heroku's service itself to do so?
Getting geographic failover to work seamlessly generally requires application-level knowledge or at the very least, exotic datastores like DynamoDB or Firebase. For better or worse, that's just not the way most people want to develop.
- more_corn 5y agoRDS has this mostly solved. They silently mirror the master into another AZ. If the primary fails the internal routing redirects to the clone.
- stickfigure 5y agoTell me, are transactions guaranteed to have replicated before they commit? If not, you have a major consistency issue during failover. Maybe your workload can accept dropping a window of transactions, maybe not.
- electroly 5y agoThey are. RDS multi-AZ replication is synchronous. Aurora is asynchronous, and multi-region replication is asynchronous, but a multi-AZ deployment of the "traditional" database engines in RDS is synchronous. It's rather the opposite of what you said before: if you stick to the old fashioned databases, this is easy to set up, failover is automatic, and no app-level changes are needed. I think you may have been thinking of multi-region, since you mentioned geographic failover. Multi-AZ isn't really geographic failover.