o※ 引述《Longness (時光如槍)》之銘言：
: 請問一下這個所謂的最終同步（不好意思可能不懂亂翻），
: 是不是指──
: 0. 原始DB的樣子
: 甲地 乙地
: A A
: B B
: 1. START!
: 甲地 乙地
: A A
: B B
: （寫入C） （寫入D）
: 2. 寫完了
: 甲地 乙地
: A A
: B B
: C D
這時候如果有人讀資料，會有可能讀到不一致的資料
過去的做法，為了防止這樣的情況發生
任何人要寫之前，先lock，也就是告訴大家說我要寫了
你們等我寫完再寫 ，要讀的人，等我寫完才能讀到我要寫的
有transaction的觀念
這個在分散式的資料庫，成本很高很難做到
MongoDB的做法，像是選一個primary，比如說甲地
所有的人都只讀甲地，那就沒有不一致的情形
: 3. 過了一陣子
: 甲地 乙地
: （兩地自動互訪）
: A A
: B B
: C →C
: D← D
: 然後最終兩邊都會寫上ABCD四份文件
其實這應該分成兩個步驟
3.1 D 寫入（replicate）甲地
3.2 C 寫入 乙地
因為大家都由甲地來讀
所以讀到的都是甲地的latest的資料
因為可以寫入乙地，所以大家不用等
: 不過如果是這樣的話，我又看了一下官網文件
: 它說一組會自動同步的MongoDB，只能有一個Primary DB，其他的Secondary DB都是
: read-only的，只有Primary能寫入、做到單向同步，從單台Primary → 各台Secondary
。
MongoDB讓你選擇要不要讀secondary。如果讀secondary，就有可能讀到不一致的資料，
因為replica有可能還沒有完成，3.1已完成可是3.2還沒完成，這時如果讀乙地，就沒有
C.
: 請問一下我是誤解eventual consistency定義了嗎？
: 還是說MongoDB的確可以透過配置，做到上述範例呢？