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

261–270 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#261

Post by kevinventullo »

pbreit wrote: post #245
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…

Any idea what Facebooks stores in MySQL? Core user database?

To a first approximation, everything.

Most product engineers interact with it by querying TAO, which you can read about in various blog posts, but is basically a cache in front of MySQL (this is a vast oversimplification).

Re: Migrating Facebook to MySQL 8.0

#262

Post by throwdbaaway »

evanelias wrote: post #199
dijit wrote: post #198

Earlier quoted context omitted.

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.

It is pretty scary because most of these new features or enhancements are buggy. By not adopting SemVer, users of MySQL who prefer stability (oxymoron?) have no obvious upgrade path. They could be happily using version 8.0.123, and then upgrade to version 8.0.126 to get some security fix, and suddenly encounter a bunch of functionality and/or performance regressions.

Some examples...

WL#10310 Redo log optimization:

Feb 2018, initial commit 6be2fa0bdbba, landed in 8.0.11 (Apr 2018)

Jun 2018, crash regression fix commit 270d18368650, landed in 8.0.13 (Oct 2018)

Apr 2019, performance regression fix commit 75c4f7161a56, landed in 8.0.18 (Oct 2019)

WL#5655 - InnoDB: Separate doublewrite file to ensure atomic writes:

Dec 2019, initial commit ce14ef911, landed in 8.0.20 (Apr 2020)

Feb 2020, data loss regression fix commit c1bc61dc7, landed in 8.0.20 (Apr 2020)

May 2020, stall regression fix commit 00b284707, landed in 8.0.21 (Jul 2020)

In comparison, Cassandra during the DataStax days was extremely buggy, but at least it tried to follow SemVer. So the operators can follow some simple guideline, e.g. >=2.0.14 is fine, >=2.1.17 is fine, >=2.2.9 is fine. Of course regression can still happen, but that would be an exceptional case.

Re: Migrating Facebook to MySQL 8.0

#263

Post by wikibob »

jjnoakes wrote: post #93
buro9 wrote: post #84

Earlier quoted context omitted.

gresrun works at YouTube, if by reference you mean citation then his comment is it.

wikibob was probably looking more for public documentation about the why and how rather than confirmation that the statement is true.

Yep, I love watching conference talks or reading Twitter threads, papers, etc about these kind of migrations.

Re: Migrating Facebook to MySQL 8.0

#264

Post by throwaway2037 »

ipaddr wrote: post #205
paulddraper wrote: post #190

Earlier quoted context omitted.

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

Why would alphabetically be better? Wouldn't you want first in first out?

Why was this down-voted? It is a good question. I thought exactly the same myself. And the reply from @setr is helpful. (Hat tip) I never thought about the impact of dump/restore!

Re: Migrating Facebook to MySQL 8.0

#265

Post by anarazel »

evanelias wrote: post #259
thayne wrote: post #250

Earlier quoted context omitted.

> Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl

In practice, this is rarely a problem unless you're a cloud vendor with a DBaaS product; the most common concern there tends to be bugs that cause server crashes. But even that is fairly rare, and those platforms (AWS, GCP, Azure, Alibaba, etc) generally maintain custom patch sets anyway. As far as I can recall, the vast majority of modern MySQL CVEs have been low severity and/or require the attacker to already be in…

> For sake of comparison -- does Postgres backport every security patch to every major.minor tree?

Unless the security fix in question is not applicable to some branch, yes.

https://www.postgresql.org/support/security/ https://www.postgresql.org/support/versioning/

Re: Migrating Facebook to MySQL 8.0

#266

Post by mathnode »

takeda wrote: post #61

Perhaps it's due to me being in the PostgreSQL camp, but what happened to MariaDB? I was convinced that's where MySQL developers went and that's where development proceeded, while MySQL was just half dead, because Oracle did not care about it.

MariaDB is massive now.

mysql and MariaDB diverged from versions 5.6 and 10 respectively, although MariaDB can and does still merge some fixes from mysql; oracle don’t do that.

MariaDB and the original InnoDB developers are now doing heavy rewrites with big performance gains, replication options like multi-source, spider for sharding and galera are all built in and actively maintained.

Oracle attempted to extort anyone trying to licence a mysql based product(rip infobright), so infinidb and clustrix, now respectively called columnstore and xpand, have new homes with MariaDB and are core parts of the system. Online schema changes, easy horizontal scale (huge numbers that make db2 and oracle sweat), s3 backed tables, non blocking backups, flashback, versioned tables.

The list goes on, and many industry veterans from ibm, oracle, sybase etc are finding a home there and helping MariaDB grow.

There are new public developer resources and the connectors are feature rich and well loved. There have been a few free online conferences during the pandemic, and MariaDB now has its own place at fosdem not just bundled in with mysql.

If you go enterprise, there isn’t much out there as accessible as maxscale for transaction failover!

Re: Migrating Facebook to MySQL 8.0

#267

Post by pjmlp »

radicalbyte wrote: post #260
pjmlp wrote: post #256

Earlier quoted context omitted.

> Experimenting on or converting small projects into new markets? Bringing MaximeVM out of research labs into the market as GraalVM. First RDMS to support Perl and Java as stored procedures. Join venture with Sun for Network Computer thin clients. > Fleshing out OpenSolaris into a product that could rival linux? Every OpenSolaris sales is one sale less from Unbreakable Linux, so in a day and age where UNIX === Linux,…

FANG would buy them if they had somehow managed to stumble forward to the mid-2010s.

Zero offers from any of them, so.

Re: Migrating Facebook to MySQL 8.0

#268

Post by gigatexal »

midom wrote: post #192
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/

I've not got a FB account due to reservations about FB and their business model but that doesn't mean I am above learning from what they do, thanks for the link, I'll have to find info elsewhere though.

Re: Migrating Facebook to MySQL 8.0

#269

Post by ipaddr »

setr wrote: post #254
ipaddr wrote: post #205

Earlier quoted context omitted.

Why would alphabetically be better? Wouldn't you want first in first out?

Alphabetical makes it so two databases with the same triggers have the same behavior. FIFO breaks that, because now it depends on trigger construction order (eg when dump/restoring) and is totally invisible to the user. Additionally, modifying a trigger by drop/creating it would change behavior, unless you also drop/create every trigger (in the original order)

Thank you most important thing I learned today.

Re: Migrating Facebook to MySQL 8.0

#270

Post by kaba0 »

tonyedgecombe wrote: post #257
truffdog wrote: post #234

Earlier quoted context omitted.

Mr. Cantrill might be engaging in hyperbole. Big companies are big though- lots of people in charge of lots of things, and often they wander off in different directions. It doesn't make sense to model their behavior as if directed by a single hive mind.

Companies do have a culture though, the reason Amazon warehouse employees have to piss in a bottle can be traced back to Bezos and his laser like focus on controlling costs.

Big enough companies are the stereotypical paper clip AIs everyone fear, but with money. Anything seemingly moral action by them is simply a cost-analysis on how the public opinion will effect their profits.
Post reply on HN