爱吱声

标题: Replica Set的数据同步 [打印本页]
作者: shengnan007    时间: 2012-9-18 13:20
标题: Replica Set的数据同步
    上一篇文章，我们了解了replica set是如何选举出primary的。当primary被选举出来，就开始处理系统中的写数据的请求，secondary要及时的同步这些写到primary中的最新的数据，保持MongoDB中数据的一致性，那么secondary是如何进行数据同步的呢？接下来我们详细分析这个问题。
* u) D$ B( g  k+ `3 N& W) e3 |
. x1 C' z# W+ y( m0 d( M, R同步/ D4 [& F. o: u7 J. I' L
* X. B! I0 K! R3 Z% ~% P. g
    一个secondary在正常运行时，会选择replica set中的一个节点，从这个节点中叫做local.oplog.rs的collection，拉取oplog同步日志。获得同步日志后，进行下边的三项操作：9 a) u% V+ l0 r( x
    执行op日志
$ o) ]5 h! h/ ]. }0 d. H    将op日志写入到自己的oplog中(也就是local.oplog.rs)
: G4 Q+ k" V. T3 `* F. d    请求下一个op日志
( i/ q$ t2 r* w+ D; x0 l7 w8 ]# p+ c2 ^9 s
    如果在第一步执行完毕，第二步还没有执行完的时候，secondary宕机了，那么在secondary重新恢复之后，会认为第二步的写操作还没有执行，重新开始执行第二步。在MongoDB的设计中，oplog的操作是具有幂等性的，也就是说将oplog中的某一条操作记录执行多次，不会影响结果的正确性。) m* m/ N( B6 ?4 D; C
6 t% [' {7 m, `* _+ [1 s
    比如说，有一个数据是{counter:1}，我们在primary中，对这个数据执行了操作{$inc:{counter:1}}，就是把counter字段的值增加1，结果是{counter:2}。Oplog不会记录inc操作，而是直接记录{$set:{counter:2}}。因此，对于oplog中的操作记录，无论执行多少次，都不会影响结果的正确性。. m9 {" ^+ Q$ c& k
& L1 t: I; T2 r
w参数, k9 T. @6 \/ f  |, J

$ {5 q& o7 ?; I    当我们在MongoDB中执行一个写操作时，默认情况下，写操作指令发送后，就认为写操作执行成功了。为了保证系统可用性和数据安全性，我们可以更改配置，当写操作在n个节点（n包括primary，如果n=1，那就是在primary执行成功后返回）都执行成功后，才返回成功。这个配置的命令如下：
7 B9 r8 h( h3 I6 {db.foo.runCommand({getLastError:1, w:2})
7 n4 r4 c6 t6 y9 E: L' d$ [( g, s3 o2 z+ E- g/ I
    在更改了这个配置之后，执行写操作的流程如下：; _0 \  ~7 y0 n% ]( s8 i9 Q

/ j! l7 ~4 i$ A: f8 L- c    在primary上完成写操作；
& ~+ h$ f) K4 a( _8 m. D$ a# r; \    写操作被记录在primary的oplog中，oplog中包含一个ts字段，记录了写操作发生的时间t；
- \, f% e) L1 Z9 I$ g    客户端在primary中执行{getLastError:1, w:2}命令，primary完成了写操作，只要再有一个节点完成写操作，就可以满足w:2     了；
9 X3 g6 n; c8 ~. ?- J- V8 C5 @: @    secondary从primary获得oplog，获得上一次操作的记录；
9 W. A$ v/ {3 x; L7 ^) |6 n    secondary执行oplog中刚才那一条时间t的操作；5 o- R; i+ C/ ?+ W
    secondary从primary的oplog中获取时间t之后的log，条件为{ts:{$gt:t}}；
, F* k5 l* A  c5 g; X$ r    primary知道了secondary已经成功执行了时间t之前的oplog，因为secondary已经在请求时间t之后的oplog了；  H' m; Z$ u' \& B3 G8 L6 A( X$ G# B
    getLastError知道primary与secondary都完成了这次写操作，于是 w:2 的条件满足了，向客户端返回成功。1 m, ~5 j( g# P+ A) S6 s  E8 X. a$ |4 U

4 t' M) f, t4 \* U# g启动0 L8 H) b7 q, R! [9 r

! ~+ n/ J/ G' J! A# O    当在现有的某个replica set中加入一个新节点并启动时，这个新节点会查看自己的local.oplog.rs collection，执行一个叫 lastOpTimeWritten 的命令，查找到它最近的一条被secondary同步过的写操作。
6 i6 X: W8 E& I
9 \4 g' x, a- b5 v  l! ~    这个命令会返回一条oplog记录，其中的ts字段就是最近一次写操作的时间。如果一个节点启动的时候，oplog里没有数据，这个节点会同步其他节点中的所有数据。
% y& O7 T' ]* m$ q# }9 N- O, X! o! u% N1 R4 O3 _
选择同步源节点1 V2 c6 u; i' C4 m$ F/ I

9 Z) n+ Q. @, C- L6 x, q3 V+ j8 N    Replica Sets中的节点从距离它“最近”的节点同步数据，这个“最近”是通过ping的时间来判断的。在节点之间的心跳检测中，会记录ping某个节点和收到响应的时间，通过这个时间的长短，来确定距离的远近，时间越长视为距离越远。知道了和节点之间的距离，再通过如下的算法，来确定可以同步数据的源节点：( _" }) [. m+ K9 T7 X# m- ]

- Y( p# y* L1 P/ b& r  ofor each member that is healthy:
% T: F7 N8 P8 h3 c, `    if member[state] == PRIMARY( ~/ O- [# L# @8 `4 U
        add to set of possible sync targets* ?2 e! R; K7 D9 A) p

! r  J1 V2 b) y5 \6 A    if member[lastOpTimeWritten] > our[lastOpTimeWritten]6 u% }1 b3 Y  A! b5 u# t
        add to set of possible sync targets$ Q9 {) ^7 [( p2 Y
+ m( `: q5 A2 v
sync target = member with the min ping time from the possible sync targets, I6 u5 s$ v, o) b1 p0 y% \2 A
) L& v# d' n3 k" j7 l
    对于节点是否健康，MongoDB各个版本的判断依据有所不同，但都是为了找到能够正常运行的节点。; B: Q- j5 O/ z

* o, w+ T4 c7 t( i1 ]    我们可以通过运行db.adminCommand({replSetGetStatus:1})命令来查看当前的节点状况，在secondary上运行这个命令的时候，能够看到syncingTo这个字段，这个字段的值就表示secondary节点同步数据的源节点。+ C, k6 m( o+ r* x& ]* F/ A6 e% J, X

3 E' X% q9 I* D" I链式同步9 \$ ~! V8 e5 Q1 j8 F5 k9 g

" _) k% }. ], U1 _1 ~1 A    前边所说的内容，都是假设有一个primary和一个secondary，这种情况下的同步过程比较简单，但是如果有2个secondary或者更多，那么这个过程就要复杂的多。$ y, x5 _+ N+ {" y8 v- D3 |, w, M
* z& E( H6 ]  u! J5 I+ f
    我们用w：3来说明这个问题。比如S1和S2节点是secondary节点， P节点是primary节点，S1节点从P节点同步数据，S2节点从S1节点同步数据。这样P -> S1 -> S2 之间就形成了一个链。如果我们设定w为3，那么除了primary写入数据，还需要有两个secondaris完成同步，才可以返回成功。那么P节点如何能知道S2节点已经从S1节点同步成功了呢？0 M+ l. g7 B' I

/ o) f9 X: A0 J2 l, G  W    MongoDB通过oplog同步协议来解决上述的多个节点同步的问题。% q5 ?# y. f3 S$ T1 x0 D: d. Q
3 B; y# \: ?' T- m. j% ?5 |
    当S2从S1同步数据时，S2会给S1发送一个特殊的握手消息，“Hi，我是S2，我要从你这同步数据了，把我也算到w参数里边吧。”
  E7 S5 A/ G! w, @: b6 n; X5 H" d7 m6 b( T; ^5 C& X
    当S1收到这个消息的时候，会说，“我不是primary节点，我可以把你这个计数转到我的同步源中去。”然后S1打开一个到P的新的连接，然后对P说，“这个连接你就当是S2的吧，把S2也算到w的计数中。”这个时候，S1和P之间有两个连接，一个是S1自己的，一个是为S2建立的。
1 \& X, D; {& V# C* c0 L& p) T& N+ W/ p
    当P执行完写操作之后，S1首先会获取到P的oplog，执行完这个写操作之后，会告诉P，我已经执行完了。然后S2从S1获取到最新的oplog，同样执行这个写操作，执行完之后，告诉S1，我已经执行完了。S1在收到S2执行完毕的消息后，就通过S1代替S2建立的和P的连接，告诉P，我是代替S2建立的连接，现在S2也执行完这个写操作了。这个时候，P就知道已经有P、S1和S2都完成了这个写操作，w：3已经满足了，然后返回成功，完成这次操作。
3 u8 p" \! P5 Y& Q4 I, r
; p7 C9 Q! L: j) h9 L7 |' p    具体三个节点间的连接如下图：4 t* v* T, z7 n- `0 }
    S2                  S1               P

; R# s1 K0 n( b% T" J
                             <====>

6 m% \  {8 J4 a% [  g
         <====>       <---->
# E* o/ H, K0 }" m: J. ~1 j

1 p( x  e2 x" Z7 ~% ]2 B+ k0 Q    S1和P之间有两条通道，双线那条是真正的同步连接，单线那条是一个虚拟连接。# L5 t: E) h/ u% N/ [' S- V% V

7 C" M8 X3 [+ S- z$ g, e2 [3 Q
' y3 ^- n( g3 x# _, kReference，
+ P* ^/ f# k* J
  V6 ~, }) f/ P; O[0] Replica Set Internals Bootcamp Part IV: Syncing. Z" M' _$ U, o
http://www.kchodorow.com/blog/2012/05/07/replica-set-internals-bootcamp-part-iv-syncing/
  v5 P' H. i' t  L0 z& c
作者: 四处张望    时间: 2012-9-18 13:33
哇...,没想到这里都能看到这类高水准文章。
( z# s' y+ R, a/ l& R8 O5 ^可以偷懒不去搜索了。
作者: shengnan007    时间: 2012-9-18 13:34
四处张望 发表于 2012-9-18 13:33 9 F0 k& g% P5 ~
哇...,没想到这里都能看到这类高水准文章。7 ]4 C+ U: E: C2 ^, `) Z; g
可以偷懒不去搜索了。
+ e& s. n0 `& `  b6 z; }
前期写的一次性发出来了，后续的还要等一等。写的慢啊，哈哈
作者: 四处张望    时间: 2012-9-18 13:46
shengnan007 发表于 2012-9-18 13:34
$ a2 a. q4 P- [3 x' U6 _前期写的一次性发出来了，后续的还要等一等。写的慢啊，哈哈
6 o+ u. v  R) y( l! I1 K+ E" l
邓侃在西河的文章，对我启发很大。可惜最近两年没有实践的机会，mongo db也就是浅尝辄止。现在有这般好帖，正好
作者: 假如十八    时间: 2012-9-18 14:44
电脑小白路过学习。。。



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