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

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 107.193.141.7 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Database/M.1469971604.A.1A8.html