MongoDBのはじめての運用テキスト

MongoDBの運用について

<日付 2011/02/28> 桑野　章弘

1

■はじめに
■概要／特徴
■想定環境
■運用項目
□インストール
・インストール手順
・初期設定ファイル[mongod.conf]
□レプリカセット
○レプリカセット構築
・設定ファイル変更[mongod.conf]
・レプリカセット設定
○ レプリカセット設定変更
・設定確認
・設定テンプレートの内容変更
・設定変更適用
○ レプリカセットステータス確認
・ステータス確認
□シャーディング
○シャーディング構築
・設定ファイル変更[mongoc.conf]
・設定ファイル変更[mongos.conf]
・シャーディング設定
○データベース／コレクションのシャーディング有効化
・データベースのシャーディング有効化
・コレクションのシャーディング有効化
○ シャード、Chunk状況確認
・状態確認コマンド
・シャーディング状態確認[全件表示]
・シャーディング状態確認]
・Chunk移動
・Chunk移動後のシャーディング状態確認
□バックアップ／リストア
○ バックアップ

2

・mongodump
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongodump -v --host 192.168.0.31
--port 27017 -d testdb -c testcollection01 -o /backup/20120608
・mongoexport
○ リストア
・mongorestore
--port 27017 -d testdb -c testcollection01 /backup/20120608/testdb/
testcollection01.bson
・mongoimport
□セキュリティ／ユーザ管理
○ keyfileによるアクセス制御
○ ユーザ作成
○ ユーザ確認
○ ユーザ削除
□コレクション操作
○ コレクション名変更
○ INDEX作成
○ INDEX確認
○ INDEX削除
■チューニング／調査
□チューニング／調査
○ Profiling
・Profiling有効化
・Profiling無効化
○ LogLevel
・LogLevel変更
○ 各種ステータス調査
・mongostat
・mongotop
・mongosniff
・db.stats()
・db.collection.stats()
・connPoolStats
■総評
■参考文献

3

■はじめに
弊社でも、ピグライフをはじめとしてモバイルゲームなどのサービスでMongoDBを使い始
めています。
運用に関してはMySQL等にはまだノウハウ的にはかなわないものの、NoSQLのジャンルの
中では有用なプロダクトであるといえるかと思います。
ですが、運用に関しての共有ができておらず、有効な使い方ができていないパターンも多
いです、そのため運用に関してノウハウを共有するための資料を作成しました。

■概要／特徴
MongoDBには以下のような特徴がある

● BSONによる、JSONによるスキーマレスなデータ運用
これにより、柔軟なデータ構造をわかりやすく表現できる。
加えてスキーマレスなため、データの構成を柔軟に帰ることが出来る
● レプリカセットによる冗長化対応
MySQLでも、マスタを冗長化するためには、MySQLCluster、MHAなどのプロダクトが
あるが、導入に際しては様々な障壁がある。
レプリカセットはそれらと比べてとても簡単に冗長化することが出来る
● シャーディングによるスケールアウト
MySQLでは水平分散を行うためにはMySQLClustrer等の例を除きアプリ側での対応が必
要となり、垂直分散に留まっているサービスも多い。
MongoDBでは標準機能としての水平分散の仕組み（mongos mongoc ）が備わっている
ためにミドルウェア側で水平分散を実装しなくてもすむ
● キャッシュ機構の充実による、高パフォーマンス
基本機能として、できるだけデータをメモリにキャッシュする仕様になっており、別途
memcachedなどを導入しなくてもある程度のパフォーマンスを確保可能である

5

■想定環境
想定環境は以下の通りとします。
レプリカセット3台と、シャーディング3組のオーソドックスな環境を構築＆運用を想定

設定プロパティ

DB名 testdb

DB:Collection01 testcollection01

DB:Collection02 testcollection02

6

サーバ名 IP Addr port replicasets sharding

mongod01 192.168.0.11 27018 RSTest01 ShardTest01









mongoc01 192.168.0.21 27019 - -

mongoc02 192.168.0.22 27019 - -

mongoc03 192.168.0.23 27019 - -

mongos01 192.168.0.31 27017 - -

7

■運用項目

□インストール

・インストール手順
実際は、自身で作成したRPMなどでインストールしたほうが良いのですが、汎用的な方法
として今回はバイナリのtgzファイルを展開する方法を取ります
$ cd /usr/local
$ sudo wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz
$ sudo tar zxvf mongodb-linux-x86_64-2.0.3.tgz
$ cd mongodb-linux-x86_64-2.0.3
# 設定ファイルの置き場作成
$ mkdir -p ./conf

・初期設定ファイル[mongod.conf]
初期設定ファイルは以下のようになります。
これがmongodを単体起動するための設定ファイルとしての最低限の設定となります。
$ vim /usr/local/mongodb-linux-x86_64-2.0.3/conf/mongod.conf
# LISTENポート
port = 27018
# logのパス
logpath=/usr/local/mongodb-linux-x86_64-2.0.3/logs/mongod.log
# pidのパス
pidfilepath=/var/run/mongod.pid
# 再起動などした時にlogがあったら追記するかどうか
logappend=true
# バックグラウンドで起動する際に必要
fork = true
# DBファイルのパス
dbpath=/usr/local/mongodb-linux-x86_64-2.0.3/data
# DB毎にサブディレクトリを作成します
directoryperdb=true
# ユーザ認証なし（付けたほうがいいが別途説明）
noauth = true
# 監視用のRESTインターフェースを起動します（ポートはport+1000)
rest = true
# ジャーナルを有効にします（不意な電源断等の場合にjournalから復旧します）

8

journal = true

□レプリカセット

○レプリカセット構築

レプリカセットを設定する際に変更箇所は以下赤字でしめします。
# LISTENポート
port = 27018
# logのパス
# pidのパス
# 再起動などした時にlogがあったら追記するかどうか
logappend=true
# バックグラウンドで起動する際に必要
fork = true
directoryperdb=true
noauth = true
rest = true
journal = true
# レプリケーションのオプション（レプリカセットをくむmongodで）
replSet = RSTEST001

・レプリカセット設定
設定を有効にしたらmongodを起動します。

$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongod -f /usr/local/mongodb-linux-
x86_64-2.0.3/conf/mongod.conf

9

1. mongo クライアントでmongodへアクセス
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongo --host 192.168.0.11 --port
27018
MongoDB shell version: 2.0.3
connecting to: 192.168.0.11:27018/test
>

2. レプリカセット構築
> var config = {
"_id" : "RSTest01",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "192.168.0.11:27018"
},
{
"_id" : 1,
"host" : "192.168.0.12:27018"
},
{
"_id" : 2,
"host" : "192.168.0.13:27018"
}
]
}
# configをもとにレプリカセットを作成
> rs.initiate(config)
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}

3.確認
PRIMARY> rs.status()
{
"set" : "RSTest01",
"date" : ISODate("2012-02-29T06:47:31Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.0.11:27018",
"health" : 1,

10

"state" : 1,
"stateStr" : "PRIMARY",
"optime" : {
"t" : 1329994289000,
"i" : 1
},
"optimeDate" : ISODate("2012-02-23T10:51:29Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.0.12:27018",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 418681,
"optime" : {
"t" : 1329994289000,
"i" : 1
},
"lastHeartbeat" : ISODate("2012-02-29T06:47:30Z"),
"pingMs" : 0
},
{
"_id" : 2,
"name" : "192.168.0.13:27018",
"health" : 1,
"state" : 2,
"uptime" : 418683,
"optime" : {
"t" : 1329994289000,
"i" : 1
},
"pingMs" : 0
}
],
"ok" : 1
}
RSTest02,RSTest03においても同様の手順をおこなう

○ レプリカセット設定変更

・設定確認

11

現在の設定を変数に格納します

$ /usr/local/mongodb2/bin/mongo --host 192.168.0.11 --port 27018
# 現在のレプリカセットの設定を変数に格納します
PRIMARY> var config = rs.config()
# 表示
PRIMARY> config
{
"_id" : "RSTest01",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "192.168.0.11:27018"
},
{
"_id" : 1,
"host" : "192.168.0.12:27018"
},
{
"_id" : 2,
"host" : "192.168.0.13:27018"
}
]
}

・設定テンプレートの内容変更
格納した変数を更新します
ここでは、192.168.0.11のpriorityを2とし、必ずPRIMARYになるようにし、192.168.0.13は
バックアップ用途としてpriority=0とし、PRIMARY昇格しないように変更しています

PRIMARY> config.members[0].priority = 2
PRIMARY> config.members[2].priority = 0
# 変更した内容を表示
PRIMARY> config
{
"_id" : "RSTest01",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "192.168.0.11:27018",
"priority" : 2

12

},
{
"_id" : 1,
"host" : "192.168.0.12:27018"
},
{
"_id" : 2,
"host" : "192.168.0.13:27018",
"priority" : 0

}
]
}

・設定変更適用
格納した変数を更新します

# 変更した内容を適用
PRIMARY> rs.reconfig(config)
# 変更した内容を確認
PRIMARY> rs.config()
{
"_id" : "RSTest01",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "192.168.0.11:27018",
"priority" : 2
},
{
"_id" : 1,
"host" : "192.168.0.12:27018"
},
{
"_id" : 2,
"host" : "192.168.0.13:27018",
"priority" : 0
}
]
}

○ レプリカセットステータス確認

・ステータス確認

13

rs.status()コマンドで、現在のレプリカセットの状況確認を行っています

$ /usr/local/mongodb2/bin/mongo --host 192.168.0.11 --port 27018
# 現在のレプリカセットのステータスを表示
PRIMARY> > rs.status()
{
"set" : "replSetPigglifeServer2014",
"date" : ISODate("2012-06-07T08:35:38Z"),
"myState" : 2,
"syncingTo" : "192.168.0.11:27018",
"members" : [
{
"_id" : 0,
"name" : "192.168.0.11:27018",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 215773,
"optime" : {
"t" : 1339058137000,
"i" : 2
},
"pingMs" : 0
},
{
"_id" : 1,
"name" : "192.168.0.12:27018",
"health" : 1,
"state" : 2,
"optime" : {
"t" : 1339058138000,
"i" : 18
},
"self" : true

},
{
"_id" : 2,
"name" : "192.168.0.13:27018",
"health" : 1,
"state" : 2,
"uptime" : 215773,

14

"optime" : {
"t" : 1339058137000,
"i" : 39
},
"pingMs" : 0
}
],
"ok" : 1
}

□シャーディング

○シャーディング構築

シャーディングを設定する際の変更箇所は以下赤字。

# LISTENポート
port = 27018
# logのパス
# pidのパス
# 再起動などした時にlogがあったら追記しますかどうか
logappend=true
# バックグラウンドで起動します際に必要
fork = true
directoryperdb=true
noauth = true
rest = true
journal = true
# レプリケーションのオプション（レプリカセットをくむmongodで設定）
replSet = RSTEST001
# シャーディングのオプション（シャーディングを有効にしますmongodで設定）
shardsvr=true

15

・設定ファイル変更[mongoc.conf]
シャーディングの情報を格納するmongocプロセスの設定をします
port=27019
logpath=/usr/local/mongodb-linux-x86_64-2.0.3/logs/mongoc.log
pidfilepath=/var/run/mongoc.pid
logappend=true
fork = true
dbpath=/usr/local/mongodb-linux-x86_64-2.0.3/mongoc
# config server option
configsvr = true
rest = true

・設定ファイル変更[mongos.conf]
シャーディング環境へアクセスする為のmongosプロセスの設定をします
port = 27017
logpath = /usr/local/mongodb-linux-x86_64-2.0.3/logs/mongos.log
logappend = true
fork = true
pidfilepath = /var/run/mongos.pid
# mongocのIP:Portを指定
configdb = "192.168.0.21:27019,192.168.0.22:27019,192.168.0.23:27019"

・シャーディング設定
1. サーバ起動
設定を変更したら、mongod -> mongoc -> mongosの順番で起動します
[mongod]
x86_64-2.0.3/conf/mongod.conf

[mongoc]
x86_64-2.0.3/conf/mongoc.conf

[mongos]
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongos -f /usr/local/mongodb-linux-

16

x86_64-2.0.3/conf/mongos.conf

2. mongo クライアントでmongosへアクセス
$ /usr/local/mongodb2_1/bin/mongo --port 27017
mongos>

3. シャーディング構築

# admin 権限での作業を行う
mongos> use admin
switched to db admin

# addshardコマンドでshard追加
mongos> db.runCommand(
... {addshard:"RSTest01/
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018",name:"ShardTest01"
,allowLocal:true}
... );
{ "shardAdded" : "ShardTest01", "ok" : 1 }

ShardTest02,ShardTest03においても同様の手順をおこないます

3.確認
Shardが合計3つ追加されていることを確認します
mongos> printShardingStatus();
--- Sharding Status ---
sharding version: { "_id" : 1, "version" : 3 }
shards:
{ "_id" : "ShardTest01", "host" : "RSTest01/
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }
192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }

○データベース／コレクションのシャーディング有効化

・データベースのシャーディング有効化

17

シャーディング環境を構築した後は、データベースにおいてシャーディングが有効な状態
にしないとシャーディングを使用することができません。そのためにenableshardingコ
マンドを使用します。

mongos>

2. testdb　データベースにおいてシャーディングを有効にする

mongos>db.runCommand({enablesharding:"testdb"});

・コレクションのシャーディング有効化
データベースの次はコレクションのシャーディング有効化を行います。

mongos>

2. testdb　データベースの、testcollection01、testcollection02をkey:_id(PrimaryKey)を使用
してシャーディングする

mongos>db.runCommand({shardcollection:"testdb.testcollection01",key:{"_id":1}});
mongos>db.runCommand({shardcollection:"testdb.testcollection02",key:{"_id":1}});

3. 設定確認をしてみましょう。
赤字の部分が今回の作業で追加された部分です。
shards:
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }

18

192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
{ "_id" : "testdb", "partitioned" : true, "primary" : "ShardTest01" }
testdb.testcollection01 chunks:
ShardTest01 1
ShardTest01 1

○ シャード、Chunk状況確認

・状態確認コマンド
ここまでの手順で何度か使用しているが、シャードと、そのChunk情報の取得コマンドに
printShardingStatus()があります。
shards:
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }
192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
ShardTest01 1
ShardTest01 10000
ShardTest02 10000
ShardTest03 10000
{ "_id" : { $minKey : 1 } } -->> { "_id" : "00000c95bfbee9e0" } on :
ShardTest01{ "t" : 3000, "i" : 0 }
{ "_id" : "00000c95bfbee9e0" } -->> { "_id" : "1ac64445b0f496a3" }
on : ShardTest01{ "t" : 12000, "i" : 0 }
{ "_id" : "1ac64445b0f496a3" } -->> { "_id" : "35ba8085acafbdb7" }
on : ShardTest01{ "t" : 12000, "i" : 1 }
{ "_id" : "35ba8085acafbdb7" } -->> { "_id" : "502bd71147565e09" }
on : ShardTest01{ "t" : 5000, "i" : 0 }
{ "_id" : "502bd71147565e09" } -->> { "_id" : "6af8715b78dd90bc" }
on : ShardTest01{ "t" : 6000, "i" : 0 }
{ "_id" : "6af8715b78dd90bc" } -->> { "_id" : "85945c33b56644a8" }

19

on : ShardTest01{ "t" : 7000, "i" : 0 }
{ "_id" : "85945c33b56644a8" } -->> { "_id" : "a04b5b78052387e9" }
on : ShardTest01{ "t" : 8000, "i" : 0 }
{ "_id" : "a04b5b78052387e9" } -->> { "_id" : "b82718d75c58f8ec" } on :
ShardPigglifeServer1008 { "t" : 9000, "i" : 0 }
　　　too many chunks to print, use verbose if you want to force print

“too many chunks to print, use verbose if you want to force print”というメッセージがでまし
たが、これはChunk数が多すぎるために、省略されましたという意味です。

・シャーディング状態確認[全件表示]
上記、printShardingStatus()だと、Chunk数が多数に渡る場合に省略されてしまうため細か
いChunk状況の確認をしたい場合は、printShardingStatus(undefined, true)を使用するこ
とですべてのChunkを表示することができます。
shards:
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }
192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
ShardTest01 1
ShardTest01 10000
ShardTest02 10000
ShardTest03 10000
# 以下省略

○ Chunk移動

・シャーディング状態確認]
シャーディングでのChunkの状態を確認します。
先程使用したprintShardingStatus(undefined, true)を使用してみましょう。

20

shards:
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }
192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
ShardTest01 1
ShardTest01 10000
ShardTest02 10000
ShardTest03 10000
{ "_id" : { $minKey : 1 } } -->> { "_id" : "00000c95bfbee9e0" } on :
ShardTest01{ "t" : 3000, "i" : 0 }
{ "_id" : "00000c95bfbee9e0" } -->> { "_id" : "1ac64445b0f496a3" } on :
ShardTest01{ "t" : 12000, "i" : 0 }
{ "_id" : "1ac64445b0f496a3" } -->> { "_id" : "35ba8085acafbdb7" } on :
ShardTest01{ "t" : 12000, "i" : 1 }
{ "_id" : "35ba8085acafbdb7" } -->> { "_id" : "502bd71147565e09" } on :
ShardTest01{ "t" : 5000, "i" : 0 }
{ "_id" : "502bd71147565e09" } -->> { "_id" : "6af8715b78dd90bc" } on :
ShardTest01{ "t" : 6000, "i" : 0 }
{ "_id" : "6af8715b78dd90bc" } -->> { "_id" : "85945c33b56644a8" } on :
ShardTest01{ "t" : 7000, "i" : 0 }
{ "_id" : "85945c33b56644a8" } -->> { "_id" : "a04b5b78052387e9" } on :
ShardTest01{ "t" : 8000, "i" : 0 }
{ "_id" : "a04b5b78052387e9" } -->> { "_id" : "b82718d75c58f8ec" } on :
ShardPigglifeServer1008 { "t" : 9000, "i" : 0 }
# 以下省略
赤字で示した、{ "_id" : "35ba8085acafbdb7" } -->> { "_id" : "502bd71147565e09" }にの
ChunkをShardTest01 から ShardTest02 に移動します。

・Chunk移動
次にChunkを実際に移動してみましょう。Chunk移動には管理コマンド（admin実行権限が
必要な）moveChunkコマンドを使用します。
再びmongosに接続します。

moveChunkでは移動したいChunkのkeyに該当するfind文を書く必要があります。

21

前述の確認で、移動したいChunkは{ "_id" : "35ba8085acafbdb7" } -->>
{ "_id" : "502bd71147565e09" }の範囲にある事は判明しているので、その最小値
35ba8085acafbdb7に1を加えた35ba8085acafbdb8を指定します。

mongos> use admin
mongos> db.adminCommand({moveChunk : "testdb.testcollection02", find :
{ "_id" : "35ba8085acafbdb8" }, to : "ShardTest02"})
{ "millis" : 5000, "ok" : 1 }

・Chunk移動後のシャーディング状態確認
では実際に移動したかどうか確認しましょう。printShardingStatus(undefined, true)です。
ShardTest01->ShardTest02にChunkが移動したことがわかると思います。

shards:
192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" }
192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" }
192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" }
databases:
ShardTest01 1
ShardTest01 9999
ShardTest02 10001
ShardTest03 10000
# 省略
{ "_id" : "35ba8085acafbdb7" } -->> { "_id" : "502bd71147565e09" } on :
ShardTest02{ "t" : 5000, "i" : 0 }
# 省略

□バックアップ／リストア

○ バックアップ

22

BSON形式でバックアップを取得したい場合はmongodumpコマンドを使用し、BSON形式
になってしまいます。データ処理などに使用したいのでJSONでバックアップしたい、
という場合は、mongoexportを使用しましょう。
ただし、JSON形式ですと、データの属性などが失われることに注意してください。

・mongodump
1. DB全体のバックアップを取得する場合
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongodump -v --host 192.168.0.31 --
port 27017 -o /backup/20120608

1. あるDBのあるCollectionのみバックアップを取得する場合
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongodump -v --host 192.168.0.31 --
port 27017 -d testdb -c testcollection01 -o /backup/20120608

・mongoexport
1. あるDBのあるCollectionのみバックアップをJSON形式で取得する
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongoexport -v --host 192.168.0.31
--port 27017 -d testdb -c testcollection01 -o /backup/20120608/testdb/
testcollection01.json

○ リストア

・mongorestore
1. DB全体のリストアを行う場合
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongorestore -v --host 192.168.0.31 --
port 27017 -o /backup/20120608

1. あるDBのあるCollectionのみバックアップをリストアする場合
testcollection01.bson

mongodump に --drop オプションをつけることで、データをリストアする前にそのコレク
ションをDropしてからリストアすることが出来る。ただし、その際シャード情報などの
データは失われてしまうため前述したshardcollectionを再度行う必要がある。

23

・mongoimport
1. DB全体のバックアップを取得する場合
$/usr/local/mongodb-linux-x86_64-2.0.3/bin/mongoimport -v --host 192.168.0.31
testcollection01.json

□セキュリティ／ユーザ管理

○ keyfileによるアクセス制御
mongos,mongodなどで共通のkeyfileを作成して、これを元にアクセス制限を行います。

1. keyfileの作成
$ openssl rand -base64 753 > /usr/local/mongodb-linux-x86_64-2.0.3/conf/keyfile
$ cat /usr/local/mongodb-linux-x86_64-2.0.3/conf/keyfile
LUri/
vkIUanUcW90dmimbwB338u8RgXDIwNOB2ZdYBw1Xcd3qEc0HV9SJ9tL641G
h2uzdex2lf3imAxnHhfbihOw0x3LeMbJdFAG+29pD7ryiiG2zvKp0Fax07Tf7BrY
wR6N2VOxHwmPvbA37wiZdjZyc+xhoufDdYg7gdQuG63xj8qqa6ad3iHk/8KJXpCY
q1bct4vbKqYL+rfYS/8yOYNqnPMQmDol9/Xmmg39Byhx/8b+ZhfgyQ7HJ/VUJH9e
OI+dmu9adoZH/4zkz4Ku0+kKLxcOfPaGvpIoAxbRy3B22BGNzqUdE+jWR4aXeFkw

(snip)

TqX4A1axpiewNrW5vJbkSgHJRYjskXXt7Iz8YWoPW+w5+VeaknbwX0VqTJDHtOJ
J
eVb0NWJV6R5ZoMgkjd77s4xpXd0On+ARypbXry8rSMnz

2. mongos,mongodの設定変更
mongos,mongodのそれぞれで、keyfileを指定して起動します
keyfile = /usr/local/mongodb-linux-x86_64-2.0.3/conf/keyfile

2. mongos,mongodを再起動します

○ ユーザ作成

24

データベース[testdb]に、ユーザ[dbuser]を作成する場合の設定方法は以下のようになりま
す。

27018
>

2. データベース[testdb]にユーザ[dbuser]をパスワード[password]で作成する
> use testdb
switched to db testdb
> db.addUser('dbuser', 'password')

○ ユーザ確認
データベース[testdb]に、どの様なユーザがいるか確認する場合の方法。
27018
>

2. データベース[testdb]に作成されているユーザを確認する
> use testdb
> db.system.users.find()
{ "_id" : ObjectId("57656479248e475ccaabd259"), "user" : "dbuser", "readOnly" :
false, "pwd" : "8764586d24968c0d5cdd2bf710bd7652" }

○ ユーザ削除
データベース[testdb]の、ユーザ[dbuser]を削除する場合の例です。


25

27018
>

2. データベース[testdb]にユーザ[dbuser]をパスワード[password]で作成する
> use testdb
> db.removeUser('dbuser')

□コレクション操作

○ コレクション名変更
ただし、シャーディング環境ではできない

> use testdb
> db.runCommand( { renameCollection: "mydb.oldname", to: "mydb.newname" }

□INDEX操作

○ INDEX作成
データベース[testdb]のコレクション[testcollection01]のキー[testkey01]でINDEXが貼りたい
場合。
1. mongo クライアントでmongos(sharding環境でなければmongod)へアクセス
27017
>

2.コレクション[ testcollection01]に、[testkey01]をキーにしたINDEXを作成する

26

> use testdb
> db.testcollection01.ensureIndex({testkey01:1});

○ INDEX確認
データベース[testdb]のコレクション[testcollection01]に貼ってあるINDEXの確認
27017
>

2. コレクション[ testcollection01]に、作られているINDEXを確認する。
PrimaryKeyのINDEXと、前述のINDEX作成手順で作った、testkey01をキーとしたINDEXが
"name" : "testkey01_1",という名前で作成されているのがわかる。
> use testdb
> db.testcollection01.getIndexes()
[
{
"name" : "_id_",
"ns" : "testdb.testcollection01",
"key" : {
"_id" : 1
},
"v" : 0
},
{
"_id" : ObjectId("4dc23fa3a80b90ab1053178c"),
"key" : {
"testkey01" : 1
},
"name" : "testkey01_1",
"v" : 0
}
]

27

○ INDEX削除
データベース[testdb]のコレクション[testcollection01]に貼ってある、先程作成した
"name" : "testkey01_1"というINDEXを削除する。

27017
>

2. INDEX [testkey01_1]を削除する
> use testdb
> db.testcollection01.dropIndex("testkey01_1")

■チューニング／調査

□チューニング／調査

○ Profiling
Profilingは、クエリが遅い場合などにどのクエリが遅いか等の調査を行うために使用する。
有効にした段階に指定したミリ秒以上のクエリなどをprofileコレクションに格納され
る。

・Profiling有効化
profilingは各mongodに対して行う（mongos経由ではできない）
27018
>

28

2. データベース[testdb]のProfilingを行う
> use testdb
# 全クエリの保存
> db.setProfilingLevel(2);
# 遅いクエリのみの保存。この場合は1000msより遅いクエリは保存される
> db.setProfilingLevel(1,1000);

・Profiling確認

> use testdb
# 引っかかったクエリを確認する
> db.system.profile.find()
{ "ts" : ISODate("2012-04-
23T04:13:48.407Z"), "op" : "query", "ns" : "testdb.testcollection01", "query" :
{ "_id" : "480f9a4343c2c732" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :
295, "millis" : 0, "client" : "192.168.0.106", "user" : "" }
{ "ts" : ISODate("2012-04-
{ "_id" : "bbba256780303b8b" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :
{ "ts" : ISODate("2012-04-
{ "_id" : "411553252e38c7e8" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :
{ "ts" : ISODate("2012-04-
{ "_id" : "bce2a5a9a9ef4a7a" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :
{ "ts" : ISODate("2012-04-
{ "_id" : "6253562523456225" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :
{ "ts" : ISODate("2012-04-
{ "_id" : "53252b22c2252222" }, "ntoreturn" : 1, "idhack" : true, "responseLength" :

・Profiling無効化

29

27018
>

2. データベース[testdb]のProfilingを行う
> use testdb
# Profilingを無効にする
> db.setProfilingLevel(0);

○ LogLevel
ログも普段はログレベルを低くしておいたほうがログが少なくてよいが、障害切り分け時
などには一時的にログレベルを上げる事で切り分けの材料にすることが出来る。
ログレベルには0から5まであり、数字が大きいほど詳細な（しかし冗長な）ログが出力さ
れる

・LogLevel変更
27018
>

2. ログレベルの変更を行う。admin権限で行う。
> use admin
# ログレベルを最高の5に設定する
> db.adminCommand({setParameter:1, logLevel:5})
{ "logLevel" : 0, "ok" : 1 }

（詳細なログ出力が行われる。ここで原因切り分けが終わったらログレベルを戻す）

30

# ログレベルを最低の0に設定する
> db.adminCommand({setParameter:1, logLevel:0})
{ "logLevel" : 5, "ok" : 1 }

○ 各種ステータス調査

・mongostat
指定したmongodの状況をリアルタイムで確認可能
1. mongo クライアントでmongostatを実行
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongostat --host
192.168.0.11:27018,192.168.0.14: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.0.11: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 RSTest01 M 11:16:57
192.168.0.12:27018 0 384 164 0 245 480 0 30.1g 63.9g 15.6g 0
2 0 0|0 2|0 96k 652k 2587 RSTest02 M 11:16:57

192.168.0.11: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 RSTest01 M 11:16:58
192.168.0.12:27018 0 465 170 0 255 582 0 30.1g 63.9g 15.6g 1
3 0 0|0 2|0 108k 1m 2587 RSTest02 M 11:16:58

192.168.0.11:27018 0 385 115 0 163 490 0 36.1g 76.2g 14.3g 1
2 0 0|0 1|0 92k 745k 3056 RSTest01 M 11:16:59
192.168.0.14:27018 0 378 160 0 247 525 0 30.1g 63.9g 15.6g 0
2.1 0 0|0 2|0 99k 832k 2587 RSTest02 M 11:16:59

192.168.0.11:27018 0 388 145 0 218 541 0 36.1g 76.2g 14.3g 1
1.8 0 0|0 2|0 96k 716k 3056 RSTest01 M 11:17:00
192.168.0.14:27018 0 404 166 0 216 559 0 30.1g 63.9g 15.6g 1
11.1 0 0|0 2|0 100k 811k 2587 RSTest02 M 11:17:00

192.168.0.11:27018 0 386 104 0 179 582 0 36.1g 76.2g 14.3g 0
1.3 0 0|0 2|0 92k 811k 3056 RSTest01 M 11:17:01
192.168.0.14:27018 0 386 148 0 236 629 0 30.1g 63.9g 15.6g 1
1.9 0 0|0 2|0 104k 863k 2587 RSTest02 M 11:17:01

192.168.0.11:27018 0 423 110 0 181 399 0 36.1g 76.2g 14.3g 1
2.5 0 0|0 2|0 84k 776k 3056 RSTest01 M 11:17:02
192.168.0.14:27018 0 401 156 0 235 436 0 30.1g 63.9g 15.6g 1
3.7 0 0|0 2|0 88k 677k 2587 RSTest02 M 11:17:02

31

192.168.0.11:27018 0 379 138 0 228 443 0 36.1g 76.2g 14.3g 0
1.9 0 0|0 2|0 89k 793k 3056 RSTest01 M 11:17:03
192.168.0.14:27018 0 426 172 0 263 491 0 30.1g 63.9g 15.6g 0
2.3 0 0|0 2|0 98k 779k 2587 RSTest02 M 11:17:03

192.168.0.11:27018 0 430 129 0 213 495 0 36.1g 76.2g 14.3g 1
2.5 0 0|0 2|0 99k 825k 3056 RSTest01 M 11:17:04
192.168.0.14:27018 0 447 161 0 239 502 0 30.1g 63.9g 15.6g 1
2.2 0 0|0 2|0 108k 869k 2587 RSTest02 M 11:17:04

192.168.0.11:27018 0 420 119 0 201 497 0 36.1g 76.2g 14.3g 0
1.7 0 0|0 2|0 88k 865k 3056 RSTest01 M 11:17:05
192.168.0.14:27018 0 420 149 0 230 522 0 30.1g 63.9g 15.6g 0
1.9 0 0|0 1|0 94k 713k 2587 RSTest02 M 11:17:05

192.168.0.11:27018 0 346 137 0 216 517 0 36.1g 76.2g 14.3g 0
1.9 0 0|0 2|0 89k 849k 3056 RSTest01 M 11:17:06
192.168.0.14:27018 0 368 136 0 217 518 0 30.1g 63.9g 15.6g 1
2 0 0|0 2|0 90k 835k 2587 RSTest02 M 11:17:06

・mongotop
指定したmongodの状況をリアルタイムで確認可能
1. mongo クライアントでmongostatを実行
$ /usr/local/mongodb-linux-x86_64-2.0.3/bin/mongotop --host 172.28.8.41 --port
27018

結果出力は下記のようになる。
ns total read write 2012-05-23T02:14:10
local.oplog.rs 1929ms 1929ms 0ms
testdb.testcollection01 5ms 0ms 3ms

ns total read write 2012-05-23T02:14:12
local.oplog.rs 1929ms 1929ms 0ms

32


・mongosniff
指定したmongod、mongosに流れているパケットをキャプチャして解析することができ
る。
ログなどで正確に出力させることができないqueryを駆使したoperationもmongosniffであれ
ば取得することが可能。

下記は出力例。パケットキャプチャを行うためにはroot権限が必要なので、rootか、sudoで
実行すること。
# mongosniff --source NET eth0 27017
sniffing... 27017
192.168.0.11:27017 <<-- 192.168.0.101:39853 @e 178 bytes id:5d1a2d6e 1561996654 -
2401728
reply n:1 cursorId: 1459176079823433956
{ ts: Timestamp 1339484929000|67, h: 990353900320314554, op: "u",
ns: "testdb.testcollection01", o2: { _id: "aa69583bb4b50ba9" }}
# 以下略

・db.stats()
データベースの統計情報の表示
27018
>

2. データベース[testdb]の統計情報の表示を行う
> db.stats()
{
# ここからはシャード毎の値
"raw" : {
"RSTest01/192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018" : {
"db" : "testdb",

33

"collections" : 2,
"objects" : 1060,
"avgObjSize" : 73.18490566037735,
"dataSize" : 77576,
"storageSize" : 225280,
"numExtents" : 7,
"indexes" : 2,
"indexSize" : 65408,
"fileSize" : 201326592,
"nsSizeMB" : 16,
"ok" : 1
},
"RSTest01/192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018" : {
"db" : "testdb",
"collections" : 2,
"objects" : 1060,
"avgObjSize" : 73.18490566037735,
"dataSize" : 77576,
"numExtents" : 7,
"indexes" : 2,
"fileSize" : 201326592,
"nsSizeMB" : 16,
"ok" : 1
},
"RSTest01/192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018" : {
"db" : "testdb",
"collections" : 2,
"objects" : 1060,
"avgObjSize" : 73.18490566037735,
"dataSize" : 77576,
"numExtents" : 7,
"indexes" : 2,
"fileSize" : 201326592,
"nsSizeMB" : 16,
"ok" : 1
}
},
# シャード全体の合計
"objects" : 3180,
"avgObjSize" : 73.18490566037735,
"dataSize" : 232728,
"numExtents" : 21,
"indexes" : 6,
"fileSize" : 603979776,

34

"ok" : 1
}

3. 各項目の意味

項目名意味

objects オブジェクト数

avgObjSize オブジェクトの平均サイズ

datasize このDBに格納されているデータの合計サイズ、各ドキュメントのサイズ
が減少した場合にはこの値は変化しないが、ドキュメントそのものを削
除した場合には減少する。

storageSize このDBに確保されているドキュメントストレージのサイズの合計

numExtents 確保されているデータファイルの合計

Indexes Indexの合計数（全コレクションのDB合計）

IndexSize INDEXのデータサイズの合計

nsSizeMB ネームスペース情報が格納されているネームスペースファイルの容量。
データファイルと同じディレクトリにある、拡張子*.nsのファイルがネ
ームスペースファイルとなっている。

4. 見るポイント
・確保されているデータファイルは確保されているが、Chunk移動等でデータの入っていな
いが確保だけされているゴミデータファイルが増えていないか　→repair等を行う
・シャード毎の項目で、Chunkが極端に偏っているシャードが無いか

・db.collection.stats()
コレクションの統計情報の表示
27018
>

35

2. データベース[testdb]にある、コレクション[testcollection01]の統計情報を表示する
> db.testcollection01.stats()
{
# シャード全体の合計
"sharded" : true,
"flags" : 1,
"count" : 543,
"numExtents" : 6,
"size" : 84684,
"totalIndexSize" : 98112,
"indexSizes" : {
"_id_" : 98112
},
"avgObjSize" : 51.98526703499079,
"nindexes" : 1,
"nchunks" : 3,
# ここはシャード毎の値
"shards" : {
"ShardTest01" : {
"count" : 543,
"size" : 28228,
"avgObjSize" : 51.98526703499079,
"numExtents" : 2,
"nindexes" : 1,
"lastExtentSize" : 32768,
"paddingFactor" : 1,
"flags" : 1,
"indexSizes" : {
"_id_" : 32704
},
"ok" : 1
},
"ShardTest03" : {
"count" : 543,
"size" : 28228,
"avgObjSize" : 51.98526703499079,
"numExtents" : 2,
"nindexes" : 1,
"flags" : 1,

36

"indexSizes" : {
"_id_" : 32704
},
"ok" : 1
},
"ShardTest03" : {
"count" : 543,
"size" : 28228,
"avgObjSize" : 51.98526703499079,
"numExtents" : 2,
"nindexes" : 1,
"flags" : 1,
"indexSizes" : {
"_id_" : 32704
},
"ok" : 1
}
},
"ok" : 1
}

3. 各項目の意味

項目名意味

ns ネームスペース

count オブジェクト数

numExtents 確保されているデータファイルの合計

size コレクションのサイズ

storageSize このコレクションに確保されているドキュメントストレージの大きさ

totalIndexSize INDEXのサイズ

avgObjSize オブジェクトの平均サイズ

37

nindexes このコレクションのINDEX数

nchunks このコレクションのChunk数

4. 見るポイント
・シャード毎の項目で、Chunkが極端に偏っているシャードが無いか
・オブジェクトの平均サイズが極端に大きかったり小さかったりしないか

・connPoolStats
レプリカセット、シャーディング環境におけるコネクション統計を取得できます。

27017
>

2. db.adminCommand("connPoolStats")を実行
> use admin
# ログレベルを最高の5に設定する
> db.adminCommand("connPoolStats")
{
"hosts" : {
"192.168.0.21:27019::0" : {
"available" : 1,
"created" : 1
},
"192.168.0.21:27019::30" : {
"available" : 1,
"created" : 1
},
"192.168.0.21:27019,192.168.0.22:27019,192.168.0.23:27019::0" :
{
"available" : 2,
"created" : 2
},
"192.168.0.21:27019,192.168.0.22:27019,192.168.0.23:27019::30" :
{
"available" : 1,
"created" : 1

38

},
"192.168.0.22:27019::0" : {
"available" : 1,
"created" : 206
},
"192.168.0.22:27019::30" : {
"available" : 1,
"created" : 1
},
"192.168.0.23:27019::0" : {
"available" : 1,
"created" : 206
},
"192.168.0.23:27019::30" : {
"available" : 1,
"created" : 1
},
"192.168.0.11:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.12:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.13:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.14:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.15:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.16:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.17:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.18:27018::0" : {
"available" : 0,
"created" : 1
},
"192.168.0.19:27018::0" : {

39

"available" : 0,
"created" : 1
},
"RSTest01/192.168.0.11:27018,192.168.0.12:27018,192.168.0.13:27018::0"
:{
"available" : 2,
"created" : 2
},
"RSTest02/192.168.0.14:27018,192.168.0.15:27018,192.168.0.16:27018::0"
:{
"available" : 1,
"created" : 1
},
"RSTest03/192.168.0.17:27018,192.168.0.18:27018,192.168.0.19:27018::0"
:{
"available" : 1,
"created" : 1
}
},
"replicaSets" : {
"RSTest01" : {
"hosts" : [
{
"addr" : "192.168.0.11:27018",
"ok" : true,
"ismaster" : true,
"hidden" : false,
"secondary" : false,
"pingTimeMillis" : 0
},
{
"addr" : "192.168.0.12:27018",
"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
},
{
"addr" : "192.168.0.13:27018",
"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
}
],
"master" : 0,
"nextSlave" : 0
},

40

"RSTest02" : {
"hosts" : [
{
"addr" : "192.168.0.14:27018",
"ok" : true,
"ismaster" : true,
"hidden" : false,
},
{
"addr" : "192.168.0.15:27018",
"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
},
{
"addr" : "192.168.0.16:27018",
"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
}
],
"master" : 0,
"nextSlave" : 0
},
"RSTest03" : {
"hosts" : [
{
"addr" : "192.168.0.17:27018",
"ok" : true,
"ismaster" : true,
"hidden" : false,
},
{
"addr" : "192.168.0.18:27018",
"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
},
{
"addr" : "192.168.0.19:27018",

41

"ok" : true,
"ismaster" : false,
"hidden" : false,
"secondary" : true,
}
],
"master" : 0,
"nextSlave" : 0
},
"createdByType" : {
"master" : 425,
"set" : 4,
"sync" : 3
},
"totalAvailable" : 13,
"totalCreated" : 432,
"numDBClientConnection" : 80,
"numAScopedConnection" : 10,
"ok" : 1
}

42

■総評
今回は一概に検証したものと言うことではないですが、今後MongoDBを使用するにあた
って、基本的な設定／運用部分などでハマる事がないようにある程度まとめることにし
ました。
その間に「薄い本」などでちゃいましたがｗ
あちらは開発に必要な事がまとめてあるもので、こちらは色々インフラ的な運用方法につ
いてすぐ必要になるであろう部分を具体的にまとめたつもりです。（基本的には自分の
ためですｗ）
もっと細かい事、最新の事が知りたい場合は公式のWiki等を見るようにしましょう。
これが、誰かのお役に立てば幸いです。

■参考文献
・ http://www.mongodb.org/display/DOCS/Home
・ http://jp.docs.mongodb.org/manual/contents/

43

MongoDBのはじめての運用テキスト

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a MongoDBのはじめての運用テキスト

Semelhante a MongoDBのはじめての運用テキスト (20)

Mais de Akihiro Kuwano

Mais de Akihiro Kuwano (20)

MongoDBのはじめての運用テキスト