4 ms·
It also doesn't manage failover. Shared storage is a totally viable approach. (I've worked as a PostgreSQL DBA for over a decade and have built multiple shared
by rosser 9y ago
It also doesn't manage failover. Shared storage is a totally viable approach. (I've worked as a PostgreSQL DBA for over a decade and have built multiple shared storage-based HA environments for multiple employers.)
If you mis-manage failover, you will destroy your data. This makes proper backup even more important.
- colanderman 9y agoNor does Postgres replication manage failover. Either way you need a 3rd party tool. Yep, botched failovers are bad. Of course, a botched failover between replicated DBs is no walk in the park either. In many such cases you'll still want to pull backups anyway, if there's no clear way in your domain to merge two "authoritative" databases.
- rosser 9y ago> In many such cases you'll still want to pull backups anyway... In all cases where you care about your data, you must take backups. There is no substitute for that step. Additionally, you want to periodically restore your backups and test them for validity — ideally automatically. There's a saying in the ops world, borne of bitter experience: "Your backups are only as good as their last successful restore."
- grantwu 9y agoI read "pull backups" as "restore from backup" not "make backups".
- colanderman 9y agoWhat grantwu said. You misinterpreted me. Seems to be a theme today. I guess I should spell things out more clearly in the future.
- rosser 9y agoOk, my apologies. I've never heard that phrasing before, but now that you clarify, I understand it. Ambiguity in online discourse is an ongoing problem. Thanks for helping resolve this occurrence without acrimony.