Upgrading GitHub.com to MySQL 8.0
github.blog5–years old.
It’s interesting that the current LTS for MySQL is already 5-years old (2018).
I’m surprised there isn’t a more current LTS.
https://en.m.wikipedia.org/wiki/MySQL
Especially when you see this quoted by MySQL team:
‘About every 2 years a new Long Term Support version will be released
https://dev.mysql.com/blog-archive/introducing-mysql-innovat...Does anyone know if the performance regressions between 5.7 and 8.0 have been fixed? I no longer use MySQL regularly so I haven't been following this.
If I recall correctly, this was one of the major reasons why people were deferring this upgrade.
---
> Most notably, we encountered a problem where queries with large WHERE IN clauses would crash MySQL. We had large WHERE IN queries containing over tens of thousands of values.
The need to rewrite queries is mildly concerning. If this was part of their Rails codebase, I'm curious if these patches will make it into the ORM.
They have not been fixed, 8.0 is much hungrier for disk io for many query patterns. MariaDB is much better.
I figured this would be an opportunity for further vertical integration directly with Azure’s MySQL product.
Was there a reason this wasn’t done? The article seems rather explicit of running on top of Azure VMs.
>We also have horizontally sharded Vitess clusters for large-domain areas that outgrew the single-primary MySQL cluster.
I was thinking they could have been a planetscale customer.
I also assume they are sticking to MySQL LTS release. So their next upgrade to 8.4 will probably be next year.
Seemlessly here means actions suffered neither an increase nor decrease in the frequency of incidents
> This is the story of how we seamlessly upgraded our production fleet to MySQL 8.0.
Was it seamless? I recall GitHub being down a bunch lately, and even though the downtime is unrelated to the db upgrade, from the outside looking in, I don't know that I'd lean that hard on having done that seamlessly.
There are two possibilities:
1. The entire premise of the blogpost is completely fabricated and they are lying through their teeth.
2. The downtime was unrelated, from a product that doesn't actually have the best track record here in general.
So ... what do you think?
Thank you for using reason to fight cynicism.
or 3) Microsoft and GitHub are huge corporations where the left hand doesn't know what the right hand is doing. Writing corporate communications is hard, but it doesn't mean we shouldn't call out mistakes when they happen.
Are you genuinely trying to suggest that the people who did the migration don't know if it caused an outage or not?
I don't know how you got that from what I said.