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
810
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の非同期レプリケーションでのHAの難しさについて考える
yoku0825
1
450
HeatWave をオンプレの MySQL と同じように使おうとしてみた!
yoku0825
0
200
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
Other Decks in Technology
See All in Technology
データ基盤からデータベースまで?広がるユースケースのDatabricksについて教えるよ!
akuwano
3
150
Delta airlines®️ USA Contact Numbers: Complete 2025 Support Guide
airtravelguide
0
350
TLSから見るSREの未来
atpons
2
190
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
14
5.9k
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
120
関数型プログラミングで 「脳がバグる」を乗り越える
manabeai
2
220
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
710
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
140
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
430
ロールが細分化された組織でSREは何をするか?
tgidgd
1
160
2025-07-06 QGIS初級ハンズオン「はじめてのQGIS」
kou_kita
0
180
衛星運用をソフトウェアエンジニアに依頼したときにできあがるもの
sankichi92
1
210
Featured
See All Featured
RailsConf 2023
tenderlove
30
1.1k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Writing Fast Ruby
sferik
628
62k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Thoughts on Productivity
jonyablonski
69
4.7k
Music & Morning Musume
bryan
46
6.7k
4 Signs Your Business is Dying
shpigford
184
22k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
700
Docker and Python
trallard
44
3.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Faster Mobile Websites
deanohume
307
31k
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