Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

Post reply on HN
Print view View original

191–200 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#191

Post by fowl2 »

ksec wrote: post #6

MySQL 5.6 was released on 5 February 2013 . MySQL 8.0 was released on 19 April 2018 . >The 8.0 migration has taken a few years so far. We have converted many of our InnoDB replica sets to running entirely on 8.0. At the scale of Facebook I wonder if they are the largest MySQL user on the planet. And I take this opportunity to ask, does anyone know how does the MySQL roadmap works? What sort of features are coming or…

GitHub also seems to use MySql, as recently as 2020[1]

[1] https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-dr...

Re: Migrating Facebook to MySQL 8.0

#192

Post by midom »

gigatexal wrote: post #146

Where can I read more about the custom things FB added to MySQL 5.6? Their work on replication and the DDL work seems fascinating. Are there scholarly papers, white-papers, blogs? Are they storing the friend graph in MySQL?

there's also this team page, although it has been somewhat lower on volume lately - https://www.facebook.com/MySQLatFacebook/

Re: Migrating Facebook to MySQL 8.0

#193

Post by quesera »

fredliu wrote: post #157
johannes1234321 wrote: post #138

Earlier quoted context omitted.

MySQL always was primarily developed by an commercial entity. And always gave an license out under GPL (i believe very first used some other license as GPL wasn't known back then ...) Oracle took over the development team (lots of pre-acquisition staff included) and legal rights to all of that. (Disclaimer: I started at independent MySQL AB more than ten years ago and now wear an Oracle badge, after wearing Sun for a…

Maybe it's legal talk that I don't understand, but the fact that Oracle owns the majority of the dev team today , doesn't mean Oracle developed MySQL. Because at the time MySQL was "developed", Oracle didn't own MySQL, nor did Oracle "own" the developers.

"Developed" is not used in the past tense here.

Think "Currently developed by Oracle".

Re: Migrating Facebook to MySQL 8.0

#194

Post by dijit »

paulddraper wrote: post #190
twic wrote: post #124

Earlier quoted context omitted.

> I absolutely adore Postgres's tweaks to the SQL language Do you mean additions to the SQL standard, or bits of the standard that MySQL doesn't implement, or something else? The reason i ask is that i also enjoy writing SQL for PostgreSQL, but as far as i know, i am sticking to standard SQL. Perhaps there are things i'm missing, or things i like which i haven't realised are nonstandard!

> as far as i know, i am sticking to standard SQL PostgreSQL documentation is very good about comparing each feature to the standard. For example, the SQL standard specifies that triggers fire in the historical order they are added to the table. PostgreSQL chose to fire them alphabetically. Technically nonconformant, but in practical terms, far better.

Also the c++ bindings are very mature.

This was surprising for my old tech lead who was sheepish on moving away from MySQL.

He would later refer to the MySQL bindings as “brain dead”

Re: Migrating Facebook to MySQL 8.0

#195

Post by School-Cotton »

taywrobel wrote: post #129
fipar wrote: post #122

Earlier quoted context omitted.

There have been several minor releases in the past 3 years: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/

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.

Re: Migrating Facebook to MySQL 8.0

#196

Post by merlinscholz »

ksec wrote: post #6

MySQL 5.6 was released on 5 February 2013 . MySQL 8.0 was released on 19 April 2018 . >The 8.0 migration has taken a few years so far. We have converted many of our InnoDB replica sets to running entirely on 8.0. At the scale of Facebook I wonder if they are the largest MySQL user on the planet. And I take this opportunity to ask, does anyone know how does the MySQL roadmap works? What sort of features are coming or…

The NSA also uses MySQL for their project XKEYSTORE (digital surveillance)

Re: Migrating Facebook to MySQL 8.0

#197

Post by dijit »

tapoxi wrote: post #116
munk-a wrote: post #96

Earlier quoted context omitted.

I carried out a (quite ill-advised in retrospect) migration from MySQL to Postgres on a mature codebase with absolutely no automated test coverage and it went pretty smoothly. We had some bumpy performance directly after the production migration but we were able to reach parity after about two months of observing and adding targeted indices. I absolutely adore Postgres's tweaks to the SQL language, that dialect is am…

We also did a MySQL 5.7 to PG 9.6 migration (thanks to https://pgloader.io/ ) and we got some pretty immediate speed improvements (2-5x). We shot ourselves in the foot a few weeks later with some poorly written RLS policies, but it was overall a smooth experience.

pgloader is great.

Sadly for me when I tried to make a PoC of Postgres for our eCommerce platform I found that we had violated our constraints and lost data.

That was the day I went from MySQL agnostic to MySQL hating.

It largely doesn’t matter that the defaults could be configured to be more strict. We live in a world where people are trying to avoid hiring sysadmin and that database was set up by a developer. It should not have been a default.

Re: Migrating Facebook to MySQL 8.0

#198

Post by dijit »

evanelias wrote: post #145
taywrobel wrote: post #129

Earlier 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…

Many major new features have been introduced in 8.0 point releases. Some examples: * 8.0.12 added INSTANT algorithm for adding new columns to a table * 8.0.13 added DEFAULT expressions (column default values may now be any arbitrary expression, not just a constant) * 8.0.16 added CHECK constraints * 8.0.17 added the CLONE plugin for rapid physical copying of a db * 8.0.23 added INVISIBLE columns (excluded from SELECT…

That’s pretty scary, isn’t it?

Re: Migrating Facebook to MySQL 8.0

#199

Post by evanelias »

dijit wrote: post #198
evanelias wrote: post #145

Earlier quoted context omitted.

Many major new features have been introduced in 8.0 point releases. Some examples: * 8.0.12 added INSTANT algorithm for adding new columns to a table * 8.0.13 added DEFAULT expressions (column default values may now be any arbitrary expression, not just a constant) * 8.0.16 added CHECK constraints * 8.0.17 added the CLONE plugin for rapid physical copying of a db * 8.0.23 added INVISIBLE columns (excluded from SELECT…

That’s pretty scary, isn’t it?

No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer?

SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.

Re: Migrating Facebook to MySQL 8.0

#200

Post by dijit »

hodgesrm wrote: post #127
suyash wrote: post #88

Go MySQL - solid open source database rocking for the last almost 3 decades!

Well...I love MySQL but there was a time when it was anything but rock solid. It was pretty painful until InnoDB replaced MyISAM in 2010 as the default storage engine. After that it became rare to lose data.

Except in cases where the constraints may be violated and it just inserts the next nearest thing.

Or the times where the transaction isolation just abruptly ends and commits your transaction midway; leaving no chance of a rollback.

Or when you alter a column to a new type and the cast doesn’t work in a few cases and just leaves corrupted garbage on every row.

Or when the replication misses a few transactions and your replica now looks different to your primary.

(These aren’t hypothetical, these are things I’ve seen)

Post reply on HN