MySQL監視ベストプラクティス
技術本部 サービスリライアビリティグループ（SRG）の鬼海（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
なにかの役に立てば幸いです。
このドキュメントの目的アラートトリガーにすべき値MySQLプロセス死活監視MySQLプロセスの起動時間監視レプリケーションステータスの監視コネクション数の監視ディスク残容量の監視スレーブでread_onlyがONになっているか注目すべきメトリクスと取得方法スローログ件数現在のスレッド数クエリの秒間発行件数クエリのレイテンシレプリケーション遅延秒数メトリクス取得ソリューションPercona Monitoring and Management(PMP)SaaSでのリソース監視終わりに
このドキュメントの目的
MySQLを運用していく上での監視の勘所をまとめています。
メトリクスを取得する方法とそれぞれの項目についても解説します。
アラートトリガーにすべき値
MySQLで障害が起きた際にいち早く気がつけるようなアラートトリガーを設定しましょう。
直ちに確認・対応したほうがよい値は 、翌営業日の確認でよいものは にするなどのレベル分けをして、アラート通知が多すぎてつらいということにならないようにしましょう。
MySQLプロセス死活監視
MySQLのプロセス自体が生きているかの監視です。
OOM Killerなどの理由でプロセスが突然死した場合に検知できるようにします
MySQLプロセスの起動時間監視
下記のコマンドを利用するとMySQLが起動してからの時間を確認できます。
ここの時間が短いということはMySQLが再起動が発生したということがわかります。
レプリケーションステータスの監視
スレーブが正常にレプリケーションを組めているかの監視です
と が両方Yesであること
が0であることを監視しましょう
コネクション数の監視
(現在の接続数)÷(上限接続数)の割合で監視しましょう。
上限を超えてしまうとMySQL接続エラーであるToo many connectionsがでてしまいます
余裕を持った上限設定にしておきましょう
ディスク残容量の監視
OSの監視になりますがデータベースはデータ使用量が増え続けていく事が多いので、適切に監視しましょう。
ディスク使用率がギリギリになりすぎるとできる対応も限られてきてしまうので、7割ぐらいの使用率を超えたらアラートで気がつけるようにしたほうがよいです。
スレーブでread_onlyがONになっているか
スレーブ側のDBで間違えてUPDATEなどの更新を実行しないための設定です。
MySQLのrootユーザの場合はこのread_onlyが無視されてUPDATEなども実行されてしまうので、普段の運用オペレーションではrootユーザを使わないようにしましょう
MySQL5.7以降からはrootでの更新も禁止する`super_read_only`という設定も追加されています
注目すべきメトリクスと取得方法
リソースのメトリクスは障害の原因調査に役立ちます
障害発生前、障害発生中、障害収束後の3つの時点のメトリクスを比較することで、
原因の特定に繋げやすくなります。
MySQLのリソースのメトリクスはSHOW GLOBAL STATUSなどの結果を元にグラフ化することが多いです。SHOW GLOBAL STATUSの各項目の値はその時点での値（瞬間値）とMySQLが起動してから現在までの累計値（累積値）の2種類が存在しています。
それぞれの値がどちらの値なのかは明文化されていないため、予め用意されているソリューションを用いて取得するのをおすすめしています
スローログ件数
実行に指定した閾値以上の時間がかかったクエリが記録されています
現在のスレッド数
MySQLが現在実行中のスレッドの数です
このメトリクスが平時より突出して高い場合は、アプリケーションの不具合でコネクションを異常に張っているか、DBが他の理由でスローダウンしているせいでアプリケーションが再接続をしつづけているかなどの理由が多いです
クエリの秒間発行件数
これの取得は下記の章で紹介してるソリューションで可能で
秒間でどれぐらいのSELECT、UPDATEが来ているのかを確認します。
これらが以前と比べて大幅に跳ねている場合は想定以上のアクセスが来ているか、
アプリケーションのバグでクエリ数が増えているかを疑います。
逆に、クエリ数は増えていないのにレイテンシが悪化している場合は単発が重いクエリが増えている可能性を疑いましょう。
クエリのレイテンシ
クエリ自体の平均レイテンシや、閾値を超えたスロークエリの発生数で確認します。
これらも下記のソリューションで取得可能です。
重いクエリが増えている場合、クエリ数（アクセス数）の増大でDB自体が重くなって遅くなっているのか、アクセスはそこまで増えておらずクエリ自体が高コストでDBが重くなっているかを見極めましょう。
レプリケーション遅延秒数
レプリケーションの何秒遅延しているかの値です。
継続的にレプリケーションが遅延しつづけているのか、断続的に遅延して収束を繰り返しているのかを確認します。
前者の場合非常に重い更新クエリを実行してしまったか、デッドロックなどの理由が考えられれます。
後者の場合はクエリ数が増えていた場合はDBスレーブの性能が追い付かなくなっている可能性が考えられます。
メトリクス取得ソリューション
以下のソリューションでは、
やの結果をパースしてグラフ化などをしています。
また一部ではperformance_schemaのテーブルから情報取得しているものもあります。
Percona Monitoring and Management(PMP)
Percona社が開発しているソリューション
情報を蓄積するPMM Serverと収集するPMM Clientがあります。
一通りのリソース情報がダッシュボードで用意されています。
SaaSでのリソース監視
MackerelはMySQLのリソースを収集するためのプラグインが提供されています
Datadogは標準のdatadog agentのパッケージにMySQLリソース収集機能が含まれています。
AWSのRDS（Aurora)を利用する場合はパフォーマンスインサイトを有効にしましょう。
終わりに
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
