Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by hu3 | Hacker News Reader

Parent Full thread

hu3·

The upgrade initiative started somewhere in 2023 according to the article.

MySQL 8.4 was released in April 30, 2024.

Their criteria for a "battle tested" MySQL version is probably much more rigorous than the average CRUD shop.

View on HN

Considering several versions of 8.0 had a crashing bug if you renamed a table, waiting is probably the right choice.

You’re not renaming tables when you’re at scale.

Sure you do! It's how online schema changes tend to be done, e.g. https://docs.percona.com/percona-toolkit/pt-online-schema-ch... describes doing an atomic rename as the last step.

You aren't renaming tables at scale because there are 27 downstream services that will break if you even think about fixing the name of the revnue_dolars table, and it's not in anyone's OKR to fix it

I’m not sure if this is a joke (ref to OKR was funny, for example), or just naive and not understanding the parent comment. I found it funny either way though.

Take a closer look at how some min downtime tools work. They often use a drop-swap strategy to replace an old table name with a new one that has schema changes.

There are sometimes temporary views to keep the old and new code working during gradual transitions.

You clearly have not worked at global companies with concerns that go beyond “can I do it?”. I’ve used percona and I’ve used these tools before and percona is great. But when you’re at scale something as trivial as a table name change is not something you ever do because it’s not worth the risk of taking your entire site down. Just use the existing name no matter how bad it is.

Are we talking about the same Pt-online-ddl-change?

It certainly has a drop-swap approach which does a table rename, even though the resulting table ends up with the same name as before.

That's how I encountered the MySQL table-rename-crash bug.

Reply on news.ycombinator.com