4 ms·

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 rep

by 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.

by harel 10y ago

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.