3 ms·

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" MySQ

by hu3 2y ago

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.

paulryanrogers 2y ago
Considering several versions of 8.0 had a crashing bug if you renamed a table, waiting is probably the right choice.
- blindriver 2y ago
  You’re not renaming tables when you’re at scale.
  - abhorrence 2y ago
    Sure you do! It's how online schema changes tend to be done, e.g. https://docs.percona.com/percona-toolkit/pt-online-schema-change.html#description https://docs.percona.com/percona-toolkit/pt-online-schema-ch... describes doing an atomic rename as the last step.
    - yen223 2y ago
      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
      - sroussey 2y ago
        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.
      - paulryanrogers 2y ago
        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.
        blindriver 2y ago
        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.
        paulryanrogers 2y ago
        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.

by hu3 2y ago

paulryanrogers 2y ago

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

blindriver 2y ago
You’re not renaming tables when you’re at scale.
- abhorrence 2y ago
  Sure you do! It's how online schema changes tend to be done, e.g. https://docs.percona.com/percona-toolkit/pt-online-schema-change.html#description https://docs.percona.com/percona-toolkit/pt-online-schema-ch... describes doing an atomic rename as the last step.
  - yen223 2y ago
    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
    - sroussey 2y ago
      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.
    - paulryanrogers 2y ago
      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.
      - blindriver 2y ago
        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.
        paulryanrogers 2y ago
        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.