MySQL Clusterで遭遇したトラブルについて

1. MySQL Clusterの
トラブル事例
MySQL Casual Talks vol.9
2016/01/22

2. 自己紹介
• いとう ひろゆき
• サーバ運用・保守が仕事
• MySQL好き、酒好き
• (最近ベンチマークおじさん言われる)

3. 今回のLTについて
• 2014年6月に発表した以下のスライド以降に
遭遇したお話になります
• http://www.slideshare.net/hiroi10/mcct2-
pub

4. お題
• Free Memoryとは？
• 突如滞留するクエリ1
• 突如滞留するクエリ2

5. FreeMemoryとは？

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. 突然の更新エラー

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. 対応
• DataMemoryを増やしてローリングリスタート
• 何もせずにローリングリスタートしても使用
不可領域の回収が行われるのか一時的には直
る
• データ量が多いテーブルのレコードを削除

10. 突如滞留するクエリ1

11. 定期的に一定時間クエリが滞留
• 最初原因が不明だったが、LCPが終わったタ
イミングで復旧していることが判明
• この症状が発生したMySQL Cluster環境では
FragmentLogFileSize(REDOログ)が小さいま
まだった

12. MySQL Clusterの動き
• 更新が多い環境ではほぼ常時LCPが行われる
• LCPはDataMemoryに入っている情報をファイ
ルとして書き出す処理(永続化のため)。最近の
バージョンでは２世代分保存する。
• 書き出している間の更新はGCP(REDOログ)に
保存する

13. REDOログが小さいと
• LCPの書き出しが終わる前にREDOログの領域
を使い切ってしまうと、LCPが完了するまでク
エリをブロックしてしまう

14. 対応
• FragmentLogFileSizeを増やしてイニシャルロー
リングリスタート
• 別の対応としてはLCPの書き込み速度が7.3では
デフォルト10MB/sなのでこれを増やすのもあ
りだと思います

15. 突如滞留するクエリ2

16. 不定期にクエリが滞留
• これも原因が最初不明。発生が不定期だった
があるタイミングを境に収束
• 1台のデータノードのログにWARNINGのログ
が出力されていることを確認

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. 原因
• データノードのサーバはSAS HDD 4本の
RAID10で運用していたが、1台のHDDが中途
半端に壊れかけてRAIDコントローラーから切
り離されないせいで発生していた
• その結果書き込み待ちになり、書き込みが完
了するまでクエリが応答出来なかった模様

19. 対応
• RAIDコントローラーから見たHDDがFailedに
なって自然復旧。。。
• iostatのUtilとかから検知出来そう。また単純に
ログを監視しても良さそう。

20. その他
• MySQL Cluster 7.2からは
TimeBetweenEpochsTimeoutがデフォルト0になり
GCP stopが起きないようになっている
• 今回のケースだとTimeBetweenEpochsTimeoutを7.1
の頃の4000とかにしておけばGCP stopが起きて対象
のデータノードのみ停止していたかもしれません

21. まとめ
• 前回の発表から1年半ぐらい経過したけどこの
ぐらいなので(思ったより)安定してると思いま
す。