mysqlcasual9

mysqlcasual9

1. 1. MySQL Clusterの トラブル事例 MySQL Casual Talks vol.9 2016/01/22
2. 2. 自己紹介 • いとう ひろゆき • サーバ運用・保守が仕事 • MySQL好き、酒好き • (最近ベンチマークおじさん言われる)
3. 3. 今回のLTについて • 2014年6月に発表した以下のスライド以降に 遭遇したお話になります • http://www.slideshare.net/hiroi10/mcct2- pub
4. 4. お題 • Free Memoryとは？ • 突如滞留するクエリ1 • 突如滞留するクエリ2
5. 5. FreeMemoryとは？
6. 6. MySQL Clusterでは ndb_mgm> all report memoryusage; Connected to Management Server at: ***.***.***.***:1186 Node 1: Data usage is 10%(****** 32K pages of total *******) Node 1: Index usage is 8%(****** 8K pages of total *******) Node 2: Data usage is 10%(****** 32K pages of total *******) Node 2: Index usage is 8%(****** 8K pages of total *******) ndb_mgm> • 管理ノードより各データノードの空きメモリ を確認できます
7. 7. 突然の更新エラー
8. 8. こんなログがSQLノードに 1140 [ERROR] /usr/local/mysql/bin/mysqld: The table ‘t1' is full 1140 [ERROR] /usr/local/mysql/bin/mysqld: The table ‘t2' is full • 原因が割と 。空きはあるのに無いといわれ る
9. 9. 対応 • DataMemoryを増やしてローリングリスタート • 何もせずにローリングリスタートしても使用 不可領域の回収が行われるのか一時的には直 る • データ量が多いテーブルのレコードを削除
10. 10. 突如滞留するクエリ1
11. 11. 定期的に一定時間クエリが滞留 • 最初原因が不明だったが、LCPが終わったタ イミングで復旧していることが判明 • この症状が発生したMySQL Cluster環境では FragmentLogFileSize(REDOログ)が小さいま まだった
12. 12. MySQL Clusterの動き • 更新が多い環境ではほぼ常時LCPが行われる • LCPはDataMemoryに入っている情報をファイ ルとして書き出す処理(永続化のため)。最近の バージョンでは２世代分保存する。 • 書き出している間の更新はGCP(REDOログ)に 保存する
13. 13. REDOログが小さいと • LCPの書き出しが終わる前にREDOログの領域 を使い切ってしまうと、LCPが完了するまでク エリをブロックしてしまう
14. 14. 対応 • FragmentLogFileSizeを増やしてイニシャルロー リングリスタート • 別の対応としてはLCPの書き込み速度が7.3では デフォルト10MB/sなのでこれを増やすのもあ りだと思います
15. 15. 突如滞留するクエリ2
16. 16. 不定期にクエリが滞留 • これも原因が最初不明。発生が不定期だった があるタイミングを境に収束 • 1台のデータノードのログにWARNINGのログ が出力されていることを確認
17. 17. こんなログ [ndbd] WARNING  -- Ndb kernel thread 2 is stuck in: Job Handling elapsed=100 [ndbd] WARNING  -- Ndb kernel thread 3 is stuck in: Job Handling elapsed=100 [ndbd] WARNING  -- Ndb kernel thread 4 is stuck in: Job Handling elapsed=100 [ndbd] WARNING  -- Ndb kernel thread 6 is stuck in: Job Handling elapsed=100 [ndbd] WARNING  -- Ndb kernel thread 7 is stuck in: Job Handling elapsed=100 [ndbd] WARNING  -- Watchdog: Warning overslept 22447 ms, expected 100 ms. [ndbd] WARNING  -- thr: 7: Overslept 4437 ms, expected ~10ms [ndbd] WARNING  -- thr: 6: Overslept 4436 ms, expected ~10ms [ndbd] WARNING  -- thr: 5: Overslept 4439 ms, expected ~10ms [ndbd] WARNING  -- thr: 4: Overslept 4439 ms, expected ~10ms [ndbd] WARNING  -- thr: 3: Overslept 4439 ms, expected ~10ms LCP Frag watchdog : No progress on table 38, frag 15 for 29 s.  336576 rows completed LCP Frag watchdog : No progress on table 38, frag 9 for 29 s.  336576 rows completed
18. 18. 原因 • データノードのサーバはSAS HDD 4本の RAID10で運用していたが、1台のHDDが中途 半端に壊れかけてRAIDコントローラーから切 り離されないせいで発生していた • その結果書き込み待ちになり、書き込みが完 了するまでクエリが応答出来なかった模様
19. 19. 対応 • RAIDコントローラーから見たHDDがFailedに なって自然復旧。。。 • iostatのUtilとかから検知出来そう。また単純に ログを監視しても良さそう。
20. 20. その他 • MySQL Cluster 7.2からは TimeBetweenEpochsTimeoutがデフォルト0になり GCP stopが起きないようになっている • 今回のケースだとTimeBetweenEpochsTimeoutを7.1 の頃の4000とかにしておけばGCP stopが起きて対象 のデータノードのみ停止していたかもしれません
21. 21. まとめ • 前回の発表から1年半ぐらい経過したけどこの ぐらいなので(思ったより)安定してると思いま す。