メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。
基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある
- MyISAMを使いたい
- 8でも動くけど諦めろ、もう未来はない
- InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが…
- InnoDB memcached Pluginとか使ってるんだよね
- 諦めろ、未来はない
- これを機にアーキテクチャを見直しましょう
- PKが無いtableがあるんだよね
- すべてのtableにまずPKを付けるんだ
- このあと、DMSを使ったりとかなにをするにしても死ぬ
- そもそもデータモデルとして死んでるのでPKはつけよう
- クエリキャッシュを使いたい
- 諦めましょう。そんなものは無い
- @mita2さんありがと！
- Oracle公式 : MySQL 5.7からMySQL 8.0へのバージョンアップ - MySQLを継続してお使いいただくために
- リリースノートを見ましょう
- 公式が必要なドキュメントは用意してくれています
- AWSの資料もオススメです
- MySQL DB エンジンのアップグレード
- 5.6 → 5.7 などの注意点もあって便利
- とみたさんがパラメータ差分わかるやつ作ってくれてる
- サイボウズの資料も良い
- MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～
- 特に具体的な事象に対する紹介があってよい
- 外部キー制約のALTERの話とか
- MySQL 8.0はマイナーバージョンで機能などに違いがあるので、利用するバージョンをよく確認する必要がある
- MySQL 8.0 の新機能
- MySQL 8.0 で追加された機能、MySQL 8.0 で非推奨となった機能、MySQL 8.0 で削除された機能はそれぞれ読みましょう
- 合わせて変更点も確認しましょう
- @taka_yuki_04さん、あざます！ 上の資料をみれば概ね基本的な対応は書いてある。 あとはテストしましょう。
- MySQL 8.0 の新機能
- 一部の機能、エラーコードが削除
- 文字セットの違い
- 8はutf8mb4
- 照合順序とかも要注意
- 照合順序、ORDER BYしても気づかないことあるので注意
- MySQL 8.0 でも
utf8mb4_general_ciを使い続けたい僕らは - MySQLはカラム単位で変えれるので
- パフォーマンスはKVSのような使い方をしていると特に下がる
- Aurora 2 → Aurora 3は20 ~ 30%程性能劣化することも珍しくない
- クソデカテーブルの
count(*)も遅くなっているのも影響を受けやすい - パラメータの差異は見逃しがち
- 旧環境でチューニングしていた内容を反映することを忘れるなど
- 例えば
open_cache_tableとかrange_optimizer_max_mem_sizeとか - どちらも5.7のときからあるパラメータだが、バージョンアップ時に新しいconfingを利用することで変更を忘れてパフォーマンスに影響を与えることがある
- 予約語とかSQLモードの違いとかによるエラーは開発環境で見つけれるはず
- テストを書きましょう
- GROUP BYや予約語は地道に直すしか無いです
時間があったら書く
MySQL 8.0 vs 外部キー制約 vs ALTER TABLEでメタデータロック待ちになったら疑うこと
これはちょいちょいある