Hacker News Reader

Comment by paulryanrogers | Hacker News Reader

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