[DB 8편] MySQL 복제 정리

목차는 DB 목차 에 있습니다.

[DB 8편] MySQL 복제 정리

MySQL 복제 동작 방식

• 소스는 트래픽을 받아내는 서버를 의미하며, 레플리카는 복제 서버를 의미합니다.
• 아래 동작 방식은 비동기로 이루어집니다. (I/O 처리)

순서

1. 소스에서 트래픽 (데이터 변경 요청) 이 들어오면 바이너리 로그에 이벤트를 기록합니다.
2. 복제 서버 (레플리카) 는 소스 바이너리 로그에 접근해 릴레이 로그에 copy 합니다.
3. 복제 서버 (레플리카) 는 릴레이 로그를 읽어서 데이터를 변경합니다.

MySQL 복제 형식

명령문 기반 복제

• 로그에 저장할 때, SQL 명령문을 저장합니다. 레플리카는 릴레이 로그에 저장된 SQL 문을 실행합니다.

명령문 방식 장단점

• 명령문으로 저장하기에 로그 사이즈가 작습니다.
• 비결정적 쿼리 (실행할 때마다 결과가 바뀌는) 의 경우 데이터 불일치가 발생할 수 있습니다.
  • 예를 들면, test 라는 테이블의 100 줄을 삭제하는 명령의 경우 order by 가 없다면 원치 않는 데이터가 삭제될 수 있습니다.

ROW 기반 복제

• ROW 가 변경된 것을 로그에 저장합니다.

ROW 기반 복제 장단점

• 데이터가 정확하게 복제됩니다.
• ROW 를 기반으로 데이터를 로그에 저장하기에 변경되는 데이터가 많을수록 로그 사이즈도 커집니다.

혼합 기반 복제

• 명령문 + ROW 기반 복제를 혼합해서 사용합니다.
• 기본 동작방식은 명령문으로 동작하다가 특정 조건에서 ROW 기반으로 동작합니다.

MySQL 복제 구성

액티브, 패시브 구성

• read, write 를 하나의 소스 서버에서 처리합니다.
• 데이터 복제 지연에 대한 문제점이 없습니다.
• fail over 를 하기 위해 레플리카 서버는 소스 서버와 비슷하거나 그 이상으로 구성해야 합니다. 또한, n+2 서버를 구성해야 합니다.
• 트래픽이 늘어난다면 샤딩을 통해 트래픽을 분산시켜야 합니다.

액티브, 리드풀 구성

• 읽기는 레플리카 서버에서, 쓰기는 소스 서버에서 처리하는 구성입니다.
• 읽기 서버의 경우 데이터 동기화 문제로 인해 scale out 에 제한이 있습니다.
• fail over 를 위해 레플리카 서버 (읽기) 중 1개는 스펙이 좋아야 합니다.
• 소스 서버 --> 레플리카 서버 간 복제가 일어나며, 데이터 불일치가 발생할 수 있습니다.