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 クラスタの構成

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)







・・・


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

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

- Stepdown()※ で入れ替え


（ 1 ） ConfigNode の Upgrade

• ConfigServer は Journal しておきましょう。=> 3 台とも健康でないと、 RouterNode がまともに動こうとしません。=> Journal は I/O にペナルティもあるが、プロセスのリスタート時に安定度が違います。

• できれば 1.8.x 環境の時点で Journal 有効へ。• Journal 有効であれば 3 台を少し間をおいて順番

に更新すれば OK です。• バイナリを上書きしてリスタート。


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










・・・

journal

journal

journal


（ 2 ） RouterNode の Upgrade

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

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

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


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










・・・

journal

journal

journal

上位のアプリケーションもリスタート


（ 3 ） DataNode(Arbiter) の Upgrade

• DataNode 内の順番はどれからでもよいと思うが、影響の少ない順で Arbiter から。

• 2.0.x でリスタートする前に、 config にてJournal を OFF ( nojournal=true ) にしましょう。=> ほっとくと 3GB の Journal を確保されてしまう。特に Arbiter では完全に不要。

• バイナリ上書きリスタート。


（ 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)

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)


・・・

journal

journal

journal


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

• 一番気を使います。意外と敷居の高い『 rs.stepDown() 』

• StepDown 直前にはバッファをフラッシュ！『 db.runCommand({fsync:1}); 』

• StepDown の切り替え時間はレプリカセット当たりおよそ [1-10]s 。状況次第で結構変わる、安定する手法を確定したいところ。

• 切り替え状況は Router のログを参照。([ReplicaSetMonitorWatcher] タグなど )


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

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

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

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


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(Set06)2.0.1(Sec)



・・・

journal

journal

journal

StepDown() のため、 Primary は降格


1.8.x => 2.0.x まとめ

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

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

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


その他の話

• 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

Documents

Mongo db18 upgrade