2025年になってもまだMySQLが好き

2025/09/06 大吉祥寺.pm 2025
https://kichijojipm.connpass.com/event/361631/

Transcript

1. 2025年になってもまだMySQLが好き この道一筋13年ちょい 2025/09/06 yoku0825
2. おはようござ います 1/53
3. 千葉.pmの方 から来ました 2/53
4. 千葉.pmのMは MySQLのM！ 3/53
5. ※諸説あり ます 4/53
6. ＼おはようございます／ yoku0825＠とある企業のDBAだったもの オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitterだったもの: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ‐ MySQL Casual ‐ 5/53
7. 諸君、私は MySQLが好きだ 6/53
8. 諸君、私は MySQLが大好き だ 7/53
9. MySQLひとすじ13年 MySQLのサードパーティーサポートと商用版代理店 MySQLユーザー企業のDBAその1 MySQLユーザー企業のDBAその2 5月から現職 8/53
10. Why MySQL? MySQLは大きなブラックボックスアプリケーション SQLより下側は隠蔽されている（ことになっている） 実際は全然隠れてないあたりがかわいい ‐ 良くも悪くも素直 自分で考えても実行戦略が読めないようなのは遅い 自分で考えて遅そうな実行戦略になるのは遅い これなら速く終わるだろってやつは速い レプリケーションが壊れた時の原因は大体一瞬で想像がつく ‐ オンラインであることにこだわっている（それが正しいかどうかは置いておいて） ALTER TABLE中も読み書きさせたい 何ならバッファプールの再構成もオンラインでさせてあげたい テンポラリテーブルのDisk落ちもテンポラリテーブルの再構成なく継続させたい (8.0の一部期間のみ…) ただし運用のツケは自分で払わされる ‐ レプリケーションを使えば可能性は無限大 インデックスの追加も、カラムの追加も上手くやれば(カラムの先行追加は功夫が必要)レプリカ先行させてフェイルオーバーで済ませられ る バックアップの取得も、バージョンアップも、レプリカからなら気軽にいける ただし非同期レプリケーションの自動フェイルオーバーは無茶苦茶難しい ‐ 9/53
11. Why MySQL? RDBの面白さは、さまざまなジレンマやトレードオフを内包している点だと思っています。データ の不整合を起こさず、一度コミットしたデータは絶対に失えない。でもパフォーマンスは上げたい 。この二つを両立するために、多くのデータベースではトランザクションの分離レベルを少し緩め るなどの工夫をしています。 わかります。インデックスなんてまさにそうですよね。検索速度を上げるために、わざわざデータ を複製してソートしなおしている。なぜ自らデータ量を増やすんだ……という、あのあたりの自己 矛盾が、なんだかかわいくも見えます（笑）。 https://sakumaga.sakura.ad.jp/entry/otsukatomoaki/ 10/53
12. Why MySQL? 個人的にはダメな子だから好きになったわけじゃない たまたま好きになった子がバカだっただけ まあ好きになっちゃったんだからしょうがないよね それでも俺は8.0のことは許してないぞ ‐ 11/53
13. とある企業のDBAではないもの 12/53
14. ユーザー企業のDBA 自分たち(法人)のマシン 自分たち(法人)のデータ 自分たち(法人)の運用 DBAに対応する「ユーザー」は同じ会社の同僚たち ‐ 13/53
15. とある企業のDBAではないもの お客様のマシン お客様のデータ 自分たちの運用と、お客様の運用は別物 責任分界点の内側の運用は我々 ‐ 責任分界点の外側の運用はお客様 ‐ 14/53
16. 自前の監視 CPU使用率, Memory使用率, Swap使用率, Disk使用率 スローログの数, クエリ実行時間, レプリケーション遅延, デッドロック検出, エラーログ転送, Too many connections, Threads_Running, AUTO_INCREMENT, Uptime, .. yt-healthcheck ‐ テーブルごとの1か月にフェッチされた行の総数の変化, クエリタイプごとの1か月でのレイテンシの変 化, テーブルごとの行の総数の変化, .. yt-collect ‐ 15/53
17. 自分たちのMySQL DBAと開発者でロールが分かれている場合に 開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした 方が早い ‐ MySQL側でしか気が付けないものはある レプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなの か」はわからない ‐ 必ず何らかの操作が必要なものはある レプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 16/53
18. 自分たちのMySQL DBAと開発者でロールが分かれている場合に 開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当 に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした 方が早い ‐ MySQL側でしか気が付けないものはある レプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなの か」はわからない ‐ 必ず何らかの操作が必要なものはある レプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 17/53
19. アプリケーション監視の進化 アプリケーションログの集約が一般化 トレーシングも随分普及してきた 何かエラーが起こったりレスポンスが悪くなったりした時はMySQL側で監視するよりもよっぽどノイズ も少なく検知できるケースが多い MySQL側では正常動作（たとえばロック競合でクエリを待たせるのはMySQL側では当然の正常系動作）で も影響が出ているようなケースの検出は当然正確 ‐ というよりはDBAが進化をサボっている可能性もある 18/53
20. 自分たちのMySQL DBAと開発者でロールが分かれている場合に 開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当 に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした 方が早い ‐ MySQL側でしか気が付けないものはある レプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなの か」はわからない ⇒ やりようはある ‐ 必ず何らかの操作が必要なものはある レプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 19/53
21. アプリケーションによるハートビート INSERT だけで救える命もある（特に REPLICATION CLIENT 権限が許されない(= SHOW REPLICA STATUS が使えない)環境ではこれしかない） 毎回これチェックしてからSELECT投げてると致命的に遅いけれども ‐ そもそも遅延が問題になるテーブルはレプリカから読んではいけないという前提はあれども ‐ INSERT INTO heartbeat (hostname, app_time, server_time, gtid_executed) VALUES (@@hostname, ?, NOW(3), @@global.gtid_executed) yt-heartbeat 20/53
22. 自分たちのMySQL DBAと開発者でロールが分かれている場合に 開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当 に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした 方が早い ‐ MySQL側でしか気が付けないものはある レプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなの か」はわからない ⇒ やりようはある ‐ 必ず何らかの操作が必要なものはある レプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ⇒ これは未だにそうっちゃそうだけども ‐ 21/53
23. オートヒーリングという夢 「何か起こったら」毎回フルバックアップからリストアしてレプリケーション遅延が解消するまで待ってか らLBに戻せばいいのでは？ 無限の帯域があるならそれでもそれなりに動く ‐ GroupReplication + Cloneプラグインは何か問題があればフル同期(SST)を始めて自動復 旧しようとする Galera Clusterも同様 ‐ SinglePrimaryならそれで結構いけるけどLB連携しようとすると作り込みは必要 MySQLRouterを使ったロードバランスでも同様(Clone中もルーティングしようとしちゃう…) ‐ 22/53
24. オンコールから離れてわかったもの だいぶ過保護な監視だった それぞれの目線で「相手はこれを監視しない/できないだろう」という思惑 ‐ 「片肺が落ちた」「フェイルオーバーに成功した」ならば喜ぶところでは ‐ 原因を取り除いて対処…が本当に必要なものだったのか？ その「対処」が「開発チームに連絡する」なのだったら不要なんでは ‐ ヒーリングシステムが信用しきれない気分は今もわかるけれども 23/53
25. 閑話休題 24/53
26. MySQLひとすじ13年からの 25/53
27. からの 26/53
28. ( ﾟдﾟ) 27/53
29. ＿人人人人人＿ ＞　MariaDB　＜ ￣Y^Y^Y^Y￣ 28/53
30. コレジャナイ http://www.zariganiworks.co.jp/korejanairobo/lineup/index.html 29/53
31. MySQL and MariaDB 似たようなもの？ JavaとJavaScriptくらい？ そんなには違わない ‐ Apache httpdとnginxくらい？ これも遠すぎる気がする ‐ イギリス英語とアメリカ英語くらい？ 歴史が長すぎる気がする ‐ redisとvalkeyくらい？ アレはまだそんなに差ができてないのでは？ ‐ DebianとUbuntuくらい？ ‐ 30/53
32. My and Maria The MySQL and MariaDB story - Codemotion Milan 2014 31/53
33. MySQL and MariaDB 32/53
34. MySQL and MariaDB 33/53
35. MySQL and MariaDB 34/53
36. MySQL and MariaDB MariaDBの起源はMySQL 5.1 + Mariaストレージエンジンパッチ Maria is a new storage engine that Guilhem, Sanja, Sergei and I have been working on for the last 2 years. なのでもともとはMySQL 5.0ベースで開発されていたかも Monty says: The Maria engine is released ‐ You can find the release at http://dev.mysql.com/downloads/maria/index.html Monty says: Maria build & public MySQL architecture meeting ‐ 色々な経緯がありそう Monty says: MySQL conference; The good, the bad and the ugly ‐ Maria Engine ‐ The Future of MySQL (The Project) ‐ Ghosts of MySQL Past Part 5: The Era of Acquisitions ‐ 35/53
37. Point of No Return 36/53
38. Point of No Return 37/53
39. Point of No Return MariaDBはMySQL 5.6を待たずに5.5のコードベースに機能を追加した10.0をリリース 5.6は〇racle買収後に開発が始まっているので、リリースに懐疑的だったんだろうと思う ‐ MariaDB 10.0で追加されたGTIDとマルチソースレプリケーションはMySQL 5.6/5.7のものと実装レベルでも SQLレベルでも互換性がない ‐ この当時思ったのは「ストレージエンジンの幕の内弁当」 ‐ このセカンドインパクトから既に13年 38/53
40. Days of Sisters 39/53
41. Days of Sisters MySQLにとっての暗黒時代 8.0 Maintenance Release(パッチバージョンのみのインクリメント)で機能が追加され、オプションは非推奨にされ、 デフォルトだった動作が変更されたりするやつ ‐ 今だからこそ「MySQL 8.4が出てからトークで話すネタなくなった」とか言っていられるけれども ‐ MariaDBにとってのチャレンジ 10.3 SEQUENCE , MariaDB SQL/PL, sql_mode=EMPTY_STRING_IS_NULL MariaDB 10.3 Changes & Improvements ‐ 明らかに何かからシェアを奪う気満々だった時期 ‐ この辺から（だと思う）MariaDBのサイトから “DROP IN REPLACEMENT” の文字が消えた ‐ 40/53
42. Recent Situation 41/53
43. Recent Situation MariaDB / MySQLとも Short-termとLong-termを使い分けるように MariaDB “preview release” は1年間のサポート、 “rolling release” は3か月間のサポート(最近のは rolling release) ‐ MySQL “Innovation release” は3か月間のサポート ‐ MySQL 8.0は2026/04にEOL, MariaDB 10.6は2026/07にEOL https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf ‐ https://mariadb.org/about/ ‐ 42/53
44. Dockerイメージでの比較 43/53
45. 実行ファイルの比較 44/53
46. MariaDB 10.11現在 45/53
47. datadirの比較 46/53
48. Σ(ﾟдﾟlll) 割と別物！ 47/53
49. 俺のMySQLはどこ！？ 48/53
50. yoku0825のMySQLを求める旅は続く MariaDBの情報、5年前に比べてググっても出てこないことが多くなった やってみた系の記事が全然なくなってる ‐ 大体似たようなもんだけどちょくちょく違う、は踏むまで気が付かない というかやっぱりMySQLが好き 49/53
51. ここで一句 50/53
52. コレジャナイ 俺の 🐬は コレジャナイ [root@d72a47a0507a /]# yum install mysql Loaded plugins: fastestmirror, ovl Loading mirror speeds from cached hostfile base | 3.6 kB 00:00:00 extras | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 (1/4): base/7/x86_64/group_gz | 153 kB 00:00:00 (2/4): base/7/x86_64/primary_db | 6.1 MB 00:00:00 (3/4): extras/7/x86_64/primary_db | 253 kB 00:00:00 (4/4): updates/7/x86_64/primary_db | 27 MB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package mariadb.x86_64 1:5.5.68-1.el7 will be installed .. 51/53
53. みなさんもき をつけてね！ 52/53
54. Any Question and/or Suggestion? 53/53