MySQLを割と一人で300台管理する技術

1. MySQLを割と⼀⼈で300台管理する技術 2017/09/05 yoku0825 db tech showcase 2017

2. ＼こんにちは／ yoku0825の中の⼈＠GMOメディア Oracle ACE- でもオラクれない- そしてポスグれない- ちょっとマイエスキューエる- ⽣息域 Twitter: @yoku0825- Blog: ⽇々の覚書- MyNA ML: ⽇本MySQLユーザ会- MySQL Casualʼs Slack: MySQL Casual- 1/63

3. MySQLが増えやすいわけフリーソフトウェア（GPLv2）利⽤するのにお⾦はかからない- データの複製がしやすい遠い昔（3.23.15, 2000/05）からレプリケーションがある- 詰まったらSQLチューニングより増やして何とかする、という世論もあったり - MySQL⼤好きなおじさんガイル σ(ﾟ∀ﾟ )- 2/63

4. 結果 3/63

5. 311個の mysqld (2017/08現在) 4/63

6. たぶんここまではそんなに数が多い⽅ではない… 5/63

7. が 6/63

8. GMOメディア 7/63

9. 会社の数だけDBのデザインパターンがある (c) インターネット界隈のことを調べるお http://takanoridayo.blog.shinobi.jp/Entry/426/ 8/63

10. サービスの種類が無駄に多い 9/63

11. MySQLの⾯倒を⾒る体制 DBAチーム現在4⼈体制 PostgreSQL, Oracleの⾯倒を⾒ている⼈もいるワーストの時期では稼働できたのが俺⼀⼈だった最近チームがだいぶ変わった 10/63

12. MySQLの⾯倒を⾒る #とは障害対応 MySQLに関するサポート DBに特化した（広義の）インフラデザイン DBに特化したショット作業 11/63

13. MySQLの⾯倒を⾒る #とは障害対応 DBサーバーのシェルを使えるのはDBチームとインフラチームのみ- AP起因でMySQLがぶん回ったりするものを含む- H/W交換はお任せ、OSを再セットアップしてからが出番- MySQLに関するサポート「新しい開発環境のDBがほしいんですけど」- 「APサーバーが追加されたからユーザー追加してほしいんだけど」- 「クエリー遅いんですけど」- 12/63

14. MySQLの⾯倒を⾒る #とは DBに特化した（広義の）インフラデザインバックアップの頻度, 保管先, ..etc. + その実装- 監視, リソースモニタリング, ..etc. + その実装- mikasafabric for MySQL + MySQL Router- メジャーバージョンアップの検証とか、Percona Serverとか MariaDBとか - DBに特化したショット作業吊るしの ALTER TABLE 以外を使ったテーブル定義の更新 < 5.6 だったり、テーブルが⼤きすぎてレプリケーションが詰まったりするケース - スロークエリーチューニング- マイナーバージョンアップ- 13/63

15. ｳｯ… 14/63

16. 無理 15/63

17. MySQLを割と⼀⼈で300台⾯倒を⾒るために 16/63

18. 省⼒化ただし悲惨な状態になってから⼿を付けたものだけではない 17/63

19. 省⼒化管理台帳死活（︖）監視ログ監視コンフィグテンプレートエンジンスキーマテスト mikasafabric for MySQL 後追いできるリソース監視あとこまごましたこと 18/63

20. 管理台帳ここにExcelの台帳があるじゃろ︖ 会社の外から⾒られないじゃろ︖- スプレッドシートに変わるじゃろ︖ 結局開くのに時間がかかるわ、他の機能に使いまわせないわ、古い情報（マイナーバージョンアップしたのに古いバージョン番号とか）が載ってたりするじゃろ︖ - ある⽇それが嫌になったんじゃ 19/63

21. 管理台帳データはMySQLに保管実体はPerlのスクリプトで、300インスタンスのMySQLに次々ログインして SHOW VARIABLES とか SHOW SLAVE STATUS とか諸々引っこ抜いてくる定期的(2/week)に登録済のmysqldをチェックバージョンアップ、レプリケーションの構成変更など、勝⼿に情報を更新 - マスター切り替えがあっても定期実⾏スクリプトを⼿で流し直してやるだけで台帳が最新に - 退役したサーバーは定期実⾏時にエラーになるので遅くとも1週間で反映される - 前回から変更されたサーバー変数やアカウントがあればチェックできる - 20/63

22. 管理台帳 21/63

23. 管理台帳⼀番気に⼊ってるのは、MySQLにデータが保管されている「だけ」なので、mysqlコマンドラインクライアントでデータが引っこ抜けてパイプできること mysql -e "SELECT * FROM instance_list" | grep ホスト名とかすればWHERE句すら組み⽴てなくていい…︕ - 勝⼿にタブセパレートになるので、コメントに空⽩⽂字があっても awkと相性がいい pssh や tmux を使ったマルチペインのオペレーションがやりやすい - これができたおかげでバックアップスクリプトとか⾊々連携できた- 22/63

24. 死活（︖）監視⼿数が少ない時はあんまりプロアクティブに対応できないリアクティブ対応で可能な限り拾えるように即対応しなくていいものをアラートにしない- いずれ障害になるであろうものは早めにアラートにする- 23/63

25. 死活（︖）監視ウチではNagiosが主流、ところによりZabbix これ、監視サーバーの登録は他のチームなのでその辺の⾃動化は彼らに任せておくとして「監視項目の充実」と「監視項目の差異の吸収」 24/63

26. 死活（︖）監視 Nagiosのmonitoring-pluginsの監視項目 mysql̲real̲connect 接続できたってMySQLが息してないことはいくらでもある… - SHOW SLAVE STATUS Slave̲IO̲Running, Slave̲SQL̲Running, Seconds̲Behind̲Master ただしオプション指定、マスターに向けてオプション指定するとCRITICALになるマスターをごりごり切り替えるスタイルには不向きすぎる - 25/63

27. アドオンした死活（︖）監視 SHOW PROCESSLIST バックグラウンド以外で⻑時間動きっぱなしのクエリーがあれば検知暴⾛SELECTでバッファプールを⾷い荒らす奴とか Mroongaがクラッシュしてロックのタイムアウトが設定できなかった頃役に⽴った - AUTO_INCREMENT なカラムの使⽤量あふれると即死なわりに意外と監視されていない- オススメ- information_schema.tables と information_schema.columns を JOIN して得る sys.schema_auto_increment_columns なら⼀発で取れる - 26/63

28. アドオンした死活（︖）監視 SHOW STATUS, SHOW VARIABLES Threads_connected / max_connections を監視 100%になると当然 Too many connections Percona Serverだとエラーログに出るんだけど監視ユーザーは Super 持ちなことが多くて意外と気付かない - read_only マスターの場合はOFFであるべきでスレーブの場合はONであるべき意外とうっかりミスが拾えていい - 27/63

29. アドオンした死活（︖）監視 SHOW SLAVE STATUS のMulti-Source Replication対応意外と対応されてなかった。。- マスター、スレーブの⾃動判定胸に⼿を当てて考えてみたら SHOW SLAVE STATUS の出⼒結果の有無で判断してる - じゃあスクリプトにもそれやらせればいいんじゃないか- 28/63

30. アドオンした死活（︖）監視問題があった時のログを詳細に残す WARNING, CRITICALならその時の⽣ログ（判定につかったステートメントの結果の戻り）をそのままsyslogに吐かせる - これはNagiosの制限が悪いのだ…- Songmu/horenso も便利- See also, 後追いできるリソース監視 29/63

31. 死活（︖）監視を充実させると多少雑にサイジングしてもワーニングのうちに回収できるケースが増えるサイジングにかける時間を減らせる- 予め必要そうな情報を残すようにしておく障害 ⇒ 再現待ち ⇒ 情報収集 ⇒ 対処のサイクルを短くする- ⼀度踏んだ轍をどんどん追加すると起こったあとに対処するよりもよっぽど楽 30/63

32. ログ監視エラーログを監視しているところは少ない（俺調べ）が、まあ拾っておくと幸せになれるものもいくつかあるフィルタリングして即Slackに放り投げているので、ポーリング監視に⽐べてレスポンスは圧倒的に速い - 31/63

33. ログ監視 [Note] Slave: received end packet from server due to dump thread being killed on master server̲uuidカブりとかで出るやつ（I/Oスレッドが無限に再起動するやつ） - mysqld_safe Number of processes running now: 0 OOM Killerに亭主を殺されたり、SEGVでmysqldが死んだりした時はまずこれが出る。mysqld̲safeを使ってると瞬間的に再起動されちゃってNagiosに引っかからないことがあるので。 - [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. binlog_format = STATEMENT でレプリケーションアンセーフな関数使っちゃった時に - 今はもう binlog_format = STATEMENT 撲滅したので⼆度と出ることはないような気もする - 32/63

34. ログ監視 33/63

35. ログ監視しばしば「おう、お前こんなログ吐くのな」というものと出会える⼈間、思いも⾄らないものは監視できないけど、MySQLが吐くログのうち害がないもの以外…という条件で通知させていると稀によくある - フィルタリングの仕組みを合わせて整備しておかないとあっという間にあふれる - mysqld̲safeだけならかなり前から syslog オプションがあるのでそっちで拾うのもいい 34/63

36. コンフィグテンプレートエンジン MySQL 8.0.3でInnoDB関連のパラメーターをある程度⾃動で設定する innodb-dedicated-server が導⼊されるらしいですがよく考えればコンフィグは⾃動でほげっているので今とそんなに変わることはないのであった今Perlで書いてるんだけどよく考えればこういうのPHPうってつけなんじゃ 35/63

37. コンフィグテンプレートエンジン <?php $opt= getopt("", array("datadir:", "basedir:", "tmpdir:", "slave ", "port:")); $ipaddr= getHostByName(getHostName()); $server_id= ip2long($ipaddr) & 65535; $memsize_kb= exec("head -1 /proc/meminfo | awk '{print $2}'"); ?> [mysqld] .. server-id= <?=$server_id?> <?= isset($opt["slave"]) ? "read_only" : ""?> report-host= <?=gethostname()?> innodb_buffer_pool_size= <?=(int) ($memsize_kb * 0.6)?>K innodb_log_file_size= <?=(int) ($memsize_kb * 0.6 * 0.2)?>K .. 36/63

38. コンフィグテンプレートエンジンメジャーバージョン単位でテンプレートを作っておく罠いパラメーターは⼀度回避すれば⼆度と⾷らわない- パラメーター名の変更とかに追従できる- RC2になったら8.0のテンプレートも作ろうかな- 凝ったことはしない職⼈芸が必要そうなところとかまで⾃動⼊⼒しようとするとテストとか死ぬ - 今まで⼿⼊⼒してたものの8割カバーできれば⼗⼆分 37/63

39. コンフィグテンプレートエンジン report-host [mysql] セクションの prompt server-id 各種ファイル名のパスとかやろうやろうと思っていたメモリー関連のサイジングもそろそろ⼿を付けたい 38/63

40. スキーマテスト「ちゃんとFKを張りましょう」「全てのカラムにNOT NULLをつけて正規形にしてLEFT JOINで表現しましょう」「命名規則はこうです」 39/63

41. スキーマテスト「アイエエエエエエ︕︖ FKナイ︕︖ ナンデ︕︖」あるいは「なんでここ ON DELETE CASCADE になってんの」- 消えちゃったじゃん…- NULLABLEなカラム＿⼈⼈⼈⼈⼈⼈＿＞ PKがない＜￣Y^Y^Y^Y^Y^Y￣ 40/63

42. スキーマテスト「ちゃんとFKを張りましょう」「全てのカラムにNOT NULLをつけて正規形にしてLEFT JOINで表現しましょう」「命名規則はこうです」 …とちゃんと合意が取れてても、typoだったりうっかりだったりってことはある 41/63

43. スキーマテストアプリのCIの中に「DBのスキーマをリストアし、スキーマを評価する」テストを追加リストア先はDockerコンテナ、CIのたびに1コンテナ起動してテストが終わると停⽌する - information_schema の tables, columns, statistics を⼒押しする変わりどころでは key_column_usage, referential_constraints あたりでFKのルールも評価する - 名前空間のルールを決めておくと機械的に評価が可能同じ名前のカラムは原則FKが張ってある、とか- ルールから逸脱した部分だけ書けばいい- 42/63

45. mikasafabric for MySQL １つのシステムをロードバランサ、スイッチ、サーバ、ミドルウェア、ログ集約サーバなど完全に冗⻑化しておき、１週間毎に冗⻑化されたシステム、A、Bをそれぞれ⼊れ替える。式年遷宮Infrastracture · さよならインターネット (c) kenjiskywalker- 44/63

46. mikasafabric for MySQL マスターとスレーブが気軽に⼊れ替えられる構成アプリケーションからは127.0.0.1のmysqlrouterに接続しているようにしか⾒えない - mysqlrouterから本物のマスター/スレーブにルーティングされるので、アプリケーションからは透過的にフェイルオーバーできる - ⼿動のpromoteなら2〜3秒でスイッチオーバーが完了する- スレーブをバージョンアップ ⇒ スイッチオーバー ⇒ スレーブになったもともとのマスターをバージョンアップ - 45/63

47. mikasafabric for MySQL ap01 mysqlrouter AP 127.0.0.1:3306 ap02 mysqlrouter AP fabric-host mysqlfabric mysqld 構成情報 db01 mysqld db02 mysqld 死活監視＆Failover マスター問い合わせ 127.0.0.1:3306 46/63

48. mikasafabric for MySQL もともとは Master/Slave 1台ずつでSlaveがホットスタンバイ(=PXCやInnoDB Clusterよりも規模が⼩さいHA構成) のやつを管理するためにMySQL Fabricにパッチを当てていた現在、最⼤でフツーのAsync Mater/Slave 構成20台くらいをさばかせている負荷が⾼い環境だと深刻なファイルディスクリプターリークがあってだな…（Python詳しい⼈誰か）「datadirをtypoした︕」とかしょーもない理由でMySQLを再起動できる快感 47/63

49. 後追いできるリソース監視基本はCPU使⽤率やアプリ側の監視でスタートするけど調査の過程で「あー、この項目のポーリングしてればよかった」ってことがよくあるかといって常⽇頃⾒るわけでもないので、わざわざ収集しておくのも結構しんどい - See also, アドオンした死活（︖）監視 ⇒ 問題があった時のログを詳細に残す 48/63

50. PMP for Cacti 49/63

51. PMM 50/63

52. 現在の状況 51/63

53. 後追いできるリソース監視 yoku0825/anemoeater スローログを遡って分割して投⼊することでグラフを表⽰ Dockerコンテナと組み合わせて「⾒たくなったら起動」「⾒終わったら停⽌」の運⽤レス可視化 - スローログさえ残っていればいつでも任意の時点のグラフを⾒られる 52/63

54. 後追いできるリソース監視 ytkit/yt-binlog-groupby · yoku0825/ytkit バイナリーログをGROUP BYするためのスクリプト(time, table, statement)に対応 - バイナリーログさえ残っていればいつでも任意の時間帯でどのテーブルがホットスポットになっていたかわかる - 53/63

55. 後追いできるリソース監視あと SHOW GLOBAL STATUS, SHOW GRANTS, SHOW VARIABLES, SHOW TABLE STATUS とか p_s.events_statements_summary_by_digest とか取って保管してみるとかしてる普段はただデータを保管（MySQLに突っ込んでる）するだけで、⾒たくなったら re:dashのコンテナー起動してSQL叩いてグラフにする拡張がすごく楽（SELECTで値を取ってINSERTするだけだから）実際に⾒たくなった時に「どう⾒るか」を考える- 54/63

56. たとえばクエリーダイジェストごとのrows̲examined 55/63

57. たとえばテーブルサイズ 56/63

58. あとこまごましたことバイナリーログ, リレーログ, エラーログ, スローログの名前は指定するホスト名に依存させない- ファイル名を固定することで、psshやtmuxとの相性が良くなって効率アップ - 57/63

59. あとこまごましたこと⼀括でログインして tail -f とかできる 58/63

60. あとこまごましたことテーブルサイズは⼤きくしすぎない, 無駄なスレーブを作らないログテーブル、パーティショニングじゃなくてテーブルごと、⽉ごとにテーブル分けるのだってまだまだメリットがある - テーブルサイズが⼗分⼩さくて数秒で終わるなら、あるいは数⼗分でも遅れていいスレーブだけなら、サービスを⽌めずにInnoDBのオンラインALTER TABLEで本当にオンライン - 59/63

61. あとこまごましたことバージョンはなるべく新しい⽅がいい特にモニタリング⽅⾯- 4.0とか5.0とかもう耐えられないざくざくサポートを切ると作りこみが楽 - OSのバージョンも統⼀できるとコマンド違わなくて楽- 60/63

62. まとめ管理台帳死活（︖）監視ログ監視コンフィグテンプレートエンジンスキーマテスト mikasafabric for MySQL 後追いできるリソース監視あとこまごましたこと 61/63

63. ⼿を抜くための⼿間を惜しまない 62/63

64. Questions and/or Suggestions? 63/63