标题: Replica Set的数据同步 [打印本页] 作者: shengnan007 时间: 2012-9-18 13:20 标题: Replica Set的数据同步 上一篇文章,我们了解了replica set是如何选举出primary的。当primary被选举出来,就开始处理系统中的写数据的请求,secondary要及时的同步这些写到primary中的最新的数据,保持MongoDB中数据的一致性,那么secondary是如何进行数据同步的呢?接下来我们详细分析这个问题。0 j7 _. L1 _$ a& o
& f6 ~- ]- o" e
同步 ; `( a: W7 }. F g' S, w+ p! D i- e( s
一个secondary在正常运行时,会选择replica set中的一个节点,从这个节点中叫做local.oplog.rs的collection,拉取oplog同步日志。获得同步日志后,进行下边的三项操作: 3 Y8 S4 t2 U. D 执行op日志* r3 J# ^: Z( ^* B+ a
将op日志写入到自己的oplog中(也就是local.oplog.rs) ! k. |5 z" f3 Q4 d 请求下一个op日志8 v- `8 T$ h3 I3 i! g% I
2 f/ p, o* u; U2 q! R- v" v' ^ 如果在第一步执行完毕,第二步还没有执行完的时候,secondary宕机了,那么在secondary重新恢复之后,会认为第二步的写操作还没有执行,重新开始执行第二步。在MongoDB的设计中,oplog的操作是具有幂等性的,也就是说将oplog中的某一条操作记录执行多次,不会影响结果的正确性。 . T- i1 J: V9 C0 i* b8 T; `6 L7 x: x; G9 P4 l; B* p
比如说,有一个数据是{counter:1},我们在primary中,对这个数据执行了操作{$inc:{counter:1}},就是把counter字段的值增加1,结果是{counter:2}。Oplog不会记录inc操作,而是直接记录{$set:{counter:2}}。因此,对于oplog中的操作记录,无论执行多少次,都不会影响结果的正确性。) ~6 Y- u5 q5 f1 d: o% }
2 a1 B: G6 l, T- R9 ?3 d6 v
w参数 7 s! L' ~4 i5 B0 q" e" F9 V1 x' y, h3 m
当我们在MongoDB中执行一个写操作时,默认情况下,写操作指令发送后,就认为写操作执行成功了。为了保证系统可用性和数据安全性,我们可以更改配置,当写操作在n个节点(n包括primary,如果n=1,那就是在primary执行成功后返回)都执行成功后,才返回成功。这个配置的命令如下: 2 c" h4 w' ?/ tdb.foo.runCommand({getLastError:1, w:2})) R5 b7 i: P* \ l. P
& F2 h1 j& b: F N$ ]6 q/ q 在更改了这个配置之后,执行写操作的流程如下:" \9 R2 V9 r7 r6 p
' ], P- m) z5 C" I% t$ w' U0 Q 在primary上完成写操作;/ {: }, G9 h1 J6 z; B) U2 t
写操作被记录在primary的oplog中,oplog中包含一个ts字段,记录了写操作发生的时间t; 7 `/ ?7 }! _0 R* O) q! H. f" u 客户端在primary中执行{getLastError:1, w:2}命令,primary完成了写操作,只要再有一个节点完成写操作,就可以满足w:2 了;) H ]* [5 z9 W" s* A5 D
secondary从primary获得oplog,获得上一次操作的记录;* u& H9 R5 c- w( g: q5 _
secondary执行oplog中刚才那一条时间t的操作; % d& ~* c& p! O" A% a secondary从primary的oplog中获取时间t之后的log,条件为{ts:{$gt:t}};) w1 Y# {/ d5 a
primary知道了secondary已经成功执行了时间t之前的oplog,因为secondary已经在请求时间t之后的oplog了; , {9 y. y- H9 B3 I getLastError知道primary与secondary都完成了这次写操作,于是 w:2 的条件满足了,向客户端返回成功。 - E9 i6 {7 U% g7 I6 [! J: f, W& l* V7 ^* K; m, T
启动 9 U" A7 V' k; q/ V% h0 t: E' F, r3 v6 B
当在现有的某个replica set中加入一个新节点并启动时,这个新节点会查看自己的local.oplog.rs collection,执行一个叫 lastOpTimeWritten 的命令,查找到它最近的一条被secondary同步过的写操作。 4 z: y* v' K: K8 l- H/ u- b& L4 c$ `# x1 \& M
这个命令会返回一条oplog记录,其中的ts字段就是最近一次写操作的时间。如果一个节点启动的时候,oplog里没有数据,这个节点会同步其他节点中的所有数据。 : Y- l$ _! C: R7 p1 g8 S' v ' ~2 Y) N' F. H g5 F选择同步源节点 - Z4 y- J' [! W' n9 q! x6 V 5 X$ Y: x) C5 d$ X4 Y& d Replica Sets中的节点从距离它“最近”的节点同步数据,这个“最近”是通过ping的时间来判断的。在节点之间的心跳检测中,会记录ping某个节点和收到响应的时间,通过这个时间的长短,来确定距离的远近,时间越长视为距离越远。知道了和节点之间的距离,再通过如下的算法,来确定可以同步数据的源节点: & P5 p) `6 ~+ ^' K1 g* p* ~! s1 ~( F! {: O8 {+ ` }! z
for each member that is healthy:, [2 @" b. P2 |9 d3 N0 h
if member[state] == PRIMARY5 |# N' g% f H: ], a0 _
add to set of possible sync targets " L" E2 z- d1 @$ g* a* u 3 q R2 c$ b2 N) m+ d/ a if member[lastOpTimeWritten] > our[lastOpTimeWritten]; i/ Q7 p) N/ `1 f& j! {( _* f
add to set of possible sync targets9 R0 {, a l6 g% N/ X: h) J, x4 f
2 h& J, X' i/ G! f4 O: Esync target = member with the min ping time from the possible sync targets . K' c( V' g0 w) E0 ]( p# f7 C4 p+ k3 t
对于节点是否健康,MongoDB各个版本的判断依据有所不同,但都是为了找到能够正常运行的节点。" r+ m" q2 V: }" z% U- W }