Transcript 2012_07_28_발표자료(강동운). - 이스트럭 블로그

한국 몽고디비 사용자 그룹 제 2회 Meetup
MongoDB HA(Replication & Sharding)
Backup & Restore
작성자: 강동운([email protected])
발표일: 2012년 7월 28일
소개
강동운(Software Engineer)
Electronic Arts FIFA Online
Email: [email protected]
Blog: http://eastluck.tistory.com
Facebook: http://www.facebook.com/eastluck
주요 업무 및 활동
- MongoDB 공식 한국 사용자 그룹 스터디
- SQL Server MVP 2012
- SQLer.com 이스트럭(강동운)
- SQLer Vision Study Leader
Contents
Replication
- 복제 셋(Replica sets) 과 master/slave 복제
- 데모
- 복제 셋 삭제, –rest 및 유의점
Sharding
- chunk, balancing, balancer
- config server, mongos
- Sharding DEMO
백업과 복원
- mongodump, mongorestore
- 세컨더리 파일 복사
Replication
고가용성의 기능(미러링)
복제 셋(replica set)
- 표준, 수동, 결정권자 노드
Master/Slave Replication
oplog 와 heartbeat, Priority
Replication 종류
복제셋(replica sets)
- 자동 장애조치 가능
- 12개 노드까지 구성 가능
- 홀수 노드로 구성 권장
마스터,슬레이브(master-slave)
- 자동 장애조치 불가능(수동)
- 13개 이상 노드까지 구성 가능
- 현재 잘 안 쓰임
Oplog와 heartbeat
oplog
- capped collection
- local database 내에 저장
- collection 이름, 타임 스탬프
변경된 document를 저장
Heartbeat(심장 박동)
- 2초마다 각각 서버들에게 ping
전달
- 서버의 상태를 체크
Priority
Priority
- 서버내 우선 순위
- 기본 값 1
- 0일 경우 수동노드
복제 셋 노드 종류
표준 노드
- 1개의 PRIMARY
- N개의 SECONDARY
단, Priority > 0
수동 노드
- 복제된 데이터는 가지고 있음
- Priority = 0
- 마스터가 될 수 없다.
복제 셋 노드 종류
결정권자 노드
- ARBITER 라고 함
- 데이터를 저장하지 않음
- PRIMARY FAILOVER 시 투표에는
참여
복제 셋 기본 구조
핑(heartbeat)
PRIMARY
SECONDARY
복제
핑(heartbeat)
ARBITER
핑(heartbeat)
SECONDARY
PRIMARY
복제 셋 기본 구조
PRIMARY
SECONDARY
Priority 1
SECONDARY
Priority 1
SECONDARY
Priority 1
SECONDARY
PRIMARY
Priority 40
복제 셋 기본 구조
PRIMARY
SECONDARY
Priority 1
SECONDARY
PRIMARY 1
Priority
1초전 동기화
SECONDARY
Priority 0
SECONDARY
Priority 1
3초전 동기화
복제 셋 셋팅 방법(서버시작)
mongod
--dbpath C:\DATA\first1 --port 10001
--replSet first --oplogSize 10
--rest
mongod
--dbpath C:\DATA\first2 --port 10002
--replSet first --oplogSize 10
--rest
mongod
--dbpath C:\DATA\firstarbiter --port 10003
--replSet first --oplogSize 10
--rest
복제 셋 셋팅 방법 1
mongo localhost:10001/admin
db.runCommand(
{"replSetInitiate" :
{"_id" : "first", "members" :
[
{"_id" : 1, "host" : "localhost:10001"}
, {"_id" : 2, "host" : "localhost:10002"}
, {"_id" : 3, "host" : "localhost:10003",
arbiterOnly: true }
]
}
}
)
Ex) {"_id" : 2, "host" : "localhost:10002", "Priority" : "50"}
복제 셋 셋팅 방법 2
mongo localhost:10001/admin
rs.initiate()
rs.add(“localhost:10002”)
rs.add(“localhost:10003”, {arbiterOnly: true })
복제 셋 시작옵션 --rest
포트번호 + 1000번 웹으로 접속
--rest 옵션
옵션모든
추가
및
–replSet
설정
끝경우
접속!
--rest
--rest
과
옵션
--replSet
없는
옵션 없는
추가
경우
Master/Slave 셋팅 방법
mongod
--dbpath C:\DATA\testmaster --port 10011
--oplogSize 10
--rest
--master
mongod
--dbpath C:\DATA\testslave --port 10012
--oplogSize 10
--rest
--slave
--source localhost:10011
복제 셋 및 Master/Slave
DEMO
복제 셋 삭제
Rs.remove(‘localhost:포트번호’)
서버 재시작 해야 함.
초기화 방법은??
서버 내리고 … local.* 파일을
지우시는 것이…
복제 셋 유의 점
홀수 노드로 구성 권장
프라이머리 선출
ARBITER 가 없어도 작동 함
SECONDARY에서 데이터를 읽기
위해서는 rs.slaveOk() 를 수행
Sharding
분산 처리
Shard Key(예: idx 또는 id, name 등)
Member(100만)
샤드1
샤드2
Member
(25만)
Member
(25만)
샤드3
샤드4
Member
(25만)
Member
(25만)
Sharding
샤드1
샤드2
샤드3
샤드4
샤드5
Member
(400 G)
(500
Member
(400 G)
(600
(500
Member
(400 G)
(700
(500
Member
(400 G)
(900
(500
Member
(400 G)
F
A <= ID < C
K
F <=
C
<= ID
ID <
<K
H
T
K <=
H
<= ID
ID <
< TQ
Q
<= ID
ID <
< ZT
T <=
Z
T <= ID < Z
100G
200G
300G
400G
Sharding(Chunk)
한 샤드 안에는 N개의 청크가 있다.
Chunk의 기본 사이즈 64 MB
(원랜 200MB, v1.8 이후로 64 MB)
--chunkSize N 옵션으로 조절 가능
그냥 쓰는게 바람직..
Sharding
샤드1
샤드2
샤드3
샤드3
샤드5
Member
(400 G)
(500
Member
(400 G)
(500
Member
(400 G)
(500
Member
(400 G)
(500
Member
A <= ID < C
F
F <= ID < K
I
K <= ID < T
Q
T <= ID < Z
X
100G
100G
100G
100G
C <= ID < F
I <= ID < K
Q <= ID < T
X <= ID < Z
Sharding(Chunk 예제)
샤드1
샤드2
샤드3
샤드3
샤드5
Member
(500 G)
Member
(500 G)
Member
(500 G)
Member
(500 G)
Member
(500 G)
A <= ID < C
F <= ID < G
C <= ID < F
G <= ID < J
J <= ID < K
N <= ID < Q
R <= ID < S
Q <= ID < R
S <= ID < T
K <= ID < N
T <= ID < X
X <= ID < Z
Sharding(Balancing)
샤드 서버의 청크의 숫자 조절
작업을 수행하는 프로세스(balancer)
샤드1
샤드2
Member
(청크 50개)
49개)
Member
(청크 48개)
49개)
청크 1개 이동
Sharding(Config server)
3개의 Config 서버가 필요
Config DB의 chunks collection에
chunk 정보 저장
하나라도 죽을 경우 balancing
작동 안함
Sharding(Mongos)
어플과 디비의 게이트웨이
어플은 단일 서버로 취급할 수 있다.
쓰거나 읽을 때 참조 해야 함.
개별 샤드로 접근 시 데이터 인식
못함.
Sharding(구조)
Config1
Mongos
CLIENT
Config2
Config3
샤드 1
Primar
y
Second
ary
Arbiter
샤드 2
Primar
y
Second
ary
Arbiter
샤드 3
Primar
y
Second
ary
Arbiter
Sharding(DEMO chunkSize 1)
샤드(fourth)
P(50010)
S(50011)
2.5만
2.5만
Config1
(50051)
Mongos
(55555)
Config2
(50052)
A(50012)
Config3
(50053)
샤드(first)
10만
P(50001)
3.3만
2.5만
S(50002)
3.3만
2.5만
A(50003)
샤드(second)
샤드(third)
P(50004)
S(50005)
P(50007)
3.3만
2.5만
3.3만
2.5만
3.3만
2.5만
A(50006)
S(50008)
3.3만
2.5만
A(50009)
Sharding
DEMO
백업
Mongodump
파일 복사를 하는 방법
백업(mongodump)
Mongodump
–h 호스트명
--port 포트명
–d 데이터베이스명
-o 백업디렉토리명
복원(mongorestore)
Mongorestore
–h 호스트명
--port 포트명
–d 데이터베이스명
디비명
--drop (있는 경우 삭제)
백업(파일 복사 방법)
PRIMARY 를 복사하지 말자
(파일에 LOCK이 걸릴 수 있음)
SECONDARY 복사
db.fsyncLock()
하지만!! 밸런서가 움직이고 있다!
Config 서버 중 한대를 정지 후 복사
복사 후 db.fsyncUnLock()
백업 및 복원
DEMO
SUMMARY
복제 셋, master/slave 복제
sharding(chunk, balancer, config
server, mongos)
백업과 복원(mongodump,
mongorestore, 파일복사)
Document 공간을 미리 확보하자
참고 자료
주디아줌마 블로그
http://judydba.tistory.com/169
MongoDB 활용 가이드
MongDB 완벽 가이드
MongoDB.org DOCS
감사합니다.