←back to thread

Upgrading Uber's MySQL Fleet

(www.uber.com)
234 points benocodes | 1 comments | 14 Oct 24 12:08 UTC | HN request time: 0.206s | source
Show context
tiffanyh ◴[14 Oct 24 12:36 UTC] No.41836942[source]▶
Why upgrade to v8.0 (old LTS) and not v8.4 (current LTS)?

Especially given that end-of-support is only 18-months from now (April 2026) … when end-of-support of v5.7 is what drive them to upgrade in the first place.

https://en.m.wikipedia.org/wiki/MySQL

replies(8): >>41836953 #>>41837025 #>>41837032 #>>41837038 #>>41837071 #>>41837144 #>>41837234 #>>41837295 #
pizza234 ◴[14 Oct 24 12:53 UTC] No.41837071[source]▶
I suppose they opted for a conservative upgrade policy, as v8.4 probably includes all the functional additions/changes of the previous v8.1+ versions, and moving to it would have been a very big step.

MySQL is very unstable software - hopefully this will be past - and it's very reasonable to go for the smallest upgrade steps possible.

replies(1): >>41839526 #
hu3 ◴[14 Oct 24 17:09 UTC] No.41839526[source]▶
> MySQL is very unstable software

I've worked on 20+ projects using MySQL in consulting career. Not once stability was a concern. Banking clients would even routinely shut down radom MySQL nodes in production to ensure things continued running smoothly.

As I'm sure users like Uber and Youtube would agree. And these too: https://mysql.com/customers

Unless you know something we don't and we're just lucky.

replies(2): >>41844474 #>>41879132 #
1. pizza234 ◴[18 Oct 24 13:12 UTC] No.41879132[source]▶
I've used MySQL for almost 15 years, and reported dozens of bugs, a few of which were critical security issues.

My definition of "very unstable" has been very vague, so I'll clarify.

MySQL is stable software if a company uses a subset of features - the core ones, stable for a long time. Anything outside of that area, and either a company has very considerable engineering resources (that is, being able to work on the MySQL source, indeed like Uber, Google or Facebook), or it's suicide.

For starters, the MySQL development model has a habit of abandoning functionalities while not officially deprecating them, leaving them buggy.

MyISAM for example has been abandoned long ago, but not officially. Around 10/12 years ago, while it was still somewhat used, we experienced a bug where the tables were marked as crashed on clean shutdowns. Very nasty because it caused long recovery times on startup.

InnoDB fulltext indexes are the same. They have a broken workflow (they require maintenance, but some required maintenance functionalities are missing), and clearly MySQL has abandoned them, but not officially deprecated.

New functionalities have typically nasty bugs. The critical bugs I've mentioned were on simple operations related to relatively new, but not widespread, functionalities (MVIs, regular expressions, InnoDB FTIs, I think JSON, and can't remember the other(s)).

Worse, MySQL 8.0 has been a complete trainwreck, because the product managers decided to develop features/changes in patch versions, continuosly introducing breakages. So, maybe a functionality that has finally been stable for an year or more, suddenly breaks (in production, of course).

Heck, even something as simple as 'SHOW TRIGGERS' is currently buggy, just because triggers are not common in the userbase.

Given the domain you've mentioned (banking) you've probably been working with a conservative set of functionalities - which absolutely makes sense, but calling MySQL stable depends on whether one considers MySQL a small set of functionalities, or the whole set of them.