爱吱声

标题: Replica Set的数据同步 [打印本页]
作者: shengnan007    时间: 2012-9-18 13:20
标题: Replica Set的数据同步
    上一篇文章，我们了解了replica set是如何选举出primary的。当primary被选举出来，就开始处理系统中的写数据的请求，secondary要及时的同步这些写到primary中的最新的数据，保持MongoDB中数据的一致性，那么secondary是如何进行数据同步的呢？接下来我们详细分析这个问题。
  Q7 t- R+ U( L' V8 w$ O2 r) {* P/ O# G. g& Q+ i& W( E
同步1 k, K# C: U$ o: s2 \9 N

- Y& d+ D3 L( N- o) K" w    一个secondary在正常运行时，会选择replica set中的一个节点，从这个节点中叫做local.oplog.rs的collection，拉取oplog同步日志。获得同步日志后，进行下边的三项操作：7 g2 M/ d; Q3 R: h& L- u0 h
    执行op日志" B: G2 ~/ P/ B
    将op日志写入到自己的oplog中(也就是local.oplog.rs)0 p6 P4 @! A/ j- n! P- G8 R/ }
    请求下一个op日志
5 G6 @4 l5 j# U3 q! j8 L  A; K$ e5 t  C! G9 ^
    如果在第一步执行完毕，第二步还没有执行完的时候，secondary宕机了，那么在secondary重新恢复之后，会认为第二步的写操作还没有执行，重新开始执行第二步。在MongoDB的设计中，oplog的操作是具有幂等性的，也就是说将oplog中的某一条操作记录执行多次，不会影响结果的正确性。, P+ p$ R% a& m8 m" e4 I3 a) J

& [7 M( M. e- m% ?/ l  t8 L* ^' H    比如说，有一个数据是{counter:1}，我们在primary中，对这个数据执行了操作{$inc:{counter:1}}，就是把counter字段的值增加1，结果是{counter:2}。Oplog不会记录inc操作，而是直接记录{$set:{counter:2}}。因此，对于oplog中的操作记录，无论执行多少次，都不会影响结果的正确性。! J5 ]) L0 X' m
# {" g6 W( f& z9 T: S& R% d0 O7 y
w参数( z$ E# Z4 h# |# s

3 ^5 W3 K* V! g: L2 O) d2 u7 W8 v    当我们在MongoDB中执行一个写操作时，默认情况下，写操作指令发送后，就认为写操作执行成功了。为了保证系统可用性和数据安全性，我们可以更改配置，当写操作在n个节点（n包括primary，如果n=1，那就是在primary执行成功后返回）都执行成功后，才返回成功。这个配置的命令如下：9 W* G+ [4 b! d; I9 `
db.foo.runCommand({getLastError:1, w:2})
  ]  G+ k+ R1 |+ |+ [$ J) y; N8 d0 V. I( ^' Q
    在更改了这个配置之后，执行写操作的流程如下：
' Y* G) a7 {" a" a8 P5 X6 ^+ x  d) B5 ?/ W. j/ e
    在primary上完成写操作；1 ?, l% \6 B8 t4 r  G1 e
    写操作被记录在primary的oplog中，oplog中包含一个ts字段，记录了写操作发生的时间t；
) b! [+ B$ {: V9 _- y! w, }    客户端在primary中执行{getLastError:1, w:2}命令，primary完成了写操作，只要再有一个节点完成写操作，就可以满足w:2     了；4 g# j9 r+ V2 ]; D- I# a, b# w% X
    secondary从primary获得oplog，获得上一次操作的记录；9 l: N; r1 C& u) W' [
    secondary执行oplog中刚才那一条时间t的操作；  z8 _, H# H* B4 B
    secondary从primary的oplog中获取时间t之后的log，条件为{ts:{$gt:t}}；
" X# }) W# J: W& V    primary知道了secondary已经成功执行了时间t之前的oplog，因为secondary已经在请求时间t之后的oplog了；0 x0 _  b( H; [4 f
    getLastError知道primary与secondary都完成了这次写操作，于是 w:2 的条件满足了，向客户端返回成功。2 R. R" u3 r( S/ y5 f+ S5 k( N+ l/ [7 j

- f* R7 p6 D$ w4 ^" b启动9 o/ @3 Q, ]8 k5 o* v4 D) D& ^
8 f0 U6 E# D2 D# H* v  m! t
    当在现有的某个replica set中加入一个新节点并启动时，这个新节点会查看自己的local.oplog.rs collection，执行一个叫 lastOpTimeWritten 的命令，查找到它最近的一条被secondary同步过的写操作。
; Z) d5 u( G0 v5 ~& S' T7 Z* v& t' X! f
    这个命令会返回一条oplog记录，其中的ts字段就是最近一次写操作的时间。如果一个节点启动的时候，oplog里没有数据，这个节点会同步其他节点中的所有数据。0 G( D7 b2 p7 ]4 a) E
& ?) T% l9 K  x/ s0 b
选择同步源节点
# r- S$ T8 B9 ?2 G0 m% n$ M" w4 S) k
    Replica Sets中的节点从距离它“最近”的节点同步数据，这个“最近”是通过ping的时间来判断的。在节点之间的心跳检测中，会记录ping某个节点和收到响应的时间，通过这个时间的长短，来确定距离的远近，时间越长视为距离越远。知道了和节点之间的距离，再通过如下的算法，来确定可以同步数据的源节点：
! M. w9 ?" ~& Z; O/ D
  Y# p* B6 a; E+ v$ b- cfor each member that is healthy:  V( F) [+ |0 v, \8 e
    if member[state] == PRIMARY" }) u5 @- m- `  \# M; Z
        add to set of possible sync targets& z4 V/ P6 P8 W* S' x0 a

- n7 h( F. e7 O: S; w6 e% {  O1 w& w    if member[lastOpTimeWritten] > our[lastOpTimeWritten]
  m2 V/ e, w% I; b6 l        add to set of possible sync targets
5 K+ [+ G: }) [5 \( u" o" Y8 S# }' p. p) Z$ m, p( t; t( ~. D$ J- i
sync target = member with the min ping time from the possible sync targets1 q0 [7 I( I7 k* t; K! n9 ]# D
1 w5 T& ^  Q9 \1 L% B- c
    对于节点是否健康，MongoDB各个版本的判断依据有所不同，但都是为了找到能够正常运行的节点。4 m9 z5 e* G* o7 _- q* o
8 G* N4 T. N- {& R' _
    我们可以通过运行db.adminCommand({replSetGetStatus:1})命令来查看当前的节点状况，在secondary上运行这个命令的时候，能够看到syncingTo这个字段，这个字段的值就表示secondary节点同步数据的源节点。
  W0 x5 W8 H( n8 Q. Q: P- p
$ z% D/ [2 S+ e链式同步5 B# E6 E5 b/ F4 g4 j

! ?8 m( }6 M9 `, G2 F$ H    前边所说的内容，都是假设有一个primary和一个secondary，这种情况下的同步过程比较简单，但是如果有2个secondary或者更多，那么这个过程就要复杂的多。
) P' u2 {+ X5 k1 @" n9 V; x2 [- q' Q. E8 V& g) v% n( k$ O6 e
    我们用w：3来说明这个问题。比如S1和S2节点是secondary节点， P节点是primary节点，S1节点从P节点同步数据，S2节点从S1节点同步数据。这样P -> S1 -> S2 之间就形成了一个链。如果我们设定w为3，那么除了primary写入数据，还需要有两个secondaris完成同步，才可以返回成功。那么P节点如何能知道S2节点已经从S1节点同步成功了呢？
, Q4 [( u# \- K6 ~# [1 M
% i* t* ?2 T3 R* s( @/ q    MongoDB通过oplog同步协议来解决上述的多个节点同步的问题。" B2 M$ ^! h7 U+ }

3 [) X3 c$ B% l1 B    当S2从S1同步数据时，S2会给S1发送一个特殊的握手消息，“Hi，我是S2，我要从你这同步数据了，把我也算到w参数里边吧。”0 D# [" \7 J3 N. D, l

/ S: Z5 v: F& s0 ]7 f7 L$ B9 L: D    当S1收到这个消息的时候，会说，“我不是primary节点，我可以把你这个计数转到我的同步源中去。”然后S1打开一个到P的新的连接，然后对P说，“这个连接你就当是S2的吧，把S2也算到w的计数中。”这个时候，S1和P之间有两个连接，一个是S1自己的，一个是为S2建立的。
4 T* j( j. ?% V7 @; `& z! D: a4 k1 L: W6 `
    当P执行完写操作之后，S1首先会获取到P的oplog，执行完这个写操作之后，会告诉P，我已经执行完了。然后S2从S1获取到最新的oplog，同样执行这个写操作，执行完之后，告诉S1，我已经执行完了。S1在收到S2执行完毕的消息后，就通过S1代替S2建立的和P的连接，告诉P，我是代替S2建立的连接，现在S2也执行完这个写操作了。这个时候，P就知道已经有P、S1和S2都完成了这个写操作，w：3已经满足了，然后返回成功，完成这次操作。
% Z6 ]2 P6 Y( }6 ^$ S# F/ C
8 t! b4 W/ t: Y& E0 r; \    具体三个节点间的连接如下图：
0 @6 D1 Y' x1 E# ~) Z& L
    S2                  S1               P

1 T5 \6 i- L1 B
                             <====>

% W3 U/ C5 x/ [+ d' M+ q
         <====>       <---->
% P" t* n0 O* ?4 ?" m, `( y6 P

* e: d1 W! {+ U2 ^7 z    S1和P之间有两条通道，双线那条是真正的同步连接，单线那条是一个虚拟连接。
, M: y. z, m0 C. ]) ^: n# Q, t# M" V1 s( p8 y" a/ G

) B. L. ^0 L( {1 WReference，4 }) f+ r- v! i0 n* d
: C+ o5 v/ M# c$ A% C% v
[0] Replica Set Internals Bootcamp Part IV: Syncing  F" m- Q) ~% s7 p, s  }
http://www.kchodorow.com/blog/2012/05/07/replica-set-internals-bootcamp-part-iv-syncing/& P& a: F5 [# b8 E. |
作者: 四处张望    时间: 2012-9-18 13:33
哇...,没想到这里都能看到这类高水准文章。
/ s7 X8 m, u8 F# p可以偷懒不去搜索了。
作者: shengnan007    时间: 2012-9-18 13:34
四处张望 发表于 2012-9-18 13:33 9 g1 G' u1 G- l  a$ y) r
哇...,没想到这里都能看到这类高水准文章。4 G- {2 K+ q! Y8 T+ u
可以偷懒不去搜索了。

2 B& X& U7 J1 ~9 E2 K/ c7 y前期写的一次性发出来了，后续的还要等一等。写的慢啊，哈哈
作者: 四处张望    时间: 2012-9-18 13:46
shengnan007 发表于 2012-9-18 13:34
$ S$ p) g" \" g& T/ X/ V$ [前期写的一次性发出来了，后续的还要等一等。写的慢啊，哈哈
* j' I% O$ d- T& k* v* L& R9 N
邓侃在西河的文章，对我启发很大。可惜最近两年没有实践的机会，mongo db也就是浅尝辄止。现在有这般好帖，正好
作者: 假如十八    时间: 2012-9-18 14:44
电脑小白路过学习。。。



欢迎光临 爱吱声 (http://www.aswetalk.net/bbs/) Powered by Discuz! X3.2