Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Perl MongersのためのMySQL InnoDB Cluster超入門
Search
yoku0825
February 19, 2021
Technology
3
9.6k
Perl MongersのためのMySQL InnoDB Cluster超入門
2021/02/19 Japan.pm 2021
https://yapcjapan.connpass.com/event/198170/
yoku0825
February 19, 2021
Tweet
Share
More Decks by yoku0825
See All by yoku0825
HeatWave をオンプレの MySQL と同じように使おうとしてみた!
yoku0825
0
180
MySQLのロックの種類とその競合
yoku0825
10
4.3k
MySQL 8.4 LTS が あらわれた
yoku0825
2
2k
ぼくたちはMySQL 8.1とどう生きるか
yoku0825
6
2.6k
2022年のMySQLerが20年前のMySQL 4.0に触ると何が起きるか
yoku0825
0
530
テストデータが偏るということについて
yoku0825
3
8.9k
MySQLが得意なこと、不得意なこと(仮)
yoku0825
12
14k
MySQLとインデックスとPHPer
yoku0825
8
8.2k
MySQLとインデックスと私
yoku0825
82
61k
Other Decks in Technology
See All in Technology
Glacierだからってコストあきらめてない? / JAWS Meet Glacier Cost
taishin
1
140
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
3
10k
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
120
Frontier airlines®️ USA Contact Numbers: Complete 2025 Support Guide
oliversmith12
0
110
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
3
2.9k
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
6k
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
360
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
4
660
Zephyr RTOSを使った開発コンペに参加した件
iotengineer22
1
190
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
410
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
Backlog ユーザー棚卸しRTA、多分これが一番早いと思います
__allllllllez__
1
130
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Balancing Empowerment & Direction
lara
1
410
Testing 201, or: Great Expectations
jmmastey
42
7.6k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Done Done
chrislema
184
16k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Bash Introduction
62gerente
614
210k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Transcript
Perl Mongersのための MySQL InnoDB Cluster超入門 「それ、違うわよ」君はつぶやいた。「それは、村上龍」と続けたあと、僕の顔をのぞき込む。 「村上龍だったっけ?」僕の言葉が聞こえなかったかのように、物憂げに窓の外に視線を移しながら君は話題を変えた。 「レプリケーション」「レプリケーション?」「そう。レプリケーション。マルチマスターの」 ©sakaik 2021/02/18
yoku0825 Japan.pm 2021
Chiba.pmの方 から来ました 1/48
Chiba.pmの “m” はMySQLの “m” ※諸説あり 2/48
What’s InnoDB Cluster? 初出は2017/04 (MySQL 5.7.18) 比較的新しい と言うほどではなかった… ‐ 3つのプロセスを協調動作させて
“InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 3/48
\こんばんは/ yoku0825@とある企業のDBA オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter:
@yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会 ‐ MySQL Casual ‐ 4/48
What’s InnoDB Cluster? 初出は2017/04 (MySQL 5.7.18) 比較的新しい と言うほどではなかった… ‐ 3つのプロセスを協調動作させて
“InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 5/48
よういするもの 6/48
MySQL Shellでdba.configureInstanceします 7/48
それを受けてMySQLはグループレプリケーション専用アカウントを作ります 8/48
他のノードにも実行します 9/48
MySQL Shellでdba.createClusterします 10/48
最初の1台でグループレプリケーションが開始されました 11/48
cluster.addInstanceで他の2台をクラスターに追加します 12/48
これでグループレプリケーションは完了です 13/48
グループレプリケーションの参加ノードは、お互いを相互に監視しています 14/48
どこか1か所のキープアライブが途切れると 15/48
自分が大多数かどうかを確かめる (多数派に属していればグループレプリケーションを継続できる。 この場合は3台とも利用可能なまま) 16/48
ノードダウンやネットワーク障害で1ホストが完全に通信不能になると 17/48
それぞれのノードが自分が多数派かどうかを考えて 18/48
少数派は group_replication_exit_state_action の動作をする (デフォルトはread_only) 19/48
多数派は少数派をグループレプリケーションにいないと認識する 20/48
シングルプライマリーモードでプライマリーサーバーが切り離された場合、 残った中から分散合意で新しいプライマリーサーバーを選出する 21/48
それぞれのノードがグループレプリケーションを「どう」認識しているかは、 performance_schema.replication_group_membersで観測可能 22/48
弾き出されたノードはcluster.rejoinInstanceまたは group_replication_autorejoin_triesや group_replication_start_on_bootで復帰可能 23/48
再度参加できればそのまま元通りに (バイナリログ適用による追い付くまでのラグはあるけど) 24/48
さて、MySQL Routerからグループレプリケーションにアクセスする方法 25/48
の前に(時を戻そう) 26/48
MySQL Shellがdba.createClusterした時 27/48
MySQL Shellがdba.createClusterした時 28/48
cluster.addInstanceで他の2台をクラスターに追加した時 29/48
cluster.addInstanceで他の2台をクラスターに追加した時 30/48
MySQL Routerは --bootstrap で初期化する時に 31/48
mysql_innodb_cluster_metadata.instancesにアクセスして 32/48
/var/lib/mysqlrouter/state.json にストアする 33/48
この時ストアするのは「メタデータノード」と呼ばれ 34/48
「このノードにアクセスすれば、 performance_schema.replication_group_membersで グループレプリケーションを観測できるはず」という 問い合わせ先候補 35/48
bootstrapが済んで起動後のMySQL Routerに DBI:: connect します 36/48
MySQL Routerはメタデータノードを選んで (first aliveで先頭から最初に接続できたノード) 37/48
メタデータをフェッチしてオンメモリにキャッシュします (実際はバックグラウンドスレッドによる非同期、 デフォルトTTL=0.5秒) 38/48
6446ポートならRead-Writeでプライマリーサーバー宛てなので 39/48
mysqlrouterプロセスが接続元であるようにNAPTして、 プライマリーサーバーに転送します 40/48
こんな感じ です 41/48
MySQL InnoDB Cluster超入門 mysql_innodb_cluster_metadata.instances はMySQL Shellによって更新されたり されなかったりすることを期待している 「メタデータの取得候補」なので、リアルタイムに反映されなくても「どれか一つに到達でき ればOK」 ‐
このテーブル自体、グループレプリケーションによって同じデータが反映されていることを期 待する ‐ performance_schema.replication_group_members はグループレプリケーションに よってリアルタイムに正しく更新されることを期待している このテーブルの中身のキャッシュであるメタデータキャッシュのTTLが (グループレプリケー ション側でのフェイルオーバー/スイッチオーバーが終わったあとの) 切り替えにかかる時間 ‐ STATEがERRORになっていたら迂回するなど基本的な機能はある ‐ 42/48
MySQL InnoDB Cluster超入門 グループレプリケーション単体で使うことも可能(その場合はInnoDB Clusterとは 呼ばないけれども) MySQL Routerが嫌ならConsulやVIPとか既存の仕組みと組み合わせることもできる ‐ なんならDBD::innodb_clusterとか作ってmysqlrouterプロセスの代わりをさせることもでき
る気がする ‐ クラスタ管理用のデーモンがいなくて良いのは楽で良い グループレプリケーション(N*2+1とでも呼ぶか), MySQL Router(N)もいずれも、マスター/ レプリカのような非対称性がない ‐ MySQL Shellは使いたい時に、グループレプリケーション管理用のアカウントで接続さえでき れば良い(なんなら、そのたびにアカウントを作ったって良い) ‐ 43/48
MySQL InnoDB Cluster超入門 マスター/レプリカのポートの打ち分けはアプリケーション側の責務 クエリーの中身をパースして I や U だったらマスターに振る…とかは一切しない ‐
パースしないからこそMySQL over SSLでも特に設定変更は要らないし ‐ トランザクションやロック、 LAST_INSERT_ID() が途中ですげ変わる心配もない ‐ DBD::mysql (やその他の接続ライブラリ) からは完全に透過的に振る舞う mysqlrouterは本当にNAPTするくらいしかパケットに触らない ‐ 44/48
The next step for MySQL InnoDB Cluster超入門 グループレプリケーションは監視方法がガラっと違う SHOW REPLICA
/* (SLAVE) */ STATUS はからっぽ ‐ performance_schema.replication_group_member_stats とかを監視していく Release yt-healthcheck supports –role=group_replication · yoku0825/ytkit ‐ mysqlrouterが新しい障害点として現れる ヘルスチェック用のエンドポイント、mysqlrouter越しに SELECT 1 でもするようにしておくと いいかも ‐ 45/48
InnoDB Cluster 3つのプロセスを協調動作させて “InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL
Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 46/48
Stay tuned!! 47/48
Any Questions and/or Suggestions? 48/48