MySQL on IaaSの運用あれやこれや

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

(･∀･)ゞあんまりデータベースとして面白味はない… 8/44

( ｰ`дｰ´) だがDBA としては嬉しい 9/44

の前に俺が好んで作る構成 10/44

俺が好んで作る構成 11/44

俺が好んで作る構成サービス用のインスタンスとは別にバックアップ専用のレプリカを作る大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアップが取れるサービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータを転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。今は某オブ
ジェクトストレージに送るのが主流 12/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

俺が好んで作る構成サービス用のインスタンスとは別にバックアップ専用のレプリカを作る大体「セグメントごとに1つ」くらいのペース ‐ バックアップレプリカは好きな時に止めたり止めなかったりして好きにバックアップが取れるサービス用のレプリカを増設する時も、時間によらず「バックアップレプリカを止めてデータを転送するだけ」で構築できる ‐ かつてはここからファイルサーバーやテープドライブに転送していた。
今は某オブジェクトストレージに送るのが主流 17/44

インターネットへの送信がデータ量に線形に課金で嬉しいケース帯域幅95%ile方式の課金だと「バックアップ＆外部転送」を特定の時間に重ねるとバンと跳ね上がる可能性がある転送バイト数よりも転送に使う帯域に気を使わないといけないのがストレス ‐ 複数のバックアップレプリカから同時に転送が走らないようにしたり ‐ 転送帯域に制限をかけたらかけたでバックアップが長引いたり ‐ 最初から「どんな速度で送ろうと、100GBは100GBぶんの料金」なので余計な駆
け引き(?)が要らないあとは「だいたい線形」なので、95%ileみたいに桁が一つ変わることはない ‐ 18/44

オブジェクトストレージ vs. ブロックストレージ前者の方が幾分お安くつくイメージ的には物理マシンの HDD vs. SSD くらい？ ‐
長期保管用にはオブジェクトストレージ, 短期保管(数日ぶんを保持する用途)にはブロックストレージ(あるいは物理マシンのHDD)とやっていたけど、それもオブジェクトストレージに載せた方が安くつく？ ⇒安くつきました ‐ 19/44

ストレージが小単位で増やせるのが嬉しいケースバックアップレプリカはサービストラフィックを一切受け付けないので、サービス用mysqldに比べて小さいマシンパワーで動かせる 1サーバーに複数のmysqldを起動させて集約を図る ‐ そのぶんdatadir用の領域がいっぱいほしい ‐ 物理マシンだといつか「ベイに空きがないからここから先は再構築しかない」タイミングにぶつかることがあるけれど、基本的にそんなこともないそれを恐れて無駄に数TB余らせてしまうこともない
‐ 22/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 [email protected]'%' で作るということ ‐
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

MySQL on IaaSの運用あれやこれや

MySQL on IaaSの運用あれやこれや

yoku0825

More Decks by yoku0825

Other Decks in Technology

Featured

Transcript