MySQL Clusterを運用して10ヶ月間

MySQL Clusterを
運用して10ヶ月間
MySQL Cluster Casual Talks #2
2014/06/25

誰
❖ いとうひろゆき
❖ サーバ運用/保守が仕事
❖ ネットワークからOS、ミドルウェアまでアプリケーシ
ョン以外はなんでも面倒を見ないといけない(程度の差
はあります)
❖ MySQL好き。酒好き。

お題
❖ サーバ構成
❖ パラメータ検討
❖ サービスインから発生した障害と対応
❖ 監視について
❖ その他
❖ 終わりに

LB
WEB/SQLノード/管理ノード(2台)
データノード
1ノードグループ構成

H/Wに適したパラメータは？
InnoDBみたいなお約束なパラメータはあるの？

データノードのパラメータ
http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndbd-
definition.html

❖ MaxNoOfExecutionThreads (デフォルト2)
❖ ndbmtdのみのパラメータ
❖ 主要な動作スレッドの動作スレッド数が決まる
❖ LDM, TC, Send, Receive Threads
❖ 設定数によってスレッド数は自動設定される
❖ 最大で物理CPUコア数と同じにする(目安)
❖ 7.3系では最大36まで指定可能

❖ ThreadConfig
❖ MaxNoOfExecutionThreadsより詳細に動作スレッドを指定可能
❖ 設定例
❖ ThreadConfig=main={cpubind=1},ldm={count=4,cpubind=2,3,8,
9},recv={cpubind=5},rep={cpubind=7},io={cpubind=4}
❖ 各スレッドがどのCPUコアで動作するか固定される(taskset的な)

❖ Numa (デフォルト1)
❖ /proc/[ndbmtdのPID]/numa_maps を見る限り numactl --
interleave=all で起動してくれる
❖ NUMA環境ならSwap Insanity対策のためにも
❖ ODirect(デフォルト0)
❖ innodb_flush_method=O_DIRECTと同様ダイレクトIOを使用

❖ TransactionDeadlockDetectionTimeout(デフォルト1200)
❖ 設定値の単位はmsなので1.2秒がデフォルト
❖ tcがクエリ実行を待てる時間。innodb_lock_wait_timeoutに近い
感じ。大きすぎるとデッドロック待ちでクエリが滞留してしまう
事がある。大きすぎる設定値はMaxNoOfConcurrentScansの上限
に引っかかる原因になったりする。

❖ MaxNoOfConcurrentScans(デフォルト256, 最大500)
❖ スキャンクエリの最大並列実行数(テーブルスキャン、インデッ
クススキャンで利用される)
❖ データノード単位で持つのでデータノードの数が2個なら最大並
列実行数は1000になる
❖ InnoDBには無い制限なので瞬間的に大量のアクセスが来た場合
にSQLノードのエラーログにToo many active scansと出力され
ていることがあります

❖ MaxNoOfConcurrentTransactions(デフォルト4096)
❖ データノード全体で同時実行可能なトランザクション数(でも1ト
ランザクションで1消費するわけではない)
❖ MaxNoOfConcurrentScansと同様データノード単位で持つ値
❖ マニュアルより計算式
❖ TotalNoOfConcurrentTransactions = (maximum number of
tables accessed in any single transaction + 1) * number of
cluster SQL nodes

❖ NoOfFragmentLogFiles(デフォルト16)
❖ Redoログのファイル数。
❖ FragmentLogFileSize(デフォルト16MB)
❖ Redoログ1つのファイルサイズ
❖ デフォルトの場合 NoOfFragmentLogFiles * 4 *
FragmentLogFileSizeで1024MB
❖ The default parameter value is 16, which by default means 16
sets of 4 16MB files for a total of 1024MB)

SQLノードのパラメータ
http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-program-
options-mysqld.html

❖ ndb-cluster-connection-pool(デフォルト1)
❖ SQLノードがデータノード1つ辺りに接続する数
❖ 増やすと接続数が増えるので負荷状況次第で性能が向上
❖ 但し増やすとSQLノードとしてのNodeIdが消費されるため、
config.iniに書く[MYSQLD]の数を増やす必要がある
❖ query_cache_type, query_cache_size
❖ MySQL Cluster環境では無効にする

サービスインから発生した
障害と対応

障害1
❖ SQLノードのエラーログに以下内容が出力
❖ [ERROR] /usr/local/mysql/bin/mysqld: Got temporary error 245 'Too many
active scans' from NDBCLUSTER
❖ 対応
❖ そもそも受けきれないのならフロントのWeb(Apache)のMaxClientsを下
げる(一時しのぎ)。
❖ TransactionDeadlockDetectionTimeoutをリトライ処理しっかりしてるな
ら小さくする
❖ クエリの見直し

障害2
❖ データノードのログに以下内容が出力
❖ Signal lost, out of long signal memory, please increase
LongMessageBuffer (Resource configuration error)
❖ 対応
❖ LongMessageBufferを増やす。
❖ 使用していたバージョンではデフォルトが4MBだった
❖ This parameter seldom needs to be changed from the default.
❖ 7.3.5から64MBがデフォルトに(#^ω^)ビキビキ

障害3?
❖ 仮想環境のndbd 3 x 2ノードグループをndbmtdの3 x 1ノ
ードグループへ変更する際に発生。
❖ 良くない事に時間がなく、ノードグループ数が変わる場
合にstart backupで取れるバックアップデータを使用出
来るか検証出来なかった。そのためmysqldumpしてリス
トアを試みました

障害3?
❖ 結果、見事にリストア時にエラーが発生
❖ 出力メッセージ
❖ Got temporary error 410 'REDO log files overloaded (decrease
TimeBetweenLocalCheckpoints or increase NoOfFragmentLogFiles)' from
NDBCLUSTER
❖ マニュアル見る(http://dev.mysql.com/doc/refman/5.6/en/mysql-
cluster-ndbd- definition.html#ndbparam-ndbd-
timebetweenlocalcheckpoints)

障害3?
❖ マニュアルより
❖ All the write operations in the cluster are added together. Setting
TimeBetweenLocalCheckpoints to 6 or less means that local
checkpoints will be executed continuously without pause,
independent of the cluster's workload.
❖ TimeBetweenLocalCheckpointsを6以下にしてリストア
して成功
❖ しかしndbmtdの再起動が発生したため大きく時間ロス。

障害4
❖ デイリーのcronのタイミングでndbmtdが落ちる
❖ 出力メッセージ
INFO -- Internal program error (failed ndbrequire)
INFO -- DBTC (Line: 7783) 0x00000002
INFO -- Error handler shutting down system
INFO -- Error handler shutdown completed - exiting
ALERT -- Node 20: Forced node shutdown completed. Caused by
error 2341: 'Internal program error (failed ndbrequire)(Internal error, programming error or
missing error message, please report a bug). Temporary error, restart node'.

障害4
❖ 環境依存せず複数環境で発生
❖ 最悪のケースで全部のデータノードが停止(1回だけ)
❖ 気付いたらスワップ使っていた
❖ I/O負荷の高いであろうcron(updatedb実行)を停止
❖ スワップとの兼ね合いでTimeBetweenWatchDogCheckに引っか
かって停止したと考えられたため
❖ ついでにvm.swappiness = 0 に設定

データノード
❖ CPUコア毎の使用率を監視
❖ ロードアベレージ監視やCPU使用率監視(全体)はあまり役に立た
ない
❖ 負荷の高い状態でもロードアベレージがほとんど上がらない(せ
いぜいldmスレッド数+1,2ぐらい)

データノード
❖ ネットワークトラフィックを監視
❖ データノードの特徴として負荷が無い状態でもネットワークトラ
フィックが発生する
❖ 極端にトラフィックが発生しなくなったら何かしら異常が発生し
ているためアラートとする
❖ 負荷が無い状態でも100Kbps前後は常時トラフィックが発生
❖ 現在サービス中のデータノードでは負荷が最も低い時間でも
10Mbps前後で推移

データノード
❖ DataMemory, IndexMemoryの使用率監視
❖ 管理ノード(ndb_mgmd)で定期的にチェック
ndb_mgm> all report memoryusage;
Connected to Management Server at: localhost:1186
Node 1: Data usage is 30%(177824 32K pages of total 589824)
Node 1: Index usage is 11%(44203 8K pages of total 393344)
ndb_mgm>

SQLノード
❖ 通常のMySQLと同様、接続監視は必須
❖ 但しengine=ndbなテーブルに対する参照や更新処理が行えるか
設定するべき
❖ DBのデータがデータノードにあるMySQL ClusterだがSQLノードも
割とリソース消費するので一般的な監視は行い、台数を増やすタイ
ミングに気を配る

OS周り
❖ パケットドロップやエラーは発生しにくいように設定
❖ NICのリングバッファは最大に(RXは必須)
❖ RSS対応NICを使用する
❖ データノードでスワップ発生は致命的
❖ vm.swappiness=0に設定しつつメモリに余裕があるか安定するま
では気を配る

使用バージョン
❖ MySQL Clusterに関してはリリースされている最新バー
ジョンを使用する
❖ 7.2系と7.3系でJOINの性能がクエリによって本当に30倍ぐらい差
が出るため
❖ 7.2系だと30秒前後かかるが7.3系だと1秒もかからないクエリ
に実際に遭遇

❖ MySQL Clusterは通常のMySQLと比較するとレンジ系のク
エリ、セカンダリインデックスを使用したクエリが苦手。
かつ結構制限があるので注意が必要
❖ 設定を間違えない限りは1台ダウンしてもサービスは継続
するので運用している側からすると喜楽
❖ 落ちたら起動すれば自動的に復旧する
❖ 主キーに対するconstなSELECTはひたすら速いしクエリに
よってはデータノードを増やせば勝手にスケールする
❖ 新しいバージョンならJOINも十分高速

❖ MySQL Clusterは標準機能として冗長化される、クエリ
によってはノードを増やせばスケールするといったメリ
ットはあるが、先に挙げた通り向き不向き、制限がある
ので通常のMySQLの方が向いているケースも多いので
事前に十分に検討を行って下さい

MySQL Clusterを運用して10ヶ月間

More Related Content

What's hot (19)

Viewers also liked (13)

Similar to MySQL Clusterを運用して10ヶ月間 (20)

MySQL Clusterを運用して10ヶ月間