몽고db 동기화 과정 / 데이터 동기화 / replica set 의 동기화 / 어떻게 동기화 / 싱크 / 데이터 싱크 /
ref.1 에 대한 번역의 일부이다.
MongoDB 의 Replica Set Data 동기화
- replica set 의 secondary member 들은 다른 멤버들로 부터 sync 또는 data 를 복제한다.
- mongodb 가 2가지 형태의 data sync 를 사용한다.
- initial sync 는 새로운 멤버들이 full data set 과 함께 시작할 수 있게 하기위해서이고,
- 복제(replication) 은 계속진행되는 변경을 모든 data set 에 적용하기 위해서 한다.
initial Sync
replica set 의 한 member 의 모든 data 를 다른 member 에게 copy 하는 것이다.
mongodb 4.4 부터 initialSyncSourceReadPreference parameter 를 이용해서 선호하는 iniitial sync source 를 지정할 수 있다.
과정
localdatabase 를 제외한 모든 database 를 복제한다(clnoe). 복제하기 위해서 mongod 는 각 source database 에 있는 모든 collection 을 scan 하고, 모든 data 를 이 collection 들의 복사본에 넣는다.3.4 부터는 initial sync 는 document들이 각 collection 에 copy 될 때, collection 의 모든 index들을 만든다. 예전에는
_idindex 들만 만들었다고 한다.3.4 부터는 data copy 를 하는 동안에 새롭게 추가된 oplog record 들을 pull 한다. target member 는 local database 안에 충분한 disk space 를 갖는 것을 보장해야 한다. 이
localdatabase 에 data copy stage 동안에 pull 하는 oplog record들을 임시적으로 저장하기 때문이다.모든 변경들이 data set 에 적용된다. source에서 온 oplog 를 이용해서 mongod 는 replica set 의 current state 를 반영하기 위해 data set를 update 한다. initial sync 가 끝나면, member 는
STARTUP2에서SECONDARY로 바뀐다.
Replication
initial sync 이후에 Secondary members 들은 data 를 계속해서 복사한다. secondary member들은 oplog 를 sysnc from source 로 부터 oplog 를 copy 하고, 이 작업들(operations)을 비동기 처리로 적용한다.
Secondary 들은 필요할 때 자동으로 그들의 sync from source 를 변경한다. 변경할 때는 다른 멤버들의 replication 의 상태와 ping time 의 변화에 근거해서 변경한다.
sync source 를 선택하는 법은 여기를 참고하자.
Streaming Replication
sync from source들은 그들의 “동기화하는 secondary 들”에게 연속적인 oplog 항목들의 stream 을 보낸다. streaming replication 은 높은 부하와 높은 대기시간(latency) 에 있는 네트워크에서 생기는 복제 지연(replication lag) 을 완화시킬 수 있다.
그것은 또한:
- secondary들로 부터의 읽기에 대한 staleness(만든지 오래된) 를 줄인다.
w: 1write operation들을 잃어버리는 위험을 줄인다.w: "majority"와w: >1write operation 들의 latency 를 줄인다.(즉, replication 을 기다리는 모든 write concern )
v4.4 이전에서는 secondary 들은 sync from source 에 대한 request 를 발행하고 response 를 기다리는 방식으로 oplog entries 의 batch 들을 가져왔다.(fetch)
이를 위해 각 oplog entries 의 batch에 대한 네트워크 roundtrip이 필요했다. MongoDB 4.4는 스트리밍 복제를 비활성화하고 이전 복제 동작을 사용하기 위해 oplogFetcherUsesExhaust 라는 startup parameter를 추가한다.
sync from source에 리소스 제약 조건이 있거나 replication에 대한 MongoDB의 네트워크 대역폭 사용을 제한하려는 경우에만 oplogFetcherUsExhaust 를 false로 설정하자, 이 값이 false 이면, streaming replication 을 사용하지 않는다는 의미이다.
Multithreaded Replication
MongoDB는 동시성(concurrency)을 향상시키기 위해 여러 스레드를 사용하여 묶어서 한번에(in batches) write operations 를 한다. MongoDB는 document ID(WiredTiger)에 따라 batch를 그룹화하고 동시에, 다른 스레드를 사용하여 각 operation에 대한 group을 만든다. MongoDB는 항상 document에 대해서 그들의 원래 write order 로 write operation을 한다.
버전 4.0에서 변경
MongoDB 4.0부터는, 만약 read 가 이 replcation batch 들이 적용되어지는 secondary 에서 수행된다면, secondary들에서 수행하면서, read concern level 이 local 또는 majority 로 설정된 읽기 작업들(read operations)은 WiredTiger snapshot data로 부터 data 를 읽어오게 된다.
snapshot 에서 읽으면 데이터를 일관되게 볼 수 있으며, lock 없이 지속적인 복제(replication)와 동시에 읽기가 가능하다. 따라서 이런 read concern level 들을 필요로 하는 secondary read 들은 더이상 replication batch들이 적용되기를 기다릴 필요가 없으며, 수신되는대로 처리할 수 있다.
me: local, marjority 라는 read concern level 을 사용하면 snapshot 에서 data 를 읽어오게 되고, 그런 이유로 replication batch 로 인해 발생할 수 있는 대기시간을 없앨 수 있다.
Flow Control
MongoDB 4.2 부터, 관리자들은 primary 가 그것의 write 들이 “replica set 의 대다수의 member 들에게 oplog 가 write 되는 시간(majority comitted lag)” 을 유지하면서 write들을 수행하도록 비율(rate)을 제한할 수 있다.
이것은 flowControlTargetLagSeconds를 이용해서 할 수 있는데, 이 설정값에 ‘지연(lag)’ 의 최대치’를 설정할 수 있다.
기본적으로, flow control 은 enabled 되어 있다. enableFlowControl 로 설정할 수 있다.
see also:
replication sync source 선택
MongoDB 4.4 부터, initial sync source 를 선택할때는 startup parameter initialSyncSourceReadPreference replica set 의 settings.chainingAllowed 세팅보다 우선순위를 갖는다.
replica set member 가 성공적으로 initial sync 를 수행한 후, replication sync source를 선택할때는 chainingAllowed 를 따르게 된다.
댓글 없음:
댓글 쓰기