役割別のMongoDB Journalオプション有効度合い

1. MongoDBのjournaling
役割別おすすめ度
2012/05
Id:sawanobly (HiganWorks LLC)

2. 内容についてのお断り
• この資料は独自に調査した結果や運用構
築の経験をまとめたものです。
• この資料を元に何かした際の影響につい
ては責任を負いかねます。

3. MongodbのJournalとは
• 先行書き込みログ、無効化可能
（Transaction logとかZFSのZILみたいなもの）
• MongoDBのプロセスが不正終了した際
– Journalなし:Lockを消して整合性確認のリペア必須
– Journalあり:自動でロールフォワードし起動
• 安全な分、パフォーマンスに影響する、OFF
のほうが速いが最近『標準で有効』になった
• Journalを有効にしたら良いケース、別にいら
ないと思うケースをまとめる

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

5. 単独のMongodb：75%
• 有効にすると運用が楽
• しかしDisk容量とI/Oに結構影響する
• 不正終了時にリペアする余裕があるなら
Journal不要
• ドキュメント数に応じてリペア時間は増
えるので、多い場合はJournalしておくの
も無難。

6. RepliacaSets:30%
• 全データノード※が同時に落ちるという
環境でない限り、Journalするよりパ
フォーマンスの低下を避けるという判断
でよい
※Arbiter含めて3つ以上のノード
• 運用の楽さだけをとるならJounal有効もあ
り

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

8. MongoRouter(mongos):0%
• データを持たないのでJournalしようがあ
りません。

9. おわり