Mongo db18 upgrade
Upcoming SlideShare
Loading in...5
×
 

Mongo db18 upgrade

on

  • 1,610 views

MongoDB upgrade Report.

MongoDB upgrade Report.
1.8.x -> 2.0.x
(1.8.3 -> 2.0.1)

Statistics

Views

Total Views
1,610
Views on SlideShare
1,607
Embed Views
3

Actions

Likes
2
Downloads
6
Comments
0

1 Embed 3

http://localhost 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Mongo db18 upgrade Mongo db18 upgrade Presentation Transcript

    • MongoDB Upgrade Report 1.8.x -> 2.0.x 2011/11/14 Sawanobori (twitterID:sawanoboly) MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • MongoDB Upgrade
      • 実運用中の MongoDB 1.8.3 クラスタを 2.0.1 に Upgrade しました。
      • Upgrade の手順と注意点をまとめ。
      • [ 実施前の注意 ]
      • コネクションが切れるのでアプリは注意。
      • MapReduce がこけるバグ※に会うかもしれない (※Workaround あり、 CoreServer/SERVER-4185)
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • Mongodb クラスタの構成 mongos 1.8.3 mongos 1.8.3 mongos 1.8.3 mongos 1.8.3 Mongod(conf) 1.8.3 Mongod(conf) 1.8.3 Mongod(conf) 1.8.3 Mongod(Set01) 1.8.3 (Pri) Mongod(Set01) 1.8.3 (Sec) Mongod(Set01) 1.8.3 (Arb) Mongod(Set02) 1.8.3 (Pri) Mongod(Set02) 1.8.3 (Sec) Mongod(Set02) 1.8.3 (Arb) Mongod(Set06) 1.8.3 (Pri) Mongod(Set06) 1.8.3 (Sec) Mongod(Set06) 1.8.3 (Arb) ・・・ MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • クラスタ内 Node を Upgrade する順番
      • ConfigNode
      • RouterNode
      • DataNode(Albiter)
      • DataNode(Secondary)
      • DataNode(Primary) - ※Stepdown() で入れ替え
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 1 ) ConfigNode の Upgrade
      • ConfigServer は Journal しておきましょう。 => 3 台とも健康でないと、 RouterNode がまともに動こうとしません。 => Journal は I/O にペナルティもあるが、プロセスのリスタート時に安定度が違います。
      • できれば 1.8.x 環境の時点で Journal 有効へ。
      • Journal 有効であれば 3 台を少し間をおいて順番に更新すれば OK です。
      • バイナリを上書きしてリスタート。
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ConfigNode 更新 mongos 1.8.3 mongos 1.8.3 mongos 1.8.3 mongos 1.8.3 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(Set01) 1.8.3 (Pri) Mongod(Set01) 1.8.3 (Sec) Mongod(Set01) 1.8.3 (Arb) Mongod(Set02) 1.8.3 (Pri) Mongod(Set02) 1.8.3 (Sec) Mongod(Set02) 1.8.3 (Arb) Mongod(Set06) 1.8.3 (Pri) Mongod(Set06) 1.8.3 (Sec) Mongod(Set06) 1.8.3 (Arb) ・・・ journal journal journal MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 2 ) RouterNode の Upgrade
      • プロセスのリスタート時にアプリケーションの接続が切れます。再接続させるかアプリケーションも一緒にリスタートします。 => 例: mongoid(ruby) はプールするので要リスタートでした。
      • ConfigNode3 つが健在でないと mongos は開始しません、 ConfigNode の状態にのみ注意。
      • バイナリ上書きリスタートで OK .
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • RouterNode 更新 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(Set01) 1.8.3 (Pri) Mongod(Set01) 1.8.3 (Sec) Mongod(Set01) 1.8.3 (Arb) Mongod(Set02) 1.8.3 (Pri) Mongod(Set02) 1.8.3 (Sec) Mongod(Set02) 1.8.3 (Arb) Mongod(Set06) 1.8.3 (Pri) Mongod(Set06) 1.8.3 (Sec) Mongod(Set06) 1.8.3 (Arb) ・・・ journal journal journal 上位のアプリケーションもリスタート MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 3 ) DataNode(Arbiter) の Upgrade
      • DataNode 内の順番はどれからでもよいと思うが、影響の少ない順で Arbiter から。
      • 2.0.x でリスタートする前に、 config にて Journal を OFF ( nojournal=true ) にしましょう。 => ほっとくと 3GB の Journal を確保されてしまう。 特に Arbiter では完全に不要。
      • バイナリ上書きリスタート。
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 4 ) DataNode(Secondaly) の Upgrade
      • Secondaly の更新も特に影響はない。
      • レプリカセットを信頼するなら Jounal は OFF で。 ( リスタート前に nojournal=true )
      • この機会に Journal を有効にするという場合はリスタート時に Journal の確保で待ち時間ができます。
      • その他オプション (rest, jsonp, etc.) もついでに調整。
      • バイナリ上書きリスタート。
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • DataNode(Arbiter, Secondaly) 更新 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(Set01) 1.8.3 (Pri) Mongod(Set01) 2.0.1 (Sec) Mongod(Set01) 2.0.1 (Arb) Mongod(Set02) 1.8.3 (Pri) Mongod(Set02) 2.0.1 (Sec) Mongod(Set02) 2.0.1 (Arb) Mongod(Set06) 1.8.3 (Pri) Mongod(Set06) 2.0.1 (Sec) Mongod(Set06) 2.0.1 (Arb) ・・・ journal journal journal MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 5 ) Datanode(Primary) の更新 -1
      • 一番気を使います。 意外と敷居の高い 『 rs.stepDown() 』
      • StepDown 直前にはバッファをフラッシュ! 『 db.runCommand({fsync:1}); 』
      • StepDown の切り替え時間はレプリカセット当たりおよそ [1-10]s 。 状況次第で結構変わる、安定する手法を確定したいところ。
      • 切り替え状況は Router のログを参照。 ([ReplicaSetMonitorWatcher] タグなど )
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • ( 5 ) Datanode(Primary) の更新 -2
      • StepDown 終了後に mongod のバイナリ上書きリスタート。
      • しかし StepDown 後、 Router 経由の接続が不安定になることが多い。。。
      • 動作が怪しくなったら RouterNode のキャッシュをクリアする、コストは微小。 『 db.adminCommand(“flushRouterConfig”) 』  => 状況によってはアプリのリスタートも検討。
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • DataNode(Primary) 更新 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 mongos 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(conf) 2.0.1 Mongod(Set01) 2.0.1 (Sec) Mongod(Set01) 2.0.1 (Pri) Mongod(Set01) 2.0.1 (Arb) Mongod(Set02) 2.0.1 (Sec) Mongod(Set02) 2.0.1 (Pri) Mongod(Set02) 2.0.1 (Arb) Mongod(Set06) 2.0.1(Sec) Mongod(Set06) 2.0.1 (Pri) Mongod(Set06) 2.0.1 (Arb) ・・・ journal journal journal StepDown() のため、 Primary は降格 MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • 1.8.x => 2.0.x まとめ
      • Default の Journal 扱いに注意 (nojournal オプション )
      • レプリカセットのローテーション以外は大体想定通りの挙動で扱いやすい。
      • フロントから見て無停止っぽくは一応可能だが、 100% の稼働率は保障できない。用途によっては一度完全に停止しましょう。
      MongoDB upgrade report 1.8.x -> 2.0.x / 16
    • その他の話
      • StepDown() 時の挙動は安定度に幅がある。 => 内容は前述のとおり、 Primary 障害発生時にも同じことが言えるので、今後の運用課題
      • MapReduce の接続でバグに遭遇 M/R が始まらない&ログファイル超肥大 => コミュニティに報告 (https://jira.mongodb.org/browse/SERVER-4185) => 一時対処として、 『 M/R 直前に必ず “ flushRouterConfig” 』で回避とした。 実装後は今のところ安定稼働、次バージョンで修正か?
      以上 MongoDB upgrade report 1.8.x -> 2.0.x / 16