MongoDB journal casebook

2,892 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,892
On SlideShare
0
From Embeds
0
Number of Embeds
1,096
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MongoDB journal casebook

  1. 1. MongoDBのjournaling 役割別おすすめ度 2012/05Id:sawanobly (HiganWorks LLC)
  2. 2. 内容についてのお断り• この資料は独自に調査した結果や運用構 築の経験をまとめたものです。• この資料を元に何かした際の影響につい ては責任を負いかねます。
  3. 3. MongodbのJournalとは• 先行書き込みログ、無効化可能 (Transaction logとかZFSのZILみたいなもの)• MongoDBのプロセスが不正終了した際 – Journalなし:Lockを消して整合性確認のリペア必須 – Journalあり:自動でロールフォワードし起動• 安全な分、パフォーマンスに影響する、OFF のほうが速いが最近『標準で有効』になった• Journalを有効にしたら良いケース、別にいら ないと思うケースをまとめる
  4. 4. ConfigServer:100%• Shardingのキモ、絶対Journalしましょう• Configが3つあっても、1つかけると、 Mongosが起動しない※ – 稼働中のものまで落ちはしない – ※(2.0.5)で一応起動するようにはなった
  5. 5. 単独のMongodb:75%• 有効にすると運用が楽• しかしDisk容量とI/Oに結構影響する• 不正終了時にリペアする余裕があるなら Journal不要• ドキュメント数に応じてリペア時間は増 えるので、多い場合はJournalしておくの も無難。
  6. 6. RepliacaSets:30%• 全データノード※が同時に落ちるという 環境でない限り、Journalするよりパ フォーマンスの低下を避けるという判断 でよい ※Arbiter含めて3つ以上のノード• 運用の楽さだけをとるならJounal有効もあ り
  7. 7. Arbiter:5%• データを持つわけでも無いので不要• 不正終了時は一丁前にLock => 起動しない という挙動をするので、それが煩わしい という場合はDiskを3GB消費してJournalし よう。
  8. 8. MongoRouter(mongos):0%• データを持たないのでJournalしようがあ りません。
  9. 9. おわり

×