mongo db 완벽 가이드 9장 복제 파트 스터디 자료

1. 9장 복제MongoDB전효성http://cafe.naver.com/architect11

2. Single server durabilitySingle server durability 지원이 취약한 이유일부러 하지 않는 않았다.이유는?기존의 DBMS도 single server durability를 보장 못하는 경우가 많다.물리적 파괴와 같은 상황에서 복구가 힘들다.그래서?Multi-server durability를 사용하시라.2

3. 복제의 용도데이터 일관성읽기 분산운영 중 백업오프라인 일괄 작업용 데이터 소스3

4. 마스터-슬레이브 복제Master 노드 생성Slave 노드 생성# mongod --dbpath~/dbs/master --port 10000 --master# mongod --dbpath~/dbs/slave --port 10001 --slave --source localhost:10000Slave 0단방향 복사master…MAX 12대 권장Slave Noplog4

5. 마스터 슬레이브 복제 옵션5

6. Shell에서 사용하기Master 노드 띄우기Slave 노드 띄우기Shell로 slave에 접속6

7. 레플리카 셋복제를 하는 또 하나의 방법자동 장애 넘김클러스터의 마스터가 유동적장애로 마스터가 죽으면 다른 슬레이브가 알아서 마스터로 변신제약사항( ver 1.6+ )최대 12대의 노드 구성최대 7대의 노드가 투표 가능7

8. 레플리카 셋 초기화( ver 1.8+ )Replica set 작동$ mongod --replSetsetname--restReplica set 초기화> rs.initiate()> rs.initiate( <config-object> )> db.runCommand( { replSetInitiate : <config-object> } )Configobject> cfg= { ... _id : "acme_a", ... members : [ ... { _id : 0, host : "sf1.acme.com" }, ... { _id : 1, host : "sf2.acme.com" }, ... { _id : 2, host : "sf3.acme.com" } ] } > rs.initiate(cfg) > rs.status()> rs.add("sf2.acme.com"); > rs.add("sf3.acme.com"); > rs.status(); http://www.mongodb.org/display/DOCS/Replica+Set+Configuration8

9. 장애처리 매커니즘Node type표준 노드(Standard)수동 노드(Passive){ …, “Priority” : 0, … }절대 마스터가 될 수 없다결정권자 노드(Arbiter){ …, “arbiterOnly” : true, … }투표만 한다9

10. 장애 판단 및 복구장애 판단Heartbeat수 대비 voting수가 반 이하로 떨어지면 마스터를 보조 노드로 변경투표를 통해 높은 득표의 노드가 마스터로 변신재 동기화 수행Voting각 노드들이 투표하여 마스터 노드 결정10

11. Vote: 가장 최근에 변경된 노드SlaveMasterVote:6SlaveSlaveSlaveSlaveSlave11

12. 장애 발생SlaveMasterVote:2SlaveSlaveSlaveSlaveSlave12

13. 마스터 노드 결정하기가장최근에 동기화MasterSlaveVote:2SlaveSlaveSlaveSlaveSlave13

14. 마스터 노드 결정하기가장최근에 동기화MasterVote:3SlaveVote:2SlaveSlaveSlaveSlaveSlave14

15. 재 동기화가장최근에 동기화MasterVote:3SlaveVote:2SlaveSlaveMaster의 데이터로 재동기화SlaveSlaveSlave15

16. 슬레이브에서 연산 수행하기슬레이브 사용 용도데이터 백업오프라인 데이터 처리용읽기 분산16

17. 읽기 분산방법1. 생성시 slaveOkey옵션을 지정하여 query를 받을 수 있도록 변경방법2. --master --slave 옵션을 동시에 적요하여 생성쿼리를 받을 수 있고, 마스터로부터 계속 복제가 이루어진다.처음 시작시 빈 db로 시작해야 함17

18. 작동 원리( Oplog )1: CUD commandMasterSlave여유공간 5% 정도2: Oplog에 기록oplog제한 컬렉션멱등원 형태로 변환$inc $set18

19. 작동 원리( 동기화 )초기 연결시: 완전 동기화 진행MasterSlave용량을 넉넉히 잡아서 동기화 중 oplog공간이 부족하지 않게 해야 함oplog19

20. 작동 원리( 동기화 )동기화 완료 이후…MasterSlave[N초마다]복제 요청oplog20

21. 작동 원리( 동기화 )MasterSlave이전 요청 ~ 현재까지 oplog전달oplog21

22. 복제 상태와 로컬 데이터베이스local databaseMongodb에서 사용하는 databaseReplica set에 대한 정보Replica set 관련 collectionlocal.system.replset : config정보local.oplog.rs : oploglocal.replset.minvalid : 내부용, 동기화정보를 추적하기 위한 정보 보관Master/Slave replication 관련 collectionMaster nodelocal.oplog.$main : oploglocal.slavesSlave nodelocal.sourcesOtherlocal.me22

23. 노드 동기화N개의 노드들이 쓰기 연산 복제 완료까지 대기보통 N을 2 ~ 3으로 설정 ( 효율성 / 안정성 trade-off )> db.runCommand( {getLastError: 1, w : N } )23

24. 관리진단Oplog변경> db.printReplicationInfo()configured oplog size: 944.1375732421875MBlog length start to end: 1266secs (0.35hrs)oplog first event time: Thu Aug 04 2011 23:47:12 GMT+0900oplog last event time: Fri Aug 05 2011 00:08:18 GMT+0900now: Fri Aug 05 2011 23:44:46 GMT+0900> db.printSlaveReplicationInfo()source: localhost:27017syncedTo: Fri Aug 05 2011 23:46:11 GMT+0900$ rm /data/db/local.*$ mongod --master --oplogSizesize//slave들을 --autosync로 재시작하거나 수동으로 재 동기화 필요함24

25. 관리인증을 통한 복제마스터 / 슬레이브의local db에 동일한 사용자와 비밀번호 추가Slave 접속 시도“repl”이라는 사용자로 접속시도local.system.users의 제일 처음 이름을 사용> use localSwitched to db local> db.add.User( “repl”, password );{“user” : “repl”, “readOnly” : false, “pwd” : “…” }25

26. 정리복제를 하는 두가지 방법.Master-slaveReplica set ( 편하다 )Oplog사이즈를 적당히 크게 잡아주자.재동기화 방지Slave에 query를 날리려면?--master or --slaveOkey옵션으로 생성26

27. 끝27