MySQL Cluster Casual Talks #2参加メモ
とりあえず
MySQLClusterCasualTalksに参加させて頂いたので今更ですが個人メモのまとめです。パラメータ名はきっとtypoがありそうで、かつ後半になるといい加減になっていくのもいつもの通り。はー、仕事でMySQL Cluster作りたい。
http://atnd.org/events/50736
ちなみに、id:garage-kid さんの方が奇麗にまとまっていますのでそちらを読む方がオススメです。
http://garagekidztweetz.hatenablog.com/entry/mysql-cluster-casual-talks2
とても参考になる会でした。参加させて頂いてありがとうございました！
MySQL運用話
http://www.slideshare.net/hiroi10/mcct2-pub
データノードパラメータ
MaxNoOfExecutionThreads
ndbmtdのみパラメータ
スレッド系のパラメータ→CPUコアと同じ数くらいが良さそう
ThreadConfigでより詳細に設定できるが、ここまでのパラメータはまだ使っていない
Numa
ODirect
TransactionDeadlockDetectionTimeout
ms単位のタイムアウト
クエリ実行で待てる時間
MaxNoOfConcurrentScans
スキャン系での並列実行数
データノード単位での設定
MaxNoOfConcurrentTransactions
デフォルト小さすぎ
データノード全体で同時実行可能なトランザクション数
１トランザクションで１消費とは限らないので、デフォルトの４０９６だと小さい
NoOfFragmentLogFiles
redoログ、これ関連のパラメータ
SQLノードパラメータ
connection-pool
コネクションプール数
ノードIDが消費されるので増やしすぎるとよろしくない
実運用では２
クエリキャッシュは無効
サービスインしてから発生した障害と対応
序盤の半年くらい
SQLノードのエラーログに too many active scans タイムアウト小さくしつつ、アプリでリトライ
データノードのログに LongMessageBufferが枯渇
昔のデフォルトは４Mで、7.3ではデフォルトが６４Mに…
ndbd から ndbmtd への移行
mysqldumpで吸って戻せるかでテスト
リストア中にエラー
NoOfFragmentLogFilesを増やす
TimeBetweenLocalCheckpoints を６以下でリストア成功
２０Gくらいのデータ
ndbmtdがcronタイミングで落ちる
スワップ使ってた
cronいくつかoff
TimeBetweenWatchDogCheckに引っかかって停止
vm.swappiness = 0 (Cent5系)
監視
データノードはCPUコア毎の状況を見た方がよい
ldmスレッド数+1,2くらいのロードアベレージに落ち着く
NWトラフィック監視
基本トラフィックが流れているので、逆にトラフィックが流れていない状態は異常
大体100kbpsくらいは常時流れている
管理ノードでDataMemory,IndexMemoryの監視
SQLノードは死活監視
CPU使用率はSQLノードの方が割と使う
単キー更新系で6,7万qpsとか出せる
パケドロとスワップ
NICのリングバッファを最大に
まとめ
最新バージョンを使いましょう
JOINで30倍くらい早くなったクエリがあった
レンジ系、セカンダリインデックスまわりが苦手
mac mini で mysql cluster
http://www.slideshare.net/cyberweb1/mac-minimysql-cluster
OpenPNE2の開発してる
42Uラックが事務所兼自宅においてて1G×７本
電気代で２０万くらい
SSDで構成、Macのthunderbolt2接続で1G越えでのIO帯域、２５万IOPSくらい
その上にVirtualBOXでUbuntu
WordpressのためのMySQLCluster環境
WordPressはデフォルトテーブルを明示的にndbへ変更をかける
１００万記事くらい入れても平気
OpenPNEでも対応させる方向で実験中
Macmini向けのthunderboltを使ったPCI拡張カード
HPさん
http://h50146.www5.hp.com/services/ci/opensource/pdfs/HP_OpenServices.pdf
管理ノード２、データノード２、SQLノード２、１０GE接続、データノードにioDrive
パラメータチューニングの確認
データノードでのioDrive効果
ディスクテーブルにioDriveを使う
デフォルトではMaxNoofExecutionThreadsネックになってノード増やしてもスケールしない
MaxNoofExecutionThreadsを１６に増やした
２台に増やしたときに1.7倍くらいにスケール
ThreadConfigでいじるとスケールがリニアな２倍まで到達
データノードのCPUは、40%くらい。SQLノードのCPUネック（おそらくNW部分）になった
connection-pool設定すると１台あたりの性能が２倍になったため、最初の４倍くらいまで来た
データノードのCPUが60%くらいで、SQLノードのsysも減ってCPUの使われ方がいい感じに
Elaps
チューニングするとelapsも短くなっている
ディスクテーブルのioDrive化
ext4
DiskPageBufferMemory でキャッシュを意図的に少なく
スループットが1/3のレイテンシが1.5倍くらい
NWは4Gbpsくらいは出ちゃう
データノードでメモリテーブルで台数が必要なケースについて、ディスクテーブルを使うことでデータノード数を削減できればラッキー
ndbmtdを使う
