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.5k
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
MySQLのロックの種類とその競合
yoku0825
10
3.6k
MySQL 8.4 LTS が あらわれた
yoku0825
2
1.4k
ぼくたちはMySQL 8.1とどう生きるか
yoku0825
6
2.5k
2022年のMySQLerが20年前のMySQL 4.0に触ると何が起きるか
yoku0825
0
420
テストデータが偏るということについて
yoku0825
3
8.7k
MySQLが得意なこと、不得意なこと(仮)
yoku0825
12
13k
MySQLとインデックスとPHPer
yoku0825
8
8.1k
MySQLとインデックスと私
yoku0825
79
58k
DavidとJackとMySQLのセキュリティと
yoku0825
0
800
Other Decks in Technology
See All in Technology
プロダクト開発、インフラ、コーポレート、そしてAIとの共通言語としての Terraform / Terraform as a Common Language for Product Development, Infrastructure, Corporate Engineering, and AI
yuyatakeyama
6
1.5k
Re:Define 可用性を支える モニタリング、パフォーマンス最適化、そしてセキュリティ
pyama86
9
5k
Tech Blog執筆のモチベート向上作戦
imamura_ko_0314
0
650
ソフトウェアアーキテクトのための意思決定術: Software Architecture and Decision-Making
snoozer05
PRO
17
3.5k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
17k
Windows Server 2025 へのアップグレードではまった話
tamaiyutaro
2
250
LambdaとSQLiteでシステム構築
ogadra
1
150
Enhancing SRE Using AI
yoshiiryo1
1
200
Microsoft Ignite 2024 最新情報!Microsoft 365 Agents SDK 概要 / Microsoft Ignite 2024 latest news Microsoft 365 Agents SDK overview
karamem0
0
180
Skip Skip Run Run Run ♫
temoki
0
350
LLM活用の現在とこれから:LayerXにおける事例とともに 2025/1 ver. / layerx-llm-202501
yuya4
3
260
あなたはJVMの気持ちを理解できるか?
skrb
5
1.9k
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
900
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Optimizing for Happiness
mojombo
376
70k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Producing Creativity
orderedlist
PRO
343
39k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
6
210
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Designing for Performance
lara
604
68k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Code Reviewing Like a Champion
maltzj
521
39k
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