Replication은 하나의 중앙 DB에서 하나 혹은 그 이상의 DB에 복사하는 프로세스를 말한다.
write/read가 가능한 원본 Master와 read only혹은 write/read가 가능한 복사본 slave로 구성된다.
두 서버의 데이터 동기화 방식은 동기와 비동기 방식 그리고 반동기 방식이 있는데 기본적으로 비동기로 이루어진다.
- 비동기 방식: Master서버의 데이터 변경이 일어날 때 slave에서 시차를 두고 동기화하는 것
* Master서버에 문제가 발생해 slave에서 복원할 경우 데이터 정합성에 문제가 발생할 수 있다.
- 동기 방식: 데이터에 변경이 일어난 동시에 동기화하는 방식을 말합니다.
* 바로 동기화 되기 때문에 master서버에 문제가 생기더라도 slave서버를 사용하여 데이터 정합성에 문제 없이 서비스를 이어갈 수 있다.
- 반동기 방식: 비동기 방식으로 작동할 때 slave에서 Master의 트랜잭션을 제대로 수신받았는지 확인할 수 없다.
반동기 방식은 master에서 보낸 트랜잭션을 모두 수신했음을 확인할 때까지 기다리리고 복제하는 방식이다. -> 데이터 정합성 문제 보완
3줄 요약
- Master: 클라이언트가 데이터에 대한 CRUD 요청 시 Binary Log를 생성하여 slave에 전달
- Slave: Master로부터 받은 Binary Log를 사용해 데이터에 반영 *Master로 승격이 가능하다.
- Master와 slave는 항성 연결되어 있지 않아도 되며, 간헐적 연결을 통해 데이터를 복제할 수 있다.
하나의 DB로 구성했을 때 트랜잭션이 몰려 성능이 저하될 수 있고 백업을 안했을 경우 문제가 발생할 수 있다.
-> Replication을 사용하여 DB를 복제했다면 트랜잭션이 몰렸을때 여러 서버로 나누어 처리하고 원본 서버의 데이터에 문제가 생겼다면. 복제 데이터를 통해 master서버를 복원할 수 있다.
1.효과
- Scale out solution: 데이터 요청을 slave에 분산함으로 병목현상 해결할 수 있다. 트랜잭션 집중에 따른 성능저하 해결
- Data Security: Slave에 데이터가 복제되며 Slave는 복제 프로세스를 중지할 수 있기 때문에 해당 원본 소스 데이터를 손상시키지 않고 백업이 가능하다.
- Analytics: 실시간 데이터를 소스에서 생성할 수 있으며, 정보분석을 Master가 아닌 slave에서 실행할 수 있다. -> 서비스에 영향을 주지 않고 정보분석
- Long-distance data distribution: 여러 지역 혹은 local에 copy할 수 있어 지리적으로 문제가 생겼을때 복구하거나 master서버에 영구적으로 access하지 않아도 원격 사이트에 로컬 복사본을 만들 수 있다.
2.복제
Master서버의 데이터를 slave서버에 복제하는 방식
- SBR (Statement Based Replication): SQL문을 복사
- 이점: 검증된 기술, 로그 파일에 기록되는 데이터가 줄어든다, 변경된 모든 쿼리문이 들어있기에 DB audit에 사용할 수 있다.
- 단점: 데이터를 일부 수정하는 문(INSERT, UPDATE, DELETE, REPLACE)은 복제하기 어렵다, 문장으로 처리되는 Non-Deterministic(UUID, SETDATE 등)은 데이터를 올바르게 복제할 수 없다. -> 경고 발생
- RBR (Row Based Replication): 변경된 Row만 복사
- 이점: 모든 변경 사항을 복제할 수 있습니다.
- 단점: SBR에 비해 더 많은 내용을 기록해야 한다, 이는 백업 복구에 더 많은 시간이 소요된다.
- MBR (Mixed Based Replication): 위의 두가지 방식을 섞어서 복사. 평소에는 SBR로 동작하다 Non-Deterministic(UUID, rand, Timestamp, 등)을 만나면 RBR 방식으로 전환하여 기록하는 방식
MySQL에서는 기본적으로는 SBR 방식을 사용한다.
- GTID(Global Transaction Identifiers) 적용: Master에서 commit된 각 트랜잭션에 관계되고 생성된 고유한 식별자. *원래 있던곳 외에도 복제 서버에서도 고유함 GTID는 원본에 커밋된 트랜잭션이 복제본에도 적용됐는지 판단할 수 있다. -> 일관성 보장
3.동작
- Slave서버에서 START SLAVE 명령문을 입력하면 slave 서버는 하나의I/O thread를 생성
- I/O thread는 Master에 접속하여 bin-log에 기록돼있는 업데이트 기록을 요청한다.
- Master서버에서 실행된 모든 SQL문 기록을 Binlog dump thread가 이를 읽어서 Slave로 전송한다
- Slave의 I/O Thread가 bin-log 내용을 수신 받은 slave의 Relay Log에 기록 한다.
- SQL Thread가 수신 받은 내용을 Slave서버에 적용한다.
Binlog dump thread: 소스는 복제본이 연결될 때 이진 로그 내용을 복제본으로 보내는 스레드를 작성합니다.
Replication I/O Thread: Master서버에 bin-log를 요청하고 binlog dump thread로 부터 받은 bin-log 데이터를 relay log에 순차적으로 입력
Replication SQL Thread: I/O thread를 통해 기록된 relay log를 읽어 스토리지 엔진에 replay하는 thread이다. 실제로 소스를 적용하기 때문에 i/o스레드에 비해 처리량과 연산이 많다.
4.주의
복제를 수행하기 위해선 bin-log에서 기록을 가져와야 하는데 이 때 원본 서버에서 데이터에 대한 수정이 일어나고 있다면 잠시 중단한 후 원본의 현재 bin-log 좌표를 가져와야 한다. 이는 원본 서버의 데이터가 변경됨에 따라 data dump와 원본 서버의 데이터가 일치하지 않게 되고 복제본이 일관되지 않거나 DB의 데이터 무결성을 잃을 수 있기 때문이다.
참고
https://dev.mysql.com/doc/refman/8.0/en/replication.html
http://www.dbguide.net/db.db?cmd=view&boardUid=146593&boardConfigUid=9&boardIdx=128&boardStep=1