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
MySQL on IaaSの運用あれやこれや
Search
yoku0825
December 03, 2020
Technology
2
710
MySQL on IaaSの運用あれやこれや
2020/12/03 dbts2020
https://www.db-tech-showcase.com/dbts/2020/online/schedule
yoku0825
December 03, 2020
Tweet
Share
More Decks by yoku0825
See All by yoku0825
MySQLのロックの種類とその競合
yoku0825
7
2.1k
MySQL 8.4 LTS が あらわれた
yoku0825
2
540
ぼくたちはMySQL 8.1とどう生きるか
yoku0825
6
2.3k
2022年のMySQLerが20年前のMySQL 4.0に触ると何が起きるか
yoku0825
0
350
テストデータが偏るということについて
yoku0825
3
8.5k
MySQLが得意なこと、不得意なこと(仮)
yoku0825
12
13k
MySQLとインデックスとPHPer
yoku0825
8
8k
MySQLとインデックスと私
yoku0825
65
53k
DavidとJackとMySQLのセキュリティと
yoku0825
0
760
Other Decks in Technology
See All in Technology
Slackbot × RAG で実現する社内情報検索の最適化
howdy39
2
310
kube-vipとkube-proxy置き換えCiliumを積んだ究極のK3sクラスタを建てる
logica0419
4
200
Oracle Database 23ai 新機能#4 Rolling Maintenance
oracle4engineer
PRO
0
120
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
2.8k
O'Reilly Superstream: Building a RAG App to Chat with Your Data
pamelafox
0
110
OPENLOGI Company Profile for engineer
hr01
1
12k
【shownet.conf_】コンピューティング資源を統合した分散コンテナ基盤の進化
shownet
PRO
0
370
令和最新版 Perlコーディングガイド
anatofuz
4
3.2k
UE5の雑多なテク
ryuichikawano
0
300
【shownet.conf_】トポロジ図の歩き方
shownet
PRO
0
460
Oracle Database 23ai 新機能#4 Real Application Clusters
oracle4engineer
PRO
0
140
【shownet.conf_】ネットワークテストの最適化と利便性の追求
shownet
PRO
0
310
Featured
See All Featured
Making Projects Easy
brettharned
114
5.8k
Gamification - CAS2011
davidbonilla
80
5k
Why Our Code Smells
bkeepers
PRO
334
57k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
29
1.7k
Optimizing for Happiness
mojombo
375
69k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
125
18k
Being A Developer After 40
akosma
84
590k
How GitHub Uses GitHub to Build GitHub
holman
473
290k
For a Future-Friendly Web
brad_frost
174
9.3k
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Rails Girls Zürich Keynote
gr2m
93
13k
Building Adaptive Systems
keathley
37
2.1k
Transcript
MySQL on IaaSの運用あれやこれや マネージドでないことを楽しむ 2020/12/03 yoku0825 db tech showcase ONLINE
2020
セッション概要(これ登録した人は見えたのかな…) - IaaS上でMySQLを運用して上手く行ったことやハマったことを紹介します - オンプレに比べて便利なこと不便なこと - マネージドに比べて便利なこと不便なこと - 「IaaSに適したMySQL」の話ではなく、「組み合わせて、上手くやりたい」経験談です 大事なことはだいたい
@ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing (仮) ‐ さいきんのMySQLに関する取り組み(仮) ‐ 1/44
\こんにちは/ yoku0825@とある企業のDBA オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter:
@yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会 ‐ MySQL Casual ‐ 2/44
MySQL on IaaS IaaSの定義とかよく知らないんですけど、このセッションの中では「OSより下(だ け)を提供してくれる何か」のつもりでいます 3/44
vs. マネージド 主に名前解決ベースのHAが提供される 秒単位のPITRが提供される 少なくともこれらが自前で提供できないなら、 MySQL on IaaS は「楽しめない」 えっこれらが提供されてないマネージドMySQLがあるんですか!?
‐ 4/44
vs. 物理マシン CPUバウンドなワークロードでは熱とか電源がちゃんとしてればオーバークロック が有効 ローカルストレージの書き込みに失敗すれば綺麗にmysqldがアボートしたり綺麗 にOSリブートかかったりする 書き込みに失敗したことが返らないストレージというものはかなり厄介 5/44
IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB~100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 6/44
7/44
(・∀・)ゞ あんまり データベースとして 面白味はない… 8/44
( ー`дー´) だがDBA としては嬉しい 9/44
の前に俺が好 んで作る構成 10/44
俺が好んで作る構成 11/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 12/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 13/44
LANが速くて嬉しいケース 力勝負の rsync はやっぱりネットワークバウンド 300GBのデータディレクトリを転送するには1Gbpsで40分、10Gbpsなら4分(ワ イヤースピード出ればだけど) 間に pzstd 噛ませて転送の容量を下げるとスピードアップできるけどCPUにもよる dest_machine$
nc -l 0.0.0.0 10000 | pzstd -dc | tar -C /data/mysql -x src_machine$ tar -C /data -c mysql | pv | pzstd -c | nc dest_machine 10000 14/44
LANが速くて嬉しいケース 地味に pt-online-schema-change や gh-ost は大容量のバイナリログを吐く 特に gh-ost は binlog_row_image
= FULL を要求するので「もとのテーブルの倍近く」のバイナ リログを(既存のトラフィックに追加で)サクッと吐く ‐ 非同期レプリケーションの転送を律速するパラメーターは特に存在しないので、ツール側でも sleepするけど心配がないくらいまで帯域が大きいと嬉しい ‐ 15/44
俺が好んで作る構成 16/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。
今は某オ ブジェクトストレージに送るのが主流 17/44
インターネットへの送信がデータ量に線形に課金で嬉しいケース 帯域幅95%ile方式の課金だと「バックアップ&外部転送」を特定の時間に重ねる とバンと跳ね上がる可能性がある 転送バイト数よりも転送に使う帯域に気を使わないといけないのがストレス ‐ 複数のバックアップレプリカから同時に転送が走らないようにしたり ‐ 転送帯域に制限をかけたらかけたでバックアップが長引いたり ‐ 最初から「どんな速度で送ろうと、100GBは100GBぶんの料金」なので余計な駆
け引き(?)が要らない あとは「だいたい線形」なので、95%ileみたいに桁が一つ変わることはない ‐ 18/44
オブジェクトストレージ vs. ブロックストレージ 前者の方が幾分お安くつく イメージ的には物理マシンの HDD vs. SSD くらい? ‐
長期保管用にはオブジェクトストレージ, 短期保管(数日ぶんを保持する用途)には ブロックストレージ(あるいは物理マシンのHDD)とやっていたけど、それもオブ ジェクトストレージに載せた方が安くつく? ⇒安くつきました ‐ 19/44
俺が好んで作る構成 20/44
俺が好んで作る構成 サービス用のインスタンスとは別にバックアップ専用のレプリカを作る 大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアッ プが取れる サービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータ を転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 21/44
ストレージが小単位で増やせるのが嬉しいケース バックアップレプリカはサービストラフィックを一切受け付けないので、サービス 用mysqldに比べて小さいマシンパワーで動かせる 1サーバーに複数のmysqldを起動させて集約を図る ‐ そのぶんdatadir用の領域がいっぱいほしい ‐ 物理マシンだといつか「ベイに空きがないからここから先は再構築しかない」タイ ミングにぶつかることがあるけれど、基本的にそんなこともない それを恐れて無駄に数TB余らせてしまうこともない
‐ 22/44
俺が好んで作る構成 23/44
IaaSのいいところ だいたいLANが速い だいたいインターネットへの送信は帯域幅ではなくデータ量で線形に課金 だいたいストレージは1GB~100GB単位で増やせる だいたい「野良インスタンス」があれば気付く 24/44
野良インスタンス XXXサービスのセグメントに何故か1つだけポツンとYYYサービスのインスタンス が… 開発環境のwebapが何故か本番のDBに接続している… 25/44
野良インスタンス 事故を防ぐためにIPアドレス決め打ちでアカウントを作っていた MySQLの「アカウント」は (User, Host) で1つのアカウント ‐ webap増えるたびに CREATE USER,
GRANT .. MySQL 8.0でロールが出来たので幾分楽になったけれど ‐ 26/44
野良インスタンス vs. ファイアウォール MySQL側の認証機構に頼るよりも、IaaS側のネットワークACLに任せる方がいい MySQL上では CREATE USER hoge@'%' で作るということ ‐
ManagedなDBMSだとこれが定石らしいし ‐ ネットワークACLは(DBMSのアカウント管理よりはよほど頻繁に)よくコード化さ れる Terraform, AWS Cloudformation, etc.. ‐ そもそも請求書に直結するので、自前データセンターよりよほど野良インスタンス が少ない() 27/44
クラウドっぽいなと思ったところ ブロックストレージが綺麗に死なない インスタンスガチャは健在 インプレースではなく「増やして減らす」が定石 28/44
datadirに刺さってるス トレージを黙って引っこ 抜いたことはあります か? [はい/イエス] 29/44
ブロックストレージが綺麗に死なない datadirに刺さってるストレージを黙って引っこ抜くとフツーのmysqldは死にます 厳密にはInnoDBログファイルへのwriteにOSがエラーを返してくれるとちゃんとAssertする ‐ NFSとかNASとかそうなんですけど、引っこ抜いても死なない(writeがエラーを返 さずに何故かずっと待つ)環境もあって プラットフォームによるんでしょうけどIaaSは待つことが多い気がする ‐ RAIDカードがぶっ壊れた時とか死にかけのHDDみたいな感じ ‐
30/44
ブロックストレージが綺麗に死なない mysqldが落ちてくれないということはTCPの3306は開きっぱなし フェイルオーバーがトリガーされない ‐ コネクションプールで繋ぎっぱなしのコネクションが切断されない ‐ あっ刺さってると思ってフェイルオーバーしたら、元のマスターが何故か活動を再 開した (少なくとも切り替えた時点では) SET
GLOBAL read_only = 1 的なクエリーを叩き込もうとして もタイムアウトしていた ‐ 仕方がないので残ったマシンだけでレプリケーション構成を再構築する、Dead promotionと 言ったりするらしい ‐ コネクションプールで繋ぎっぱなしになっていたコネクションが運悪く活動を再開 してデュアルマスターであばばばば 30分ぶんのデータの辻褄を合わせるのに8時間くらいがんばった… ‐ 31/44
ノードフェン シングだいじ 32/44
ノードフェンシングだいじ 今までは物理マシンのH/Wウォッチドッグが頑張ってOSを叩き落としてくれてい た そのことを忘れたままIaaSに行っちゃったのでこれからの人は思い出しておいてく ださい 言われてみりゃアレはLinuxの機能じゃない方のウォッチドッグだった… ‐ 33/44
同じEXPLAIN、同じmy.cnfな のに1台だけ%userが高くてレ スポンスタイムが20msくらい 遅い…原因パッと思いつきます か? 34/44
インスタンスガチャは健在 「噂には聞いていたけどこれがそれか…!」と思った ホントにインスタンス停止/起動したら綺麗に他のマシンと同じくらいになった 理屈としても噂としても理解はできるけど、物理マシン脳すぎて辿りつけなかった うわぁクラウドっぽいと思った 35/44
インプレースよりも「増やして減らす」 「バックアップ取ってレプリカ切り離してALTER流して、検証終わったらリストア してレプリケーションつなぎ直しましょうか」 「スナップショット取って復元した方を検証に使えばいいのでは?」 「( ゚д゚)ハッ!」 36/44
インプレースよりも「増やして減らす」 「トータルの台数は変えられない」という錯覚 ちゃっと上げてパッと使ってサクッと消す、クラウドだ! ‐ もともとMySQLのレプリケーションによくマッチした使い方ではある だがこの使い方と非常に相性の悪い構成管理ツールがあってだな 37/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 38/44
あんまり変わらないところ サーバーは落ちるものだと考える まあ物理マシンでも落ちたよね ‐ インスタンスリタイアの通知を見過ごすと冷汗が流れる ‐ バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 39/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る あんまりプラットフォームに密結合なスナップショットとかで取ると取り回しが効かない DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉
40/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない はやくMySQLはLTSを出してください ‐ MySQLのレプリケーションの柔軟度高杉 41/44
あんまり変わらないところ サーバーは落ちるものだと考える バックアップはポータブルな形で取る バージョンアップはサボらない MySQLのレプリケーションの柔軟度高杉 DC ⇔ クラウド間を行ったり来たりとか、クロスリージョンとか ‐ 42/44
まとめ IaaSそのものもそうだけど、IaaSについてくるその他の機能を使って、組み合わ せて楽しくやる 大事なことはだいたい @ts4th の資料に書いてある さいきんの InnoDB Adaptive Flushing
(仮) ‐ さいきんのMySQLに関する取り組み(仮) ‐ 43/44
Any Questions and/or Suggestions? 44/44