Skip to content

Instantly share code, notes, and snippets.

@soudai
Last active June 12, 2024 03:47
Show Gist options
  • Save soudai/fde4dcc8cfa8f9b3c902315d11720af8 to your computer and use it in GitHub Desktop.
Save soudai/fde4dcc8cfa8f9b3c902315d11720af8 to your computer and use it in GitHub Desktop.
MySQL 5.7 to 8 check list

確認すること

メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。

基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある

最初に諦めること

  • MyISAMを使いたい
    • 8でも動くけど諦めろ、もう未来はない
    • InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが…
  • InnoDB memcached Pluginとか使ってるんだよね
    • 諦めろ、未来はない
    • これを機にアーキテクチャを見直しましょう
  • PKが無いtableがあるんだよね
    • すべてのtableにまずPKを付けるんだ
    • このあと、DMSを使ったりとかなにをするにしても死ぬ
    • そもそもデータモデルとして死んでるのでPKはつけよう
  • クエリキャッシュを使いたい

見ると良い

破壊的変更

注意点

  • 文字セットの違い
  • パフォーマンスはKVSのような使い方をしていると特に下がる
  • Aurora 2 → Aurora 3は20 ~ 30%程性能劣化することも珍しくない
  • クソデカテーブルの count(*) も遅くなっているのも影響を受けやすい
  • パラメータの差異は見逃しがち
    • 旧環境でチューニングしていた内容を反映することを忘れるなど
    • 例えば open_cache_table とか range_optimizer_max_mem_size とか
    • どちらも5.7のときからあるパラメータだが、バージョンアップ時に新しいconfingを利用することで変更を忘れてパフォーマンスに影響を与えることがある
  • 予約語とかSQLモードの違いとかによるエラーは開発環境で見つけれるはず
    • テストを書きましょう
    • GROUP BYや予約語は地道に直すしか無いです

準備としてやると良いこと

時間があったら書く

@soudai
Copy link
Author

soudai commented Nov 14, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment