Weitere ähnliche Inhalte
Ähnlich wie MongoDBのアレをアレする (20)
Mehr von Akihiro Kuwano (20)
Kürzlich hochgeladen (11)
MongoDBのアレをアレする
- 2. アジェンダ
MongoDBCasual
もんごたんについておさらい
運用時にあったこと集
障害時何見る?
まとめ
12年7月8日日曜日
- 3. 自己紹介
桑野章弘
サイバーエージェント
Ameba を運営しています。
ピグライフの運用/構築を担当
Twitter
@kuwa_tw
Blog
http://d.hatena.ne.jp/akuwano/
著書/活動
「MySQLによるタフなサイトの作り方」
12年7月8日日曜日
- 14. サービス情報
ピグライフ
2011/05/31オープン
会員数360万人(2012/01現在)
ピグアイランド
2012/05/22オープン
リリース後5日で会員数100万人突破
8
12年7月8日日曜日
- 15. ピグライフのアーキテクチャ:全体構成
BackEnd
FrontEnd
ユーザ/エリ
staticサーバ Node.jsサーバ
Socketサーバ ア等の状態
データ
mongodbサーバ
Flashデータ 必要なデータ
→リクエス の取得
ト/取得
HTTP
WebSocket接続
・ユーザ情報
・チャット
データ
→リクエス
ユーザ ト/取得
(ブラウザ)
11
12年7月8日日曜日
- 17. アーキテクチャについて
システムアーキテクチャ
冗長化
ReplicaSets
スケーラビリティ
Sharding
13
12年7月8日日曜日
- 18. アーキテクチャの課題
ReplicaSets
相互死活監視&投票により冗長性を保つ。最小単位は
3台。
プライマリ
セカンダリ セカンダリ
23
12年7月8日日曜日
- 19. アーキテクチャの課題
ReplicaSets
相互死活監視&投票により冗長性を保つ。最小単位は
3台。
生きているサーバ プライマリ
で投票が行われ新
しいプライマリが
選ばれる
セカンダリ セカンダリ → プライマリ
24
12年7月8日日曜日
- 20. アーキテクチャの課題
Sharding
データをChunkの細かい粒度に分割し、各
mongodに分散して渡すことで各サーバの負荷を分
散します
19
12年7月8日日曜日
- 21. MongoDBの構成
Sharding
アプリケーションサー ReplicaSetsに
データをChunk
バ よりサーバの冗長
の単位に分ける
性を確保
DATA
mongos
Mongod[ShardA]
Mongod[ShardB]
mongoc
Mongod[ShardC]
20
12年7月8日日曜日
- 22. MongoDBの構成
Sharding
アプリケーションサー ReplicaSetsに
データをChunk
バ よりサーバの冗長
の単位に分ける
性を確保
ChunkA ChunkB ChunkC
mongos
mongocは
Mongod[ShardA]
シャーディング情
報を持つ
Mongod[ShardB]
mongoc
ChunkA -> ShardA
ChunkB -> ShardB Mongod[ShardC]
ChunkC -> ShardC
21
12年7月8日日曜日
- 23. MongoDBの構成
アプリケーションサー ReplicaSetsに
バ よりサーバの冗長
Sharding
データをChunk 性を確保
の単位に分ける
mongos
mongocは
ChunkA Mongod[ShardA]
シャーディング情
報を持つ
ChunkB Mongod[ShardB]
mongoc
ChunkA -> ShardA
ChunkB -> ShardB ChunkC Mongod[ShardC]
ChunkC -> ShardC
22
12年7月8日日曜日
- 24. アーキテクチャの課題
MongoDBのこれら機能により、アプリ側の実
装コストは軽く、スケーラビリティを保ったシス
テム構築を手軽に使うことができます。
サーバレベルの細かなチューニングは基本的には
必要ありません(できない)と言う所は大きなメ
リット
サーバアーキテクチャをもんごに合わせていくイ
メージ
25
12年7月8日日曜日
- 30. あれ、クラスターが遅いよ?
必要なデータを一気にデータをインポートする
oplogデータ量範囲を超えてレプリケーションが停止
一度に入れたため、PrimaryShardにChunkが溜まって
しまいI/Oバウンドに
負荷が高いのでBalancerは動かない
_人人 人人_
> 突然の死 <
 ̄Y^Y^Y^Y ̄
32
12年7月8日日曜日
- 31. あれ、クラスターが遅いよ?
シャードするコレクションを、シャード設定漏れ
PrimaryShardでデータファイルが多くなり続けてメモリ
マップドファイルのサイズを超えたためI/Oバウンドに
シャードしてないのでもちろんBalancerは動かない
_人人 人人_
> 突然の死 <
 ̄Y^Y^Y^Y ̄
32
12年7月8日日曜日
- 32. シャード設定の不備に関して
ほんとに突然パフォーマンスダウンする
「10分前は快調だった、、、」「みんなそういうの」
PrimaryShardは潤沢な状態にしておく
シャード設定は定期的に確認、もしくはシャードの設定を自
動化する
32
12年7月8日日曜日
- 33. 運用スクリプト
台数がおおくなってくると「標準のコマンドだと表示
が辛いとか」「今のマスターの一覧が欲しいな」とか
があるのでそのへんはスクリプト作成して対応
このへんが作りやすいのは魅力
32
12年7月8日日曜日
- 34. 運用スクリプト:内容
ロックタイムの取得
シャードに入っているmongod一覧のリスト出力
レプリカセットのマスター検索
レプリカセットのプライオリティ検索
printShardingStatusの整形
レプリカセット一括作成
32
12年7月8日日曜日
- 35. バックアップ
mongodump
mongosに対してmongodump実行するのはバックアッ
プとしては一番簡単だけど、稼働中にかけると完全なポイン
トイン・タイムのバックアップにはならないよ
35
12年7月8日日曜日
- 36. バックアップ
稼働中にスナップショットバックアップを取得するに
はこんな感じでやりましょう
mongos経由でAutoBalancingをOff
各レプリカセットにfsync lockをかける
各mongodにmongodumpを実行してデータ取得
各レプリカセットにfsync unlock
mongos経由でAutoBalancingをOn
35
12年7月8日日曜日
- 37. ロック
同じサーバ上に異常に書き込みの多いコレクションが
あるとクラスタ全体のアクセスに影響します
現状はクラスタを複数に分けています
アプリ実装はコレクション間を疎結合で作る必要あり
2.2系でコレクションレベルロックが実装されるとこ
のような手間はなくなる(予定)です
36
12年7月8日日曜日
- 38. ロック
Collection A Collection B Collection C
37
12年7月8日日曜日
- 39. グローバルロック
Collection A Collection C Collection B
38
12年7月8日日曜日
- 40. グローバルロック
Collection A Collection C Collection B
38
12年7月8日日曜日
- 44. mongostat
トレンドの変化がみたいとか。
現状が把握したいとか。
すべての基本です
12
12年7月8日日曜日
- 45. $ ./mongostat --host 192.168.8.41:27018,192.168.8.62:27018
insert query update delete getmore command flushes mapped vsize res faults
locked % idx miss % qr¦qw ar¦aw netIn netOut conn set repl time
192.168.8.41:27018 0 361 132 0 209 437 0 36.1g 76.2g 14.3g 1
2.2 0 0¦0 2¦0 85k 698k 3056 RSTest1001 M 11:16:57
192.168.8.62:27018 0 384 164 0 245 480 0 30.1g 63.9g 15.6g 0 2
0 0¦0 2¦0 96k 652k 2587 RSTest1002 M 11:16:57
192.168.8.41:27018 0 418 144 0 231 567 0 36.1g 76.2g 14.3g 0
1.9 0 0¦0 2¦0 100k 908k 3056 RSTest1001 M 11:16:58
192.168.8.62:27018 0 465 170 0 255 582 0 30.1g 63.9g 15.6g 1 3
0 0¦0 2¦0 108k 1m 2587 RSTest1002 M 11:16:58
13
12年7月8日日曜日
- 46. mongostat - 見るべき項目
faults - 1秒当りのページフォールト数
Locked % - グローバルライトロックの時間割合
idx miss % - indexのヒット率の時間割合
qr¦qw - 読み込みキュー¦書き込みキュー の大きさ
12
12年7月8日日曜日
- 47. mongostat - 見るべき項目
faults が多い場合
キャッシュメモリ溢れの可能性があるので、メモリ、
もしくはサーバを増設
Locked % が高い場合
書き込みのクエリを見直すか、クラスタを分ける。
qr¦qw が高い場合
サーバ負荷が低ければ、ロックの可能性を疑う。負荷
が高ければ単純なクエリ増による高負荷を疑う。
12
12年7月8日日曜日
- 48. mongostat
discoverオプションで、レプリカセットのメン
バー、クラスタに入っているメンバーを全て抽出する
ことが可能なので利用すると楽
12
12年7月8日日曜日
- 49. mongotop
現在重いmongodのどのcollectionへアクセスがか
かっているかを確認したりとかできまする。
障害の時がメイン
mongostatで状況確認→mongotopでサーバ確認
みたいな
15
12年7月8日日曜日
- 50. $ /usr/local/mongodb2_1/bin/mongotop --host mongos_ip --port 27018
connected to: mongos_ip
ns total read write 2012-05-23T02:14:10
local.oplog.rs 1929ms 1929ms 0ms
life_prd_main.Test 6ms 6ms 0ms
life_prd_main.TestPoint 5ms 0ms 3ms
life_prd_main.Test2Soil 5ms 0ms 5ms
writeに時間
life_prd_main.TestMaterial 1ms 0ms 1ms がかかってい
life_prd_main.TestOnline 1ms 0ms 1ms
る
life_prd_main.Test3 1ms 1ms 0ms
life_prd_main.TestQuest 1ms 1ms 0ms
life_prd_main.TestBan 0ms 0ms 0ms
ns total read write 2012-05-23T02:14:12
local.oplog.rs 1929ms 1929ms 0ms
life_prd_main.TestOnline 0ms 500ms 10ms
life_prd_main.Test2Soil 8ms 0ms 8ms
life_prd_main.Test 5ms 5ms 0ms
life_prd_main.TestPoint 4ms 0ms 2ms
life_prd_main.TestMaterial 2ms 0ms 2ms
life_prd_main.Test3 1ms 1ms 0ms
life_prd_main.TestQuest 1ms 1ms 0ms
life_prd_main.TestBan 0ms 0ms 0ms
17
12年7月8日日曜日
- 51. mtop
標準ツールじゃないよ
mongostatと同じようなデータが取れるけど、
ちょっと足りないです。
今流れているクエリを追える所がメリット、、、だけ
ど db.currentOp()でいいかも。
18
12年7月8日日曜日
- 52. $ ./mtop.py -s 192.168.0.100:27218
192.168.0.100. v2.0.5, 64 bit. Conns: 1304/18696. Lock %: 0.02
Mem: 12182 resident, 37120 virtual, 16617 mapped
Ops: 2816 total, 633 getmore, 0 insert, 523 update, 602 command, 1058 query,
0 delete
ID CLIENT OP A LOCKW NS
1184788867 192.168.0.112:43976 query T
1184789134 192.168.0.149:48588 query T
1184792427 192.168.0.143:36964 query T
1184866702 192.168.0.103:58179 query T
1184867005 192.168.0.126:55974 query T
1184867347 192.168.0.102:36019 query T
1184867986 192.168.0.129:37664 query T
1184868008 192.168.0.151:59313 query T
1184868757 192.168.0.105:46522 query T
1184869686 192.168.0.154:43275 query T
1184870569 192.168.0.107:58733 query T
(snip)
19
12年7月8日日曜日
- 53. mongosniff
最後はパケットキャプチャですので、何か会った際の
アクセス状況の確認が可能
mongosのアクセス状況とか、複雑なクエリを見た
い場合はこれで見るのが良い(これでみるしかない)
です。
21
12年7月8日日曜日
- 54. # mongosniff --source NET eth0 27017
# 以下にパケットがズラズラっと並ぶ
127.0.0.1:55858 -->> 127.0.0.1:27017 testdatabase.TestCol1 89 bytes id:kjkjkjkj 14086840
query: { _id: "1234567891234567" } ntoreturn: -1 ntoskip: 0
127.0.0.1:27017 <<-- 127.0.0.1:55858 205 bytes id:77383268 2000171624 - 14086840
22
12年7月8日日曜日
- 57. # mongo
# プロファイルオンにする。この場合は10ms以上かかった、リード、ライトクエリが入る。
PRIMARY> db.setProfilingLevel(2,10);
{ "was" : 2, "slowms" : 100, "ok" : 1 }
(Profile確認)
{ "ts" : ISODate("2012-07-05T04:13:48.408Z"), "op" : "update", "ns" : "testdatabase.TestCol01", "query" : { "_id" :
"4334521d75462355" }, "updateobj" : { "$set" : { "747465656e80aa0b" : 10 } }, "idhack" : true, "millis" : 0, "client" :
"192.168.0.100", "Test" : "" }
# もとに戻す
PRIMARY> db.setProfilingLevel(0);
{ "was" : 2, "slowms" : 10, "ok" : 1 }
25
12年7月8日日曜日
- 58. Loglevel変更
これもクエリもでるし、MongoDBの動作がおかし
かった場合に必要
ログの量が半端なくなるので注意
26
12年7月8日日曜日
- 59. # mongo
# ログレベルを5(最大)にする。
PRIMARY> db.adminCommand({setParameter:1, logLevel:5})
{ "logLevel" : 0, "ok" : 1 }
(ログ確認する)
# もと(ログレベル0)に戻す
PRIMARY> db.setProfilingLevel(0);
{ "logLevel" : 5, "ok" : 1 }
27
12年7月8日日曜日
- 61. mongos> db.adminCommand("connPoolStats")
{
"hosts" : {
"192.168.0.241:27019::0" : {
"available" : 1,
"created" : 1
(snip)
"createdByType" : {
"master" : 175,
"set" : 24,
"sync" : 8
},
"totalAvailable" : 24,
"totalCreated" : 207,
"numDBClientConnection" : 215,
"numAScopedConnection" : 28,
"ok" : 1
}
29
12年7月8日日曜日
- 62. db.serverStatus()
サーバの現在の状態の確認
mongostatとか各種状況確認はほぼこれを見ている
見られる項目
Replicasets
Journaling
NW
Index
要するにほとんどすべて
30
12年7月8日日曜日
- 63. PRIMARY> db.serverStatus()
{
"host" : "test-mongo01:27018",
"version" : "2.0.5",
"process" : "mongod",
"uptime" : 731083,
"uptimeEstimate" : 726409,
"localTime" : ISODate("2012-05-23T05:55:14.419Z"),
"globalLock" : {
"totalTime" : 731082571520,
"lockTime" : 21521333332,
"ratio" : 0.029437623286867328,
(snip)
},
"mem" : {
(snip)
31
12年7月8日日曜日
- 64. (snip)
"dur" : {
"commits" : 27,
"journaledMB" : 0.548864,
"writeToDataFilesMB" : 1.069064,
"compression" : 0.48677963816836817,
"commitsInWriteLock" : 0,
"earlyCommits" : 0,
"timeMs" : {
"dt" : 3091,
"prepLogBuffer" : 3,
"writeToJournal" : 305,
"writeToDataFiles" : 17,
"remapPrivateView" : 2
}
},
31
12年7月8日日曜日
- 66. PRIMARY> db. currentOp()
MongoDB shell version: 2.0.5
connecting to: 127.0.0.1:27218/test
{
"inprog" : [
{
(snip)
"opid" : 1654293341,
"active" : false,
"lockType" : "read",
"waitingForLock" : false,
"op" : "query",
"ns" : "testdb.TestPoint",
"query" : {
"_id" : "77667f763200000"
},
"client" : "192.168.0.125:34831",
"desc" : "conn",
"threadId" : "0x7f431322f700",
"connectionId" : 53986,
"numYields" : 0
},
(snip)
33
12年7月8日日曜日