[MongoDB] M102 Final Exam Question 2

將問題一的動作重複做一遍，

./a.sh

mongo --shell --port 27003 a.js

ourinit() // you might need to wait a bit after this.
// be sure 27003 is the primary.

// use rs.stepDown() elsewhere if it isn't.

注意：要多做一個drop()

db.foo.drop()

db.foo.insert( { _id : 1 }, { writeConcern : { w : 2 } } )
db.foo.insert( { _id : 2 }, { writeConcern : { w : 2 } } )

var a = connect("localhost:27001/admin");
db.foo.insert( { _id : 3 }, { writeConcern : { w : 2 } } )
a.shutdownServer()
rs.status()

db.foo.insert( { _id : 6 } )
db.foo.insert( { _id : 4 } )

db.foo.insert( { _id : 5 } )

這次要關掉的是27003 mongod

重新啟動27001的mongod

確認27003的連線已中斷 

查看資料

新增一筆資料進去

重新啟動27003的mongod

使用 rs.status() 查看狀態

確認他有連上

結果

Ans.

 The MongoDB primary does not write to its datafiles until a majority acknowledgement comes back from the rest of the cluster. When 27003 was primary, that was never received for writes 7,8,9. 

 When 27003 came back up, it transmitted its write ops that the other members had not seen yet to those members so that they would have them also. 

 MongoDB preserves the order of writes in a collection in its consistency model. In this problem, 27003’s oplog was effectively a “fork” and to preserve write ordering a rollback was necessary during 27003’s recovery phase.