INFORMATION_SCHEMA
SHOW
コマンドをも凌駕する情報量 バージョンを追うごとに内容が充実
SHOW
コマンドでは得られない情報多数 SELECT
でアクセス可能 必要な情報を得るため柔軟に絞り込みが可能
JOIN
、サブクエリを利用可能 GROUP BYによる統計
CASE
句による柔軟な出力 よく使う
SELECT
にビューを定義可能
作業の効率化応用はあなた次第！
ログ
エラーログ
問題が起きたらまず見るべき
クライアントへ返されたエラーは記録されない
クライアント側でログを持っておくと便利 一般クエリログ
MySQL
サーバーへ送られたリクエストが記録される
アプリケーションのデバッグ用 スロークエリログ
時間がかかったクエリが記録される バイナリログ
レプリケーションやPIT
リカバリに利用されるデバッグ版を利用する
デバッグ版の入手方法
バイナリ版ならmysqld-debug
ソースコード
〜5.1 configure … --with-debug
5.5 〜 cmake … -DWITH_DEBUG
DBUG パッケージによるトレースが可能
my.cnfにてdubugオプションを記述
mysqld
のコードパスが一目瞭然 アサーションが通常版よりも多い
OSの情報
統計情報（UNIX
系OS
）
mpstat
、vmstat
、iostat
、top
最近話題のdstat
/procファイルシステム
システムの情報を一括で取得
Windows
アクセサリ＞システム＞システム情報 systeminfoコマンド
OSX
system_profiler
Oracle Solaris
Oracle Explorer Data Collector
Linux
sosreport
MySQL Enterprise Monitor
MySQL 専用の商用監視ツール
200 を超えるアドバイザルールが総合的にヘルスチェック
メール、 SNMP による通知
システムリソースや使用状況をグラフで表示
パフォーマンス解析の強い味方
最強のモニタリング機能
レプリケーションモニター
クエリアナライザ
商用サポート
解析のプロが責任をもってお答えします！！
自ら解析できる場合でも時間の節約に
サブスクリプションの一貫としてサポートを受けられる 商用ツールが利用可能（ Enterprise Edition ）
MySQL Enterprise Monitor
MySQL Enterprise Backup
ThreadPool
プラグイン
認証プラグイン 24 時間 365 日のサポート
ただし日本語は平日9
時〜5
時のみ（緊急時は英語で問い合わせ）トラブルを未然に防ぐ
運用のベストプラクティス
•
バックアップはしっかり計画的に！•
本番投入前に必ずアプリケーションのテストを。 負荷に見合ったハードウェアを選定。
•
要件に合致した高可用性構成をチョイス。 スタンドアロン？HA？レプリケーション？MySQL Cluster？
ディザスタリカバリは必要か？
もしもの時の保険＝サポート
•
セキュリティは万全に。•
監視は抜かりなく。 トラブル、キャパシティ、性能
全部まとめてMySQL Enterprise Monitorはいかが？•
メンテナンスは無理のない計画＋周到な準備を。参考：対策とダウンタイムの目安
対策 要件 ダウンタイムの目安
バックアップからのリストア バックアップの取得 データ量次第だが数時間〜
クラッシュリカバリ サーバー１台
InnoDBの利用
数分〜数十分
HAクラスタのフェイルオーバー
サーバー２台共有ストレージ
数分〜数十分
MySQL Clusterのフェイルオーバー
サーバー３台以上ネットワーク冗長化
〜数秒
レプリケーションのフェイルオーバー サーバー２台以上 数秒程度
メンテナンス計画
メンテナンスの種類
テーブルのメンテナンス
インデックスやカラムの追加・削除
データ型変更
古いデータの破棄
テーブルの破損 アップグレード
バグ修正
新しいバージョンの新機能を使いたい システム構成の変更
オプションの変更
ディスクやCPU、メモリの強化テーブルのメンテナンス
テーブル定義変更
ALTER TABLE
は更新がブロックされる。
基本はテーブルを全件新しい型のテーブルにコピー InnoDB Plugin/MySQL 5.5
のInnoDB
ではインデックス部分だけ を再構築 MySQL Cluster
はオンラインスキーマ変更に対応 古いデータの破棄
RANGE
パーティショニング DELETEを使う場合はこまめにCOMMIT
アップグレード
失敗しないためには周到な準備を！
アップグレード後の動作確認
作業時間の見積もり
本番環境と同じデータを使って手順を確認 レプリケーションの活用でダウンタイム縮小
スレーブのバージョン ＞ マスターのバージョン
メジャーバージョンの差はひとつまで
手順
スレーブをひとつずつアップグレード後、スレーブのひとつをマスターに 昇格
旧マスターをアップグレード
必要があれば旧マスターへ切り戻しまとめ
トラブルシューティングのポイント
何が起きているのかを見極める。
仕様を理解する。
何が正常で何が異常なのか？ OS
に詳しくなる。
問題がOSからやってくることも多い。
自分でやってみる。
再現が出来ればこちらのもの！ 的確に対策をする。
トラブルに備える。
Q&A
<Insert Picture Here>
ドキュメント内
MySQLトラブルシューティング技巧解説 〜ビジネスを支える現場のテクニック〜
(ページ 54-72)