3 ms·

The gitlab situation and Uber's article speak to the level of immaturity of PGSQL's native replication feature, and more importantly: how not widely google-able

The gitlab situation and Uber's article speak to the level of immaturity of PGSQL's native replication feature, and more importantly: how not widely google-able nor documented/adopted the replication strategies are.

djsumdog 10y ago
I didn't think replication was one of the issues Uber noted, but then I looked back at the blog posts: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/ ..and yep, it's listed. In my own experience, I'd still take PostgreSQL over MySQL. MySQL doesn't allow for DDL modifications within a transaction, which makes database migration with tools like Flyway a little less resilient. On the other hand, you can use one connection for multiple databases with MySQL, MSSQL and others, which you can't with Postgres. I mean really, they all have trade-offs. It really just depends on your specific use case.
tshannon 10y ago
I believe gitlab used slony, not the native replication. I'm not well versed in postgres, but that's what I gleaned from reading their event log.
- jessaustin 10y ago
  The decision not to use native replication might be attributed to its purported immaturity?
- detaro 10y ago
  The google doc says at the bottom that slony only was used for a migration once, otherwise they use the replication features built into postgres.
- YorickPeterse 10y ago
  As mentioned below we only used Slony to upgrade from 9.2.something to 9.6.1. For regular replication we use PostgreSQL's streaming replication.
benmmurphy 10y ago
i chose postgres over mysql at my current job because there was an easy to use backup scripts (wal-e) available at the time and i didn't see anything comparable for mysql. so we have a hot slave and also streaming backups constantly to s3 and a full base backup every week and this with very minimal work. [https://github.com/wal-e/wal-e https://github.com/wal-e/wal-e] i actually regret not using mysql because mysql at the time supported out of the box logical replication which would make database upgrades easier. we haven't upgraded our postgres DB boxes because it would involve a lot of pain. whereas if we were using mysql we probably would just upgrade the slaves and wait for a failure.

djsumdog 10y ago

I didn't think replication was one of the issues Uber noted, but then I looked back at the blog posts: https://eng.uber.com/mysql-migration/ https://eng.uber.com/mysql-migration/ ..and yep, it's listed. In my own experience, I'd still take PostgreSQL over MySQL. MySQL doesn't allow for DDL modifications within a transaction, which makes database migration with tools like Flyway a little less resilient. On the other hand, you can use one connection for multiple databases with MySQL, MSSQL and others, which you can't with Postgres. I mean really, they all have trade-offs. It really just depends on your specific use case.

tshannon 10y ago

I believe gitlab used slony, not the native replication. I'm not well versed in postgres, but that's what I gleaned from reading their event log.

jessaustin 10y ago
The decision not to use native replication might be attributed to its purported immaturity?
detaro 10y ago
The google doc says at the bottom that slony only was used for a migration once, otherwise they use the replication features built into postgres.
YorickPeterse 10y ago
As mentioned below we only used Slony to upgrade from 9.2.something to 9.6.1. For regular replication we use PostgreSQL's streaming replication.

benmmurphy 10y ago

i chose postgres over mysql at my current job because there was an easy to use backup scripts (wal-e) available at the time and i didn't see anything comparable for mysql. so we have a hot slave and also streaming backups constantly to s3 and a full base backup every week and this with very minimal work. [https://github.com/wal-e/wal-e https://github.com/wal-e/wal-e] i actually regret not using mysql because mysql at the time supported out of the box logical replication which would make database upgrades easier. we haven't upgraded our postgres DB boxes because it would involve a lot of pain. whereas if we were using mysql we probably would just upgrade the slaves and wait for a failure.