2020/12/03 dbts2020 https://www.db-tech-showcase.com/dbts/2020/online/schedule
MySQL on IaaSの運用あれやこれやマネージドでないことを楽しむ2020/12/03yoku0825db tech showcase ONLINE 2020
View Slide
セッション概要(これ登録した人は見えたのかな…)- IaaS上でMySQLを運用して上手く行ったことやハマったことを紹介します- オンプレに比べて便利なこと不便なこと- マネージドに比べて便利なこと不便なこと- 「IaaSに適したMySQL」の話ではなく、「組み合わせて、上手くやりたい」経験談です大事なことはだいたい @ts4th の資料に書いてあるさいきんの InnoDB Adaptive Flushing (仮)‐さいきんのMySQLに関する取り組み(仮)‐1/44
\こんにちは/yoku0825@とある企業のDBAオラクれない‐ポスグれない‐マイエスキューエる‐生息域Twitter: @yoku0825‐Blog: 日々の覚書‐日本MySQLユーザ会‐MySQL Casual‐2/44
MySQL on IaaSIaaSの定義とかよく知らないんですけど、このセッションの中では「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 -xsrc_machine$ tar -C /data -c mysql | pv | pzstd -c | nc dest_machine 1000014/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 Questionsand/orSuggestions?44/44