[mysql] replica 서버 구축하는 목적, 복제방법 w.바이너리 로그

Replication 이란 ?
- 한 서버에서 다른 서버로 데이터를 동기화
> 원본 데이터를 가진 서버를 소스 서버 (= 마스터)
> 복제된 데이터를 가진 서버를 레플리카 서버 (= 슬레이브)

Replica 서버를 구축하는 목적
- 스케일 아웃 : 갑자기 늘어나는 트래픽을 대응하는데 유연한 구조
- 데이터 백업 :
> 레플리카를 안하더라도 백업을 해야 한다
> 백업 과정은 실제 실행중인 쿼리들에 영향을 줄 수 있기 때문에, 레플리카 서버에서 데이터 백업을 실행하여 소스 서버에서 백업 시 발생하는 문제들을 해결한다
- 데이터의 지리적 분산 :
> 데이터베이스의 애플리케이션 서버가 멀리 떨어져 있다면 응답을 늦게 받게 된다.
> 빠른 응답을 위해 애플리케이션 서버에 가깝게 서비스를 구성하는게 좋다.

복제를 어떻게 하는가
- 바이너리 로그 : mysql 서버에서 발생하는 모든 변경사항을 별도의 로그 파일에 순서대로 저장한 것
> 데이터의 변경내역
> 데이터베이스나 테이블의 구조 변경
> 계정이나 권한의 변경 정보
- 동기화가 이루어지는 과정
> 소스 서버에서 생성된 바이너리 로그가 레플리카 서버로 전송되고
> 레플리카 서버에서는 해당 내용을 로컬 디스크에 저장한 뒤
> 자신이 가진 데이터에 반영함
- Binary Log Dump Thread, Replication I/O Thread, Replication SQL Thread
> Binary Log Dump Thread : 바이너리 로그를 레플리카 서버로 전송하는 역할
> Replication I/O Thread : Binary Log Dump Thread가 보낸 Binary Log Event를 가져와 로컬 서버의 파일 (Relay Log) 로 저장
> Replication SQL Thread : Relay Log 파일의 이벤트들을 읽고 실행

바이너리 로그는 어떻게 생겼을까 ?
1. statement 방식 : sql문을 바이너리 로그에 그대로 기록한다.
- 트랜잭션 격리 수준이 반드시 repeatable-read 이상이어야 한다
- 장점 : 손쉽게 sql문을 확인
- 단점 : 비확정적으로 처리될 수 있는 쿼리가 실행된 경우 데이터가 달라질 수 있음 ex, now()나 rand() 같은 비결정적 함수 호출하는 경우
2. row 방식 : 변경된 데이터 자체를 기록한다.
- mysql 5.7 버전 이후부터 바이너리 로그 기본 포맷
- 장점 : 어떤 형태의 쿼리든지 서버의 데이터 일관되게 함
- 단점 : 많은 데이터 변경하면 단시간에 로그너리 파일 커짐
3. mixed 방식 : statement 방식 + row 방식 (mysql 방식)
- 쿼리의 대부분은 statement 방식으로, 안전하지 못한 쿼리는 row 방식

`show binary logs`

`show master status;` 바이너리 파일의 위치 정보 알 수 있음

cf) Write-Ahead Log
- oracle 에서 사용한다.
- 모든 쓰기를 포함하는 바이트 열을 열어서 다른 노드로 전달한다.
- 가장 큰 단점은 저수준의 데이터를 기술한다는 점인데, 어떤 디스크 블록에서 어떤 바이트를 변경했는지와 같은 상세 정보를 포함해, 저장소 엔진과 밀접하게 엮이게 된다.
- 소스서버와 레플리카 서버 사이의 버전 불일치를 허용하지 않기 때문에 업그레이드 시 중단이 필요하다.


참고 >>
1. [10분 데코톡] 영이의 Replication https://youtu.be/95bnLnIxyWI


총평 >>
1/ replica 서버의 목적은 (1) 스케일 아웃 (2) 데이터 백업 (3) 데이터의 지리적 분산이다.
2/ oracle에서 사용하는 write-ahead log은 저수준의 데이터를 기술하기 때문에, 업그레이드 시 중단이 필요하다고 한다. 그래서 은행에서 업그레이드 시에 서버가 잠시 중단되는 것인가라고 생각했다.