MySQL Community EditionとMySQL Enterprise Editionから見たMySQLのHA方式の変遷

2025/12/13 Open Source Conference 2025 Hiroshima
https://event.ospn.jp/osc2025-hiroshima/

Transcript

1. MySQL Community EditionとMySQL Enterprise Editionから見たMySQLのHA方式の 変遷 2025/12/13 Oracle ACE Pro(MySQL) yoku0825
2. ＼おはようございます／ yoku0825＠とある企業のDBAだったもの オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitterだったもの: @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会副代表 ‐ MySQL Casual ‐ 1/44
3. おことわり 個人の観測内容であり、所属する組織、所属しない組織の意見を一切代表するものではありま せん 2/44
4. まとめ 公式, コミュニティ製入り乱れたけど今ならMySQL InnoDB Clusterが一番手軽で一番確実 非同期/準同期レプリケーションのフェイルオーバーやACIDの保証は難しすぎる ‐ MySQL Routerの扱いをどうするかは個々の事情に合わせた方が良さそう ‐ 図は2台構成で書いてますが2台にするよりは3台にするのが激しくお勧め MySQL自体は2台で済ませる場合でも第三者ノードを作った方が無難 ‐ 3/44
5. では歴史をさか のぼっていきます 4/44
6. MySQLのHAの歴史 Shared Nothing, Active/Standby, ストレージデバイス同期型 というくくりにしてはみたけれど、オーバービューで見ると共有ストレージ型もやってることはほぼ一緒 ‐ オープンソースだけで組むならPacemaker + DRBD + heartbeatとかcolosyncとか バリエーションとしてCLUSTERPROとかLifeKeeper + DetaKeeperとか ‐ 2015年の公式のホワイトペーパーにもその存在が MySQLの高可用性ソリューション ‐ 5/44
7. Pacemaker + DRBD + heartbeat 6/44
8. Pacemaker + DRBD + heartbeat これで組んでいたパターンはたまにあった MySQL 5.0からMySQL 5.5くらいまでの時代 ‐ 当時「インフラエンジニア」と呼ばれていた職種がDRBD周りのデバイスファイルもMySQLも見てい たことが多い気がする とかく「切り替わりに失敗する」「切り替わるとDRBDの再同期が大変」なイメージがある 7/44
9. その頃の商用版MySQL MySQL最新動向 8/44
10. ストレージデバイス同期型と共有ストレージ型の違い 9/44
11. ストレージデバイス同期型と共有ストレージ型の違い 単に共有ストレージにすると高くつくだけ 共有ストレージ前提のクラスタ用ソフトウェアには共有ストレージを使ったフェンシング機能がついて いる バックエンドをモノリシックにするからこそ得られるメリットだと思う ‐ 10/44
12. フェンシング 11/44
13. フェンシング サーバーは綺麗に電源停止するとは限らない SET GLOBAL read_only = ON が成功するとも、 mysqladmin shutdown が成功 するとも限らない メモリ不足によるスラッシング、ストレージレイヤの一時的な沈黙 切り替え中にプロセスが「復活」してきてしまうことがHAの一番の敵 12/44
14. MySQLのHAの歴史 Shared Nothing, Active/StandbyまたはRead Replica, ネイティブレプリケーション型 MySQLのレプリケーション機能をHA用途に使うタイプ ‐ MySQLのレプリケーションは 単方向 で 非対称 なため、「ソース, レプリカの切り替え（failover）処理」と、 それとは別に 「アプリケーションからの接続先の切り替え処理」が必要 ‐ モニター型としてMHA for MySQL, MySQL Multi Master, mysqlfailover, mysqlfabric, (GitHub) orchestrator プロキシ型として MySQL Proxy, ProxySQL, MariaDB MaxScale, MySQL Router 13/44
15. MHA for MySQL 14/44
16. MHA for MySQL これもMySQL 5.5から5.6、たまに5.7で動かしてるって話も聞いたような気がする 後年MySQL 5.6のGTIDにも対応した ‐ MySQLのレプリケーションは「レプリケーションソース」 vs 「レプリカ」の非対称構成 当時はGTIDもなく、ログファイル名やポジション番号を間違えるだけでレプリケーション全体が崩れる世の中 ‐ 専門知識なしでもsystem perlとepelでssh越しにVIPフェイルオーバーができるとあって大いに 流行った ssh越しにifconfigコマンドを呼ぶVIPがよく使われていたと思う ‐ 15/44
17. ProxySQL 16/44
18. ProxySQL ProxySQLはフェイルオーバー機能は持たない、接続の切り替えのみ MariaDB MaxScaleはフェイルオーバー機能も持ってる ‐ MHA for MySQLでVIPを使いたくない場合の接続先切り替えや、後述のフェイルオーバー機構 の要らないGalera Replicationと組み合わせて使う あるいは、フェイルオーバー自体はエンジニアがやるようなパターン ‐ 17/44
19. その頃の商用MySQL Oracle Linux + Oracle VM Manager DB技術者必見！ 圧倒的な進化を続けるMySQLの最新機能 ‐ レプリケーションによる高可用性構成 だけ3ページにわたってメリットデメリットを説明してい る（それだけニーズも実績も多かったのであろう…） MySQLの高可用性ソリューション ‐ つまりがレプリケーションベースのHAは公式にはなかった 18/44
20. MySQLのHAの歴史 Shared Nothing, Active/Active, レプリケーション魔改造型 MySQLのレプリケーション機能をソースコードレベルで改造して使うタイプ ‐ Galera Cluster for {MySQL,MariaDB}, MariaDB Galera Cluster, Percona XtraDB Cluster 魔改造レプリケーションの層で多数決を取ってトランザクションを成功/失敗させるので奇数台構 成が基本 自分たちだけで複製を調停するので独立したマネージャーが不要で、非対称性のないフラット構成なため単純 なロードバランサーだけで冗長化ができる ‐ ProxySQLやMariaDB MaxScaleはL7プロキシなのでL4LBを使わずにL7LBとして使うこともできる ‐ 19/44
21. Galera Cluster 20/44
22. Galera Cluster Codership Oy. （後にMariaDB Corpが買収） が開発した コンポーネントの名前が wsrep (Write Set REPlication) ‐ MySQLにwsrepを搭載したGalera Cluster for MySQL, MariaDBにwsrepを搭載した Galera Cluster for MariaDB(後にMariaDB Galera Cluster), Percona Server for MySQLにwsrepを搭載したPercona XtraDB Cluster 日本でも当時の Yahoo! JAPAN がPercona XtraDB Clusterを使っていたがそれ以外はそんなには聞か ない ‐ 本質的にMySQLのレプリケーションの延長線上にある（全ての書き込みを全てのノードに伝搬 する）ので書き込みはスケールしない 後にGroup Replicationとして似たようなコンセプトが本家にも実装された ‐ 21/44
23. MySQLのHAの歴史 Shared Nothing, Active/Standby?, バイナリログ加工型 バイナリログの出力までをMySQLネイティブな部分で、バイナリログの伝搬と反映の部分を管理 ‐ Tungsten Replicatorという老舗があるが使ったことはない 日本で「試してみた」以上の話を聞いたことがない… ‐ 22/44
24. Tungsten Replicator? 23/44
25. Tungsten Replicator? レプリカI/OスレッドとレプリカSQLスレッドが担当していた「バイナリログの転送」と「バイナリログイベ ントのリプレイ」を独自のプロセスが担当する ネイティブなレプリケーションは「ソースはバイナリログを手渡すところまでしか知らない」のに対し、独自の作り込み ならではの制御ができる…はず ‐ 1年くらい前の時点で、DebeziumでMySQL 5.7のバイナリログをMySQL 8.0のインスタンスに 流して、切り替え後は8.0から5.7にロールバック用に流すという猛者を見た MySQL本体にあるレプリケーション非互換も、別実装だからこそ吸収できる ‐ 24/44
26. MySQLのHAの歴史 そもそもAmazon RDS for MySQLの台頭によりMySQLを手組みするニーズは減り始めた MySQL 5.6と同時期にMySQL公式からGTIDを前提とした mysqlfailover (MySQL Utilitiesの一部, 更に言うならMySQL UtilitiesはMySQL Workbenchに同梱されたスクリプ ト群だった) が公開 自力でdaemonizeできることやSQL(3306番ポート)だけでレプリケーションの組み換えを行うあたりが新しかっ たが、VIPの付け替えやエンドポイントDNSの取り換えは --after-exec で自作するしかなかった ‐ MySQL 5.6の時点ではGTIDに対応する際の制約が大きく、そもそもGTID自体がまだ下火 ‐ MHA for MySQLは（おそらく、作者が思っていたよりもずっと）長生きした 25/44
27. ポストMHA for MySQL Amazon AuroraのMySQL版さえ出た頃で、手組み人口は更に激減したころ MySQL 5.7(2015年)はAmazon Aurora(2014年)より後らしい ‐ 2014年にひっそりとorchestratorが作成され、2016年にGitHubのブログで紹介されている (この頃は github/orchestrator だった) オンラインALTER TABLEの gh-ost (2016年)より少し後に有名になった印象 ‐ あのGitHubが使っているということ、CLIとGUIがオールインワンだったところ、MHA for MySQLが終焉を迎えて いたこと ‐ 手組み組にはスクラッチ以外にはこの選択肢しか残っていない気がする 本家はアーカイブされてPerconaがフォークしたようだが… ‐ 26/44
28. ポストMHA for MySQLになれなかった何か mysqlfailover は発展解消的に mysqlfabric にその座を明け渡した mysqlfabric も単体でMySQL Fabricと喧伝されたが、プロダクト的にはMySQL Utilitiesの枠を出られ なかった ‐ MySQL Fabricは「コネクタライブラリ自身がレプリケーションソースとレプリカのIPアドレスを認識し てルーティングするためVIPやDNSエンドポイントは不要」という触れ込みだった これが更に発展して、「MySQL RouterがMySQL Fabricと通信することで自動でルーティングが切り替わる」 方式が発表された ‐ こうなるともう完全に「 mysqlrouter をN+1で構成してLBにぶら下げる」「 mysqlrouter をアプリケー ションサーバに相乗りさせるサイドカー形式」でipvsadmフリーな環境が実現した これが今日のInnoDB Clusterにつながっている ‐ 個人的にMySQL Fabric + MySQL Routerに全ベットして盛大な負債を作った 27/44
29. MySQL Fabricの教訓 バグは多かった その割にバグレポートは少なかった 「誰も使わない機能は、どれだけたくさんの目玉があってもバグは登録されない」 ‐ バグレポートをしても微塵も直らなかった 「誰も使わない機能は略 ‐ その意味に気が付いた頃にはもう引き返せないところまで来ていた（） ‐ 公式だからと思って油断してはいけない 28/44
30. MySQLのHAの歴史 Shared Nothing, Active/Active, レプリケーション魔(?) 改造型 MySQLのレプリケーション機能をソースコードレベルで改造して使うタイプ ‐ あれ？ どこかで聞いたような ‐ Group Replication, InnoDB Cluster (= Group Replication + MySQL Router + MySQL Shell), InnoDB ClusterSet (= InnoDB Cluster + 非同期レプリカ) 魔(?) 改造レプリケーションの層で多数決を取ってトランザクションを成功/失敗させるので奇数台 構成が基本 自分たちだけで複製を調停するので独立したマネージャーが不要で、非対称性のないフラット構成なため単純 なロードバランサーだけで冗長化ができる ‐ あれ？ どこかで略 ‐ MySQL RouterはL7プロキシなのでL4LBを使わずにL7LBとして使うこともできる ‐ 29/44
31. InnoDB Cluster 30/44
32. その頃の商用版MySQL MySQL Enterprise High Availability 31/44
33. Σ(ﾟдﾟlll) GPL 版と同じ機能 32/44
34. サンプル ### All 3 servers $ sudo firewall-cmd --change-interface=eth0 --zone=trusted ### ホスト名を使ってGroupReplicationを組むので名前解決できないといけない $ sudo cat << EOF >> /etc/hosts 192.168.0.200 vm-1 192.168.0.201 vm-2 192.168.0.202 vm-3 EOF $ sudo dnf install -y https://dev.mysql.com/get/mysql84-community-release- el9-2.noarch.rpm $ sudo dnf install -y mysql-community-server mysql-shell $ sudo mysqld --user=mysql --initialize-insecure 33/44
35. サンプル ### Only vm-1 mysqlsh --js innodb_cluster_admin@127.0.0.1 c = dba.createCluster('galera_backend') c.addInstance("192.168.0.201") c.addInstance("192.168.0.202") 34/44
36. サンプル ### App nodes $ sudo dnf install -y https://dev.mysql.com/get/mysql84-community-release-el9-2.noarch .rpm $ sudo dnf install -y mysql-router-community ### GroupReplication側でホスト名で管理しているので、Appからの問い合わせに対してもホスト名が返ってく るので解決できる必要がある $ sudo cat << EOF >> /etc/hosts 192.168.0.200 vm-1 192.168.0.201 vm-2 192.168.0.202 vm-3 EOF $ sudo mysqlrouter --user=mysqlrouter --bootstrap innodb_cluster_admin@192.168.0.200 -- conf-use-sockets $ sudo sed -i -b 's/^socket=\/tmp/socket=\/var\/lib\/mysqlrouter/' /etc/mysqlrouter/my sqlrouter.conf $ sudo sed -i -b 's/bind_address=0.0.0.0/bind_address=127.0.0.1/' /etc/mysqlrouter/mys 35/44
37. ね、簡単で しょ 36/44
38. その後の商用版MySQL MySQL 8.3 Enterprise Edition & Open Telemetry MySQL Replication Monitoring : Enhanced Features for the Enterprise Edition 37/44
39. ( ﾟдﾟ) 38/44
40. ( ﾟдﾟ ) 39/44
41. (ﾟдﾟ ) 40/44
42. 忘れてた… 41/44
43. MySQL Carrier Grade Edition MySQL Cluster(MySQL NDB Cluster)の商用版 GPL版のNDBCLUSTER自体が今日話してきた仕組みとは全く違う方法でHAを実装している どちらかというとストレージデバイス同期型に近い動きはするんだけれど ‐ MySQL :: MySQL 8.4 Reference Manual :: 25.2 NDB Cluster Overview 42/44
44. まとめ 公式, コミュニティ製入り乱れたけど今ならMySQL InnoDB Clusterが一番手軽で一番確実 非同期/準同期レプリケーションのフェイルオーバーやACIDの保証は難しすぎる ‐ MySQL Routerの扱いをどうするかは個々の事情に合わせた方が良さそう ‐ 図は2台構成で書いてますが2台にするよりは3台にするのが激しくお勧め MySQL自体は2台で済ませる場合でも第三者ノードを作った方が無難 ‐ 43/44
45. Any Question and/or Suggestion? 44/44