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的确可以透过配置，做到上述范例呢？