5 ms·

Experience with Mysql replication (even simple master/slave) leads me to believe Uber is going to have some rather nasty surprises at some point.

by mml 10y ago

bogomipz 10y ago
Could you elaborate?
- harel 10y ago
  You can read it in their next blog post: "How we migrated back to PostgreSql from mySql after migrating from PostgreSql to mySql". My experience with mySql replication was OK, but I did nothing fancy - just master/slave standard stuff. However the database itself was allowing you to do stuff by default (at the time at least) that is really bad. Not to mention scaling while I was using it was pretty much "you're on your own buddy" kind of deal. Today I'm scared to touch mySql because I don't trust Oracle. I use MariaDB on an old project which used mySql but anything new is postgres.
  - oneweekwonder 10y ago
    Personally I prefer Postgres. But at the shop we use MySQL. One of the leads personally believe in Percona Server[0] and mentions some of the old mysql folks work there. I like their docs and the idea of a more tuned mysql config. [0]: https://www.percona.com/doc/percona-server/5.7/index.html https://www.percona.com/doc/percona-server/5.7/index.html
    - rpcope1 10y ago
      I can second using Percona; I wasn't much of a believer in MySQL until I inherited a medium sized application using Percona 5.7. Once you get past a few of the initial warts (like making sure the database doesn't silently truncate your data--yuck), it's been really performant, stable and impressive (and we're running a setup with a fairly complex schema with master operating at ~3000 QPS average, a slave actively replicating for read load balancing and backup, and Sphinx for FTS). Knowing what to be careful with on MySQL, I would certainly consider using the Percona flavor again in a new application.
      - noir_lord 10y ago
        I hit an in production bug with the silent truncation field thing the other day, old system (2009ish) that was been moved. Table had a field that was varchar(128) and wasn't used (original filename but system generated a hashed filename and served it with that name (for sharding, lots of files)) so for 5 years MySQL had been silently killing everything > 128 characters and it didn't matter. Then along comes our hero (me in this story) who does all the upgrades, tests everything thoroughly (he thought) and it's all fine, deploy, test everything fine. Next morning, 9 bug reports "Can't upload files at all FIXITNOW!!!". Turns out company was auto generating PDF's from some report software that dumped all the data into the filename and none of them where less than 128 chars. MySQL 5.7 started not silently dumping data into the bitbucket in the sky and instead threw an error (when quite reasonably you tried to shove 300 characters into a varchar(128)). TLDR: MySQL doing the right thing broke the broken.
darkr 10y ago
MySQL has had solid and flexible replication options for a long time. Postgres has only just started to catch up in the last couple of years. Don't get me wrong, I would generally choose Postgres over MySQL for an RDBMS with replication requirements these days, but I'm not sure I would have made that same descion a few years ago. There are valid reasons that long established companies such as Google, Twitter, Facebook and countless others chose MySQL as their primary data store.
- dijit 10y ago
  it's not that "replication options just started to catch on" with postgresql, it was that when the postgresql team take something into core it has to be fully fleshed out and fully supported with no surprises. And with that in mind, I would take the slow to deliver replication options postgresql supplies in base over the previous third-party options which where comparable to the built-in options in mysql... and I'd take it over mysql's built-in options. and I've used both postgresql and mysql in highly transactional/reliable production environments for over 5 years.
- dunk010 10y ago
  > There are valid reasons that long established companies such as Google, Twitter, Facebook and countless others chose MySQL as their primary data store. I think you're misrepresenting things here. While all do use MySQL for some specific tasks, it's clear that all also have many other central datastores which are not MySQL. In Google's case this is a gross overstatement.
  - spotman 10y ago
    Not really, YouTube runs on MySQL. Pretty sure it's still the largest video site in the world.
    - mdani 10y ago
      YouTube runs several MySQL instances behind Vitess (source: http://blog.vitess.io/2015/03/scaling-mysql-in-cloud-with-vitess-and.html http://blog.vitess.io/2015/03/scaling-mysql-in-cloud-with-vi... )
mrmondo 10y ago
Heh, yes came here to say something rather similar...

Experience with Mysql replication (even simple master/slave) leads me to believe Uber is going to have some rather nasty surprises at some point.

by mml 10y ago

Experience with Mysql replication (even simple master/slave) leads me to believe Uber is going to have some rather nasty surprises at some point.

bogomipz 10y ago

Could you elaborate?

harel 10y ago
You can read it in their next blog post: "How we migrated back to PostgreSql from mySql after migrating from PostgreSql to mySql". My experience with mySql replication was OK, but I did nothing fancy - just master/slave standard stuff. However the database itself was allowing you to do stuff by default (at the time at least) that is really bad. Not to mention scaling while I was using it was pretty much "you're on your own buddy" kind of deal. Today I'm scared to touch mySql because I don't trust Oracle. I use MariaDB on an old project which used mySql but anything new is postgres.
- oneweekwonder 10y ago
  Personally I prefer Postgres. But at the shop we use MySQL. One of the leads personally believe in Percona Server[0] and mentions some of the old mysql folks work there. I like their docs and the idea of a more tuned mysql config. [0]: https://www.percona.com/doc/percona-server/5.7/index.html https://www.percona.com/doc/percona-server/5.7/index.html
  - rpcope1 10y ago
    I can second using Percona; I wasn't much of a believer in MySQL until I inherited a medium sized application using Percona 5.7. Once you get past a few of the initial warts (like making sure the database doesn't silently truncate your data--yuck), it's been really performant, stable and impressive (and we're running a setup with a fairly complex schema with master operating at ~3000 QPS average, a slave actively replicating for read load balancing and backup, and Sphinx for FTS). Knowing what to be careful with on MySQL, I would certainly consider using the Percona flavor again in a new application.
    - noir_lord 10y ago
      I hit an in production bug with the silent truncation field thing the other day, old system (2009ish) that was been moved. Table had a field that was varchar(128) and wasn't used (original filename but system generated a hashed filename and served it with that name (for sharding, lots of files)) so for 5 years MySQL had been silently killing everything > 128 characters and it didn't matter. Then along comes our hero (me in this story) who does all the upgrades, tests everything thoroughly (he thought) and it's all fine, deploy, test everything fine. Next morning, 9 bug reports "Can't upload files at all FIXITNOW!!!". Turns out company was auto generating PDF's from some report software that dumped all the data into the filename and none of them where less than 128 chars. MySQL 5.7 started not silently dumping data into the bitbucket in the sky and instead threw an error (when quite reasonably you tried to shove 300 characters into a varchar(128)). TLDR: MySQL doing the right thing broke the broken.

darkr 10y ago

MySQL has had solid and flexible replication options for a long time. Postgres has only just started to catch up in the last couple of years. Don't get me wrong, I would generally choose Postgres over MySQL for an RDBMS with replication requirements these days, but I'm not sure I would have made that same descion a few years ago. There are valid reasons that long established companies such as Google, Twitter, Facebook and countless others chose MySQL as their primary data store.

dijit 10y ago
it's not that "replication options just started to catch on" with postgresql, it was that when the postgresql team take something into core it has to be fully fleshed out and fully supported with no surprises. And with that in mind, I would take the slow to deliver replication options postgresql supplies in base over the previous third-party options which where comparable to the built-in options in mysql... and I'd take it over mysql's built-in options. and I've used both postgresql and mysql in highly transactional/reliable production environments for over 5 years.
dunk010 10y ago
> There are valid reasons that long established companies such as Google, Twitter, Facebook and countless others chose MySQL as their primary data store. I think you're misrepresenting things here. While all do use MySQL for some specific tasks, it's clear that all also have many other central datastores which are not MySQL. In Google's case this is a gross overstatement.
- spotman 10y ago
  Not really, YouTube runs on MySQL. Pretty sure it's still the largest video site in the world.
  - mdani 10y ago
    YouTube runs several MySQL instances behind Vitess (source: http://blog.vitess.io/2015/03/scaling-mysql-in-cloud-with-vitess-and.html http://blog.vitess.io/2015/03/scaling-mysql-in-cloud-with-vi... )

mrmondo 10y ago

Heh, yes came here to say something rather similar...