Re:Goodbye Docker and Thanks for all the Fish
by CWuestefeld on Sunday March 10, 2019 @01:13PM
(#19352944)
For most use cases, other features are secondary to replication.
I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.
Re:Goodbye Docker and Thanks for all the Fish
by ericb on Sunday March 10, 2019 @02:23PM
(#19353383)
I suppose if you reason from some other criteria than avoiding downtime and data loss, a different conclusion was possible at the time.
To each their own.
Re:Goodbye Docker and Thanks for all the Fish
by CWuestefeld on Sunday March 10, 2019 @03:00PM
(#19353651)
Replication is not the best way to avoid data loss. And it's not the only way to avoid downtime (e.g., the AWS Aurora PostgreSQL servers I run don't use the normal pg replication).
And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context.
So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.
For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.