What I take away from this is that they are (or were, until recently) still running production systems on MySQL 5.6...
There are production systems that run on 30+ years old software. Upgrade for a sake of upgrade is often a wrong decision.
Migrating Facebook to MySQL 8.0
211–220 of 336 posts
Re: Migrating Facebook to MySQL 8.0
#212Earlier quoted context omitted.
I always see people asking about this. But why? Are you making schema changes that frequently?
It's my opinion that schema changes should be cheap, fast and unexciting. Unfortunately, in my experience once you are operating at scale they are expensive, slow and fraught with peril. The result is that engineering teams often chose to build poorly designed schemas and take on technical debt rather than make a schema change to a core table. This is a terrible anti-pattern! I'm massively in favour of anything that…
https://www.planetscale.com/blog/non-blocking-schema-changes
disclaimer: I work at PlanetScale
Re: Migrating Facebook to MySQL 8.0
#213can it do DDL commands in a transaction yet?
[deleted]
Re: Migrating Facebook to MySQL 8.0
#214Earlier quoted context omitted.
I'm no fan of oracle's audit approach but it sounds like you were expecting special leniency to not pay for their stuff - for decades - because you are a govt agency/ live in a low income place. Not how business works. If you're playing by the rules, no one can force you into any long term contracts you don't need.
I'm also a government Oracle dev. I have no way of knowing what I'm licensed for and they don't disable the features we're not licensed for. I literally have to talk to my director to talk to our account rep to figure out that I'm not allowed to use table partitioning.
portions of Salesforce are the same way. You don't know you're out of compliance until an audit happens and you get the "sure would be a shame if something happened to your instance..." speech.
Re: Migrating Facebook to MySQL 8.0
#215Re: Migrating Facebook to MySQL 8.0
#216Really well done article. In-xeptjh treatment of a problem that few will actually tackle - a migration at Facebook's MySQL scale.
Would be really good to see how long the project took and the migration speed they achieved.
Re: Migrating Facebook to MySQL 8.0
#217Re: Migrating Facebook to MySQL 8.0
#218Earlier quoted context omitted.
In semantic versioning parlance those would all be considered "patch" releases, not a "minor" release. The minor version segment in a semantic version is the 2nd number, so most people would consider the next "minor release" for MySQL to be 8.1.0. If following the guidance set out at https://semver.org , a patch release wouldn't add any new functionality, it would just address bugs in a backwards compatible way. A mi…
SemVer is a relatively recent proposal that the vast majority of software does not follow. Calling the three parts of a three-part version “major”, “minor” and “patch” is a SemVer thing, not a universal standard.
Worth calling out here that SemVer has been around for a decade now, so "recent" is relative
Re: Migrating Facebook to MySQL 8.0
#219> MySQL, an open source database developed by Oracle
This makes it sound like Oracle created it, when it fact the reality is the opposite: Oracle fought it, and bought Sun just so they could get their hands on MySQL. How did regulators let that happen is beyond me.
Re: Migrating Facebook to MySQL 8.0
#220Earlier quoted context omitted.
That was the expectation but the Oracle camp surprised everyone by actually giving it some attention, and meanwhile MariaDB's promise of being a "100% compatible drop-in replacement" came with more and more caveats with each release (as is to be entirely expected with any fork). When you consider the network effect of all the stacks already heavily invested in MySQL, all Oracle really needed to do was put in a modicu…
> meanwhile MariaDB's promise of being a "100% compatible drop-in replacement" came with more and more caveats with each release Anecdata: I've been using mariadb as a drop in mysql replacement for over 5 years in production, and it's been working seamlessly. I'm no DB expert, and perhaps my use case isn't complex enough or written in a highly mysql dependent way - but I felt like someone should chime in since there'…
I have a lot of stored procedures and functions that were converted from Oracle to MySQL, and they also work just fine in MariaDB.
I guess any actual incompatibility is in fringe cutting edge features, which is where both databases have diverged.