Mongo db18 upgrade

MongoDB Upgrade Report1.8.x -> 2.0.x

2011/11/14Sawanobori

(twitterID:sawanoboly)

MongoDB upgrade report 1.8.x -> 2.0.x 1 / 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 2 / 16

Mongodb クラスタの構成

mongos1.8.3

mongos1.8.3

mongos1.8.3

mongos1.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 3 / 16

クラスタ内 Node を Upgrade する順番

1. ConfigNode2. RouterNode3. DataNode(Albiter)4. DataNode(Secondary)5. DataNode(Primary)

- Stepdown()※ で入れ替え

MongoDB upgrade report 1.8.x -> 2.0.x 4 / 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 5 / 16

ConfigNode 更新

mongos1.8.3

mongos1.8.3

mongos1.8.3

mongos1.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 6 / 16

（ 2 ） RouterNode の Upgrade

• プロセスのリスタート時にアプリケーションの接続が切れます。再接続させるかアプリケーションも一緒にリスタートします。=> 例： mongoid(ruby) はプールするので要リスタートでした。

• ConfigNode3 つが健在でないと mongos は開始しません、 ConfigNode の状態にのみ注意。

• バイナリ上書きリスタートで OK ．

MongoDB upgrade report 1.8.x -> 2.0.x 7 / 16

RouterNode 更新

mongos2.0.1

mongos2.0.1

mongos2.0.1

mongos2.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 8 / 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 9 / 16

（ 4 ） DataNode(Secondaly) のUpgrade

• Secondaly の更新も特に影響はない。• レプリカセットを信頼するなら Jounal は

OFF で。( リスタート前に nojournal=true )

• この機会に Journal を有効にするという場合はリスタート時に Journal の確保で待ち時間ができます。

• その他オプション (rest, jsonp, etc.) もついでに調整。

• バイナリ上書きリスタート。MongoDB upgrade report 1.8.x -> 2.0.x 10 / 16

DataNode(Arbiter, Secondaly) 更新

mongos2.0.1

mongos2.0.1

mongos2.0.1

mongos2.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 11 / 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 12 / 16

（ 5 ） Datanode(Primary) の更新 -2

• StepDown 終了後に mongod のバイナリ上書きリスタート。

• しかし StepDown 後、 Router 経由の接続が不安定になることが多い。。。

• 動作が怪しくなったら RouterNode のキャッシュをクリアする、コストは微小。『 db.adminCommand(“flushRouterConfig”)  』=> 状況によってはアプリのリスタートも検討。

MongoDB upgrade report 1.8.x -> 2.0.x 13 / 16

DataNode(Primary) 更新

mongos2.0.1

mongos2.0.1

mongos2.0.1

mongos2.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 14 / 16

1.8.x => 2.0.x まとめ

• Default の Journal 扱いに注意 (nojournal オプション )

• レプリカセットのローテーション以外は大体想定通りの挙動で扱いやすい。

• フロントから見て無停止っぽくは一応可能だが、 100% の稼働率は保障できない。用途によっては一度完全に停止しましょう。

MongoDB upgrade report 1.8.x -> 2.0.x 15 / 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 / 16