Live data from Hacker News

Migrating Facebook to MySQL 8.0

engineering.fb.com

231–240 of 336 posts

Re: Migrating Facebook to MySQL 8.0

#231
> MySQL, an open source database developed by Oracle

Dear Facebook:

Please fix the wording emphasized above ASAP before we revolt here in outrage with your lack of attention to detail. MySQL was developed by relevant open source project contributors (initially, MySQL AB folks), but not by Oracle and even not by Sun Microsystems. MySQL has been in development for ~12 years before Sun acquired MySQL AB. Please set the record straight.

Sincerely,

MySQL user (not currently, but in the past and maybe in the future [though unlikely, because Postgre...] :-)

Re: Migrating Facebook to MySQL 8.0

#232
post #104
post #67

Earlier quoted context omitted.

As far as I can tell, Vitess still has trouble with cross-server transactions and distributed locking. Presumably something "vastly more scalable" could work around this. The Spanner team noticeably put out https://cloud.google.com/blog/products/databases/inside-clou... a few years back, which tl;drs that they managed to get a reliable enough network that partitions don't really happen anymore and so you can get both…

Are cross-server transactions scalable? Would anyone architect a system that did them en masse unless they absolutely 100% had to? I am just speculating here but I doubt that YouTube migrated to Spanner so that they could do cross-server transactions. I would think consolidating the Ops burden into the GCP org and also serving as a trophy "customer" were higher on the list of reasons. But again, just speculating...

Yeah, Google policy was to migrate everything to Spanner, not a technical decision.

> Are cross-server transactions scalable? Would anyone architect a system that did them en masse unless they absolutely 100% had to?

As a long time Vitess user and contributor/maintainer, this perfectly describes the issue. Minimal effort has been put into solving cross shard / 2PC transactions because a well designed system rarely needs it.

Re: Migrating Facebook to MySQL 8.0

#233
post #191
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...

Still do

Re: Migrating Facebook to MySQL 8.0

#234

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

Anyone on the in-crowd who can share a bit about Oracle's motivations here? I recall a Bryan Cantrill talk about how Oracle is this completely amoral machine that just wants to make money, and how that drives their every decision [0]. Is this no longer the case? Or is it, and if so, how does improving MySQL and giving it away for free making Oracle money? Or was it always hyperbole and Oracle is improving MySQL becau…

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.

Re: Migrating Facebook to MySQL 8.0

#235
post #208

Earlier quoted context omitted.

In another subthread, you're (justifiably) unhappy with how they didn't change the strict-mode default soon enough; but here you're upset that some defaults changed too fast? Also my comment above in this subthread wasn't even about defaults. I only mentioned some features added, and you responded saying it's scary and then talking about defaults? You don't like MySQL, I get it. Regardless of reasons, I don't think y…

The purpose, mainly is to warn people of the pain I’ve suffered. My life should be a lesson here because honestly it is _painful_ to realise you have lost monetary data and have to go hat in hand to the CTO and CFO to explain why. The strict mode setting should have been the default since the beginning. It is absolutely unthinkable that it wasn’t, the only justification I can think of is that: a) it wasn’t built with…

> The strict mode setting should have been the default since the beginning.

I absolutely agree with that. But what's the point in talking about a terrible default that changed nearly 6 years ago, literally over and over again, year after year?

> the only justification I can think of

The real answer is almost certainly "backwards compatibility". Same reason many things in Windows are non-ideal, for example.

Someone made a really bad technical decision early on, but fixing it overnight will break things for an utterly massive number of paying customers, so it can't be rectified without a slow transition plan. It happens.

Yes, it absolutely should have been fixed on a faster schedule regardless, given its importance. But just because it wasn't, doesn't mean that the entirety of the piece of software is hopelessly flawed and everyone involved in its development is an utter cretin. Especially when a piece of software is multiple decades in age and has gone through multiple corporate acquisitions.

> What you’ve said just exemplifies the trend I’ve seen before: MySQL does not care about creating footguns

What I've said? What footguns? I'm asking this honestly: what are you referring to? Let's recap this subthread:

* @taywrobel said "it doesn't look like much new functionality has been introduced since 8.0.4"

* I listed a number of new features introduced in 8.0 point releases, and explained that MySQL 8 is intentionally not doing SemVer

* You said "that's pretty scary" without ever elaborating on which specific thing I said you find scary

* I disagreed, given MySQL's stated written policy of not following SemVer

* You mentioned something about defaults changing (??? this wasn't even a topic I mentioned by that point in the subthread)

Now you're talking about footguns again, but the only one you're mentioning with any specificity was fixed many years ago.

> people who have bought into the ecosystem like to exhalt that “you’re holding it wrong”

Where has anyone said anything remotely like that in this subthread? Are you referring to my statement that the user should understand what's in an upgrade before upgrading? If so, I absolutely stand by that statement; it's utterly crazy to upgrade any database without even glancing at the release notes, let alone having a basic understanding of how the database vendor handles releases and versioning. This is operational basic practices 101, not about "holding it wrong".

And for what it's worth, "people who have bought into the ecosystem" includes a massive chunk of the S&P500 using MySQL as a primary data store. If it's as deficient as you claim, why aren't all these companies going out of business?

Re: Migrating Facebook to MySQL 8.0

#236
post #200

Earlier quoted context omitted.

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…

Have you seen any of those since 5.7?

Re: Migrating Facebook to MySQL 8.0

#237
post #205

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?

The problem is that it doesn't leave you a great way to adjust order. It's just kinda weird.

(To be fair, table columns share this characteristic.)

Re: Migrating Facebook to MySQL 8.0

#238

Earlier quoted context omitted.

There is definitely stuff that is non-standard, like the casting with :: in addition to CAST AS. But it's true that PSQL sticks very closely to the standard or only adds on top of it, while MySQL is very uncomformant. Funnily enough, I actually first used Postgres over MySQL a long time ago when I moved from PHP to NodeJS, and was annoyed that MySQL uses backticks for identifiers while PSQL uses SQL standard double q…

It is practically essential for any RDBMS to provide non-standard statements and features. For example, even CREATE INDEX isn't in the SQL standard, since the SQL standard deliberately avoids talking about what it considers to be implementation details. This is probably a good goal in many ways. But what counts as an implementation detail is open to interpretation. You could say the same thing about the isolation lev…

Any “platonic ideals” mention outside its natural scope deserves attention.

Re: Migrating Facebook to MySQL 8.0

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

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…

I can see the business of open source software support coming to play as well. I went from freelance development to more of a govt contracting role and just recently pivoted my career back towards tech. I never saw this side of the business but it is thriving from where I sit.

Re: Migrating Facebook to MySQL 8.0

#240
post #205

Earlier quoted context omitted.

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

The problem is that it doesn't leave you a great way to adjust order. It's just kinda weird. (To be fair, table columns share this characteristic.)

> To be fair, table columns share this characteristic.

The table columns order is meaningless, but the triggers order is very relevant.

Post reply on HN