MongoDBの journaling役割別おすすめ度

2012/05Id:sawanobly (HiganWorks LLC)

内容についてのお断り• この資料は独自に調査した結果や運用構築の経験をまとめたものです。

• この資料を元に何かした際の影響については責任を負いかねます。

Mongodbの Journalとは• 先行書き込みログ、無効化可能（ Transaction logとか ZFSの ZILみたいなもの）

• MongoDBのプロセスが不正終了した際– Journalなし :Lockを消して整合性確認のリペア必須– Journalあり :自動でロールフォワードし起動

• 安全な分、パフォーマンスに影響する、 OFFのほうが速いが最近『標準で有効』になった

• Journalを有効にしたら良いケース、別にいらないと思うケースをまとめる

ConfigServer： 100%

• Shardingのキモ、絶対 Journalしましょう• Configが 3つあっても、 1つかけると、Mongosが起動しない※–稼働中のものまで落ちはしない–※(2.0.5)で一応起動するようにはなった

単独のMongodb： 75%

• 有効にすると運用が楽• しかし Disk容量と I/Oに結構影響する• 不正終了時にリペアする余裕があるなら

Journal不要• ドキュメント数に応じてリペア時間は増えるので、多い場合は Journalしておくのも無難。

RepliacaSets:30%

• 全データノード※が同時に落ちるという環境でない限り、 Journalするよりパフォーマンスの低下を避けるという判断でよい※ Arbiter含めて 3つ以上のノード

• 運用の楽さだけをとるなら Jounal有効もあり

Arbiter:5%

• データを持つわけでも無いので不要• 不正終了時は一丁前に Lock => 起動しないという挙動をするので、それが煩わしいという場合は Diskを 3GB消費して Journalしよう。

MongoRouter(mongos):0%

• データを持たないので Journalしようがありません。

おわり