それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
エビデンス的なものを貼り付けてもイマイチ伝わらないので、文字通り雑記レベルで。 複数セッション用意してタイミングに依存した実験の結果を伝える時、難しいよね、ってことで、ダラっとした解説になってしまいます。 MySQLのサーバーに重いクエリを投げつけたりしたとき、 クライアント自身を強制終了(mysqlクライアントを「kill -9」とか)すると、サーバー側では処理が続きます。 「SHOW FULL PROCESSLIST」を見るとわかります。 再接続してクエリを投げると、別セッションなのでSHOW FULL PROCESSLIST上、もう1つ増えたところで実行されているのが見えます。 再接続して再実行すると、PROCESSLISTに表示される件数は増える。。。 ゾンビ化したクエリは、要求された処理が終わるまで走り続けて、終わっても返す相手(クライアント)がいないので、そのまま消えていきます
この記事はMySQL Casual Advent Calendar 2017 - Qiitaの9日目のエントリとなります。 実行が長引いたSELECT文を強制終了させるヤーツ MySQL5.6まで、正常に処理が進んでいて遅いSELECTをタイムアウトさせるシステム変数はありませんでした。 正常に処理が進んでいない時のパラメータだと lock_wait_timeout:メタデータロック取得待ち innodb_lock_wait_timeout:レコードロック取得待ち がありました。 正常に処理が進んでいるけど、厳密には「処理中」ではないときに効くパラメータだと net_read_timeout:クライアントからサーバに送り込んだデータの読み込み時間 net_write_timeout:サーバからクライアントへのデータの書き戻し時間 がありました。 他にも、アイドルタイムアウト系で inter
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く