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
800
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
HeatWave をオンプレの MySQL と同じように使おうとしてみた!
yoku0825
0
170
MySQLのロックの種類とその競合
yoku0825
10
4.3k
MySQL 8.4 LTS が あらわれた
yoku0825
2
1.9k
ぼくたちは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
Prox Industries株式会社 会社紹介資料
proxindustries
0
190
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
6
710
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
330
Definition of Done
kawaguti
PRO
6
460
菸酒生在 LINE Taiwan 的後端雙刀流
line_developers_tw
PRO
0
1.1k
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
0
200
CI/CDとタスク共有で加速するVibe Coding
tnbe21
0
230
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
160
本当に使える?AutoUpgrade の新機能を実践検証してみた
oracle4engineer
PRO
1
120
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
3
270
強化されたAmazon Location Serviceによる新機能と開発者体験
dayjournal
2
150
UIテスト自動化サポート- Testbed for XCUIAutomation practice
notoroid
0
110
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Designing for humans not robots
tammielis
253
25k
BBQ
matthewcrist
89
9.7k
Statistics for Hackers
jakevdp
799
220k
Designing Experiences People Love
moore
142
24k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Faster Mobile Websites
deanohume
307
31k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
43
2.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
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