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

by yoku0825

Slide 1

Slide 1 text

2025年になってもまだMySQLが好きこの道一筋13年ちょい 2025/09/06 yoku0825

Slide 2

Slide 2 text

おはようございます 1/53

Slide 3

Slide 3 text

千葉.pmの方から来ました 2/53

Slide 4

Slide 4 text

千葉.pmのMは MySQLのM！ 3/53

Slide 5

Slide 5 text

※諸説あります 4/53

Slide 6

Slide 6 text

＼おはようございます／ yoku0825＠とある企業のDBAだったものオラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitterだったもの: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ‐ MySQL Casual ‐ 5/53

Slide 7

Slide 7 text

諸君、私は MySQLが好きだ 6/53

Slide 8

Slide 8 text

諸君、私は MySQLが大好きだ 7/53

Slide 9

Slide 9 text

MySQLひとすじ13年 MySQLのサードパーティーサポートと商用版代理店 MySQLユーザー企業のDBAその1 MySQLユーザー企業のDBAその2 5月から現職 8/53

Slide 10

Slide 10 text

Why MySQL? MySQLは大きなブラックボックスアプリケーション SQLより下側は隠蔽されている（ことになっている）実際は全然隠れてないあたりがかわいい ‐ 良くも悪くも素直自分で考えても実行戦略が読めないようなのは遅い自分で考えて遅そうな実行戦略になるのは遅いこれなら速く終わるだろってやつは速いレプリケーションが壊れた時の原因は大体一瞬で想像がつく ‐ オンラインであることにこだわっている（それが正しいかどうかは置いておいて） ALTER TABLE中も読み書きさせたい何ならバッファプールの再構成もオンラインでさせてあげたいテンポラリテーブルのDisk落ちもテンポラリテーブルの再構成なく継続させたい (8.0の一部期間のみ…) ただし運用のツケは自分で払わされる ‐ レプリケーションを使えば可能性は無限大インデックスの追加も、カラムの追加も上手くやれば(カラムの先行追加は功夫が必要)レプリカ先行させてフェイルオーバーで済ませられるバックアップの取得も、バージョンアップも、レプリカからなら気軽にいけるただし非同期レプリケーションの自動フェイルオーバーは無茶苦茶難しい ‐ 9/53

Slide 11

Slide 11 text

Why MySQL? RDBの面白さは、さまざまなジレンマやトレードオフを内包している点だと思っています。データの不整合を起こさず、一度コミットしたデータは絶対に失えない。でもパフォーマンスは上げたい。この二つを両立するために、多くのデータベースではトランザクションの分離レベルを少し緩めるなどの工夫をしています。わかります。インデックスなんてまさにそうですよね。検索速度を上げるために、わざわざデータを複製してソートしなおしている。なぜ自らデータ量を増やすんだ……という、あのあたりの自己矛盾が、なんだかかわいくも見えます（笑）。 https://sakumaga.sakura.ad.jp/entry/otsukatomoaki/ 10/53

Slide 12

Slide 12 text

Why MySQL? 個人的にはダメな子だから好きになったわけじゃないたまたま好きになった子がバカだっただけまあ好きになっちゃったんだからしょうがないよねそれでも俺は8.0のことは許してないぞ ‐ 11/53

Slide 13

Slide 13 text

とある企業のDBAではないもの 12/53

Slide 14

Slide 14 text

ユーザー企業のDBA 自分たち(法人)のマシン自分たち(法人)のデータ自分たち(法人)の運用 DBAに対応する「ユーザー」は同じ会社の同僚たち ‐ 13/53

Slide 15

Slide 15 text

とある企業のDBAではないものお客様のマシンお客様のデータ自分たちの運用と、お客様の運用は別物責任分界点の内側の運用は我々 ‐ 責任分界点の外側の運用はお客様 ‐ 14/53

Slide 16

Slide 16 text

自前の監視 CPU使用率, Memory使用率, Swap使用率, Disk使用率スローログの数, クエリ実行時間, レプリケーション遅延, デッドロック検出, エラーログ転送, Too many connections, Threads_Running, AUTO_INCREMENT, Uptime, .. yt-healthcheck ‐ テーブルごとの1か月にフェッチされた行の総数の変化, クエリタイプごとの1か月でのレイテンシの変化, テーブルごとの行の総数の変化, .. yt-collect ‐ 15/53

Slide 17

Slide 17 text

自分たちのMySQL DBAと開発者でロールが分かれている場合に開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした方が早い ‐ MySQL側でしか気が付けないものはあるレプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなのか」はわからない ‐ 必ず何らかの操作が必要なものはあるレプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 16/53

Slide 18

Slide 18 text

自分たちのMySQL DBAと開発者でロールが分かれている場合に開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした方が早い ‐ MySQL側でしか気が付けないものはあるレプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなのか」はわからない ‐ 必ず何らかの操作が必要なものはあるレプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 17/53

Slide 19

Slide 19 text

アプリケーション監視の進化アプリケーションログの集約が一般化トレーシングも随分普及してきた何かエラーが起こったりレスポンスが悪くなったりした時はMySQL側で監視するよりもよっぽどノイズも少なく検知できるケースが多い MySQL側では正常動作（たとえばロック競合でクエリを待たせるのはMySQL側では当然の正常系動作）でも影響が出ているようなケースの検出は当然正確 ‐ というよりはDBAが進化をサボっている可能性もある 18/53

Slide 20

Slide 20 text

自分たちのMySQL DBAと開発者でロールが分かれている場合に開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした方が早い ‐ MySQL側でしか気が付けないものはあるレプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなのか」はわからない ⇒ やりようはある ‐ 必ず何らかの操作が必要なものはあるレプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ‐ 19/53

Slide 21

Slide 21 text

アプリケーションによるハートビート 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

Slide 22

Slide 22 text

自分たちのMySQL DBAと開発者でロールが分かれている場合に開発者がMySQLまで監視するケースはそんなに多くない ⇒ 自分が早期発見の最後の砦になる ⇒ 本当に？ ‐ 開発者がMySQLまで注意を払っていたとしても、アラートの経路は分断されている ⇒ 結局自分たちで鳴らした方が早い ‐ MySQL側でしか気が付けないものはあるレプリケーションの遅延はアプリケーションからは「その行が本当に存在しないのか」「まだ適用されていないだけなのか」はわからない ⇒ やりようはある ‐ 必ず何らかの操作が必要なものはあるレプリケーションスレッドが止まってたらまず間違いなく原因を取り除いて START REPLICA しないといけない ⇒ これは未だにそうっちゃそうだけども ‐ 21/53

Slide 23

Slide 23 text

オートヒーリングという夢「何か起こったら」毎回フルバックアップからリストアしてレプリケーション遅延が解消するまで待ってからLBに戻せばいいのでは？無限の帯域があるならそれでもそれなりに動く ‐ GroupReplication + Cloneプラグインは何か問題があればフル同期(SST)を始めて自動復旧しようとする Galera Clusterも同様 ‐ SinglePrimaryならそれで結構いけるけどLB連携しようとすると作り込みは必要 MySQLRouterを使ったロードバランスでも同様(Clone中もルーティングしようとしちゃう…) ‐ 22/53

Slide 24

Slide 24 text

オンコールから離れてわかったものだいぶ過保護な監視だったそれぞれの目線で「相手はこれを監視しない/できないだろう」という思惑 ‐ 「片肺が落ちた」「フェイルオーバーに成功した」ならば喜ぶところでは ‐ 原因を取り除いて対処…が本当に必要なものだったのか？その「対処」が「開発チームに連絡する」なのだったら不要なんでは ‐ ヒーリングシステムが信用しきれない気分は今もわかるけれども 23/53

Slide 25

Slide 25 text

閑話休題 24/53

Slide 26

Slide 26 text

MySQLひとすじ13年からの 25/53

Slide 27

Slide 27 text

からの 26/53

Slide 28

Slide 28 text

( ﾟдﾟ) 27/53

Slide 29

Slide 29 text

＿人人人人人＿＞　MariaDB　＜￣Y^Y^Y^Y￣ 28/53

Slide 30

Slide 30 text

コレジャナイ http://www.zariganiworks.co.jp/korejanairobo/lineup/index.html 29/53

Slide 31

Slide 31 text

MySQL and MariaDB 似たようなもの？ JavaとJavaScriptくらい？そんなには違わない ‐ Apache httpdとnginxくらい？これも遠すぎる気がする ‐ イギリス英語とアメリカ英語くらい？歴史が長すぎる気がする ‐ redisとvalkeyくらい？アレはまだそんなに差ができてないのでは？ ‐ DebianとUbuntuくらい？ ‐ 30/53

Slide 32

Slide 32 text

My and Maria The MySQL and MariaDB story - Codemotion Milan 2014 31/53

Slide 33

Slide 33 text

MySQL and MariaDB 32/53

Slide 34

Slide 34 text

MySQL and MariaDB 33/53

Slide 35

Slide 35 text

MySQL and MariaDB 34/53

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Point of No Return 36/53

Slide 38

Slide 38 text

Point of No Return 37/53

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Days of Sisters 39/53

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Recent Situation 41/53

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Dockerイメージでの比較 43/53

Slide 45

Slide 45 text

実行ファイルの比較 44/53

Slide 46

Slide 46 text

MariaDB 10.11現在 45/53

Slide 47

Slide 47 text

datadirの比較 46/53

Slide 48

Slide 48 text

Σ(ﾟдﾟlll) 割と別物！ 47/53

Slide 49

Slide 49 text

俺のMySQLはどこ！？ 48/53

Slide 50

Slide 50 text

yoku0825のMySQLを求める旅は続く MariaDBの情報、5年前に比べてググっても出てこないことが多くなったやってみた系の記事が全然なくなってる ‐ 大体似たようなもんだけどちょくちょく違う、は踏むまで気が付かないというかやっぱりMySQLが好き 49/53

Slide 51

Slide 51 text

ここで一句 50/53

Slide 52

Slide 52 text

コレジャナイ俺の 🐬はコレジャナイ [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