GitHubのエンジニアが語る!MySQL5.7→8.0へのサービス無停止アップグレードの内幕 #GitHub_findy
GitHub の中では GitHub\.com (as opposed to Enterprise Server) のことは dotcom って呼んでるのかな #GitHub_findy
2024-03-21 12:11:08逆方向レプリケーションは非推奨だけど制約がわかってればできないことはない(そういえばスマートスタイルの記事がどこかにあったな)。 #GitHub_findy
2024-03-21 12:13:03規模とか用途の多様性を考えるとシフトレフトだけじゃなくてシフトライトも意識して移行を実施しないといけないけど、1つのDBを複数のサービスで共用してたりすると辛そう。 #GitHub_findy
2024-03-21 12:16:27レプリカをMySQL8.0にアップデートした後にフェイルオーバーしたと。 #GitHub_findy #GitHub_findy
2024-03-21 12:16:28レプリケーションする時に8.0にない照合順序があるとレプリケーションが停止してしまう問題、、、 #GitHub_findy
2024-03-21 12:17:41文字セット照合順のせいでレプリケーションが止まった() utf8mb4_0900_ai_aiはMySQL5.7に存在しないからと。 #GitHub_findy pic.twitter.com/OQth1e07V6
2024-03-21 12:17:56やっぱり、ロールバックするために 逆方向レプリケーションも考える必要があると、事前にアプリケーション改修するとかの準備さえ必要になるよね #GitHub_findy
2024-03-21 12:19:475.7→8.0すらそもそも大変なのに、8.0→5.7でここまでの面倒が発生すると嫌になるよな。。。 #GitHub_findy
2024-03-21 12:20:00SUPER権限の動的権限への分割は地味に効いてくる(マネージドサービス使ってると特権が制約されているから特に)。 #GitHub_findy
2024-03-21 12:21:12レプリケーション遅延も 150 msec で問題になるレベルか…でも MySQL 8.0 自体の問題じゃなかったようでよかった #GitHub_findy
2024-03-21 12:22:29MySQL5.7が20msに対し、MySQL8.0にしたら100~150msのレプリカラグが発生したと。(たぶん)Datadogのプラグインが遅延を引き起こしていた。MySQL8.0自体の問題ではなかった。 #GitHub_findy
2024-03-21 12:22:55照合順序でいうと(そろそろお役御免の)Aurora MySQL v2(MySQL 5.7互換)はサポート範囲が微妙に本家MySQL 5.7と違ってたり。 #GitHub_findy
2024-03-21 12:23:05MySQL 5.7 → 8.0 にレプリカしたらレプリカラグが 20ms → 150ms に増大した(が、実はそうではなく、Datadog プラグインの実装による誤ったメトリクスだった)? #GitHub_findy
2024-03-21 12:24:05