Hacker News Reader

Comment by nine_k | Hacker News Reader

While I generally like Postgres more, the comparison does not include replication. It looks like master-master replication is still better supported on MySQL (but I may be wrong).

Another important thing for me is table partitioning. Both databases support it, but I'd love a comparison. MySQL seemingly covered a lot of ground in this regard.

View on HN

A co-worker of mine actually wrote on replication in postgres recently:

http://peter.eisentraut.org/blog/2015/03/03/the-history-of-r...

Thanks for sharing, great article. I think most of the folks singing the praises of Postgres over MySQL have never had to operationally support both databases in complex multi-DC replication environments. The answer to many replication issues with Postgres is 'rebuild the DB from scratch', which is a terrible answer when you have large databases.

I thankfully no longer have to support Postgres in production, but I can still vividly recall that terrible sense of dread I'd get in my stomach whenever I'd receive a replication alert for a Postgres database.

what sort of "replication issues"? if you use archive_command and ship/rsync wal files somewhere you will safeguard against falling too far behind (past an arbitrary wal_keep_segments limit). Also, in 9.4 you have replication slots so you can get rid of wal_keep_segments altogether: the master knows the replication progress/status of each slave and keeps required wal files around until they are no longer needed.

or were you referring to some other issue with failed replication? something that mysql handles better/differently?

Having done quite a bit with MySQL's replication in a master-master scenario, dragons be here. It works if you know exactly what your application will be doing, but honestly, it's best to avoid it. Master-master replication is tricky with any system, but the particular implementation of MySQL's replication semantics make it even more prone to inconsistent data.

Reply on news.ycombinator.com