16장 복제

문제 1. 레플리카 서버를 구축하는 목적 4가지를 말씀해주세요

• 스케일 아웃
• 데이터 백업
• 데이터 분석
• 데이터 지리적 분산

문제 2. 바이너리 로그 파일 위치 기반 복제란?

레플리카 서버에서 소스 서버의 바이너리 로그 파일명과 파일 내에서의 위치로 개별 바이너리 로그 이벤트를 식별해서 복제가 진행되는 형태

문제 3. GTID를 사용하는 복제 환경에서 안전하지 않은 쿼리 패턴은?

• 트랜잭션을 지원하는 테이블과 지원하지 않는 테이블을 함께 변경하는 쿼리 혹은 트랜잭션
• create table … select … 구문
• 트랜잭션 내에서 creat temporary table, drop temporary table 구문 사용

소스 서버에서 레플리카 서버로 복제되어 적용될 때 단일 트랜잭션으로 처리되지 않을 수 있음
GTID는 트랜잭션 단위로 올바르게 할당돼야 복제가 정상적으로 동작함

문제 4. Statement 방식과 Row 방식의 차이점

Statement

• 변경 이벤트에 대해 이벤트를 발생시킨 SQL문을 바이너리 로그에 기록하는 방식
• 바이너리 로그 파일의 용량이 작아 저장 공간에 대한 부담이 적고, 복제도 더 빨리 가능
• 비확정적으로 처리될 수 있는 쿼리의 경우 소스 서버와 레플리카 서버 간의 데이터가 달라질수 있음
• 락이 오랜시간 걸릴 수 있음(insert into … select, 풀 테이블 스캔을 유발하는 update)
• 트랜잭션 격리 수준이 Repeatable read 이상이여야 함

Row

• 변경된 값 자체를 바이너리 로그에 기록하는 방식
• 변경된 데이터가 많으면 바이너리 로그 파일의 용량이 커짐
• 락이 최소화됨
• 데이터를 일관되게 복제 가능
• 모든 트랜잭션 격리 수준에서 가능

문제 5. 비동기 복제의 장점은 무엇인가요.

소스 서버가 각 트랜잭션에 대해 레플리카 서버로 전송되는 부분을 고려하지 않기 때문에 트랜잭션 처리 성능이 빠르고, 레플리카 서버에 문제가 생기더라도 소스 서버는 아무런 영향을 받지 않음

문제 6. 반동기 복제의 AFTER_COMMIT 방식에서 Phantom Read가 발생하는 이유를 말해주세요.

AFTER_COMMIT 방식의 경우 소스 서버에서 트랜잭션을 바이너리 로그에 기록하고 스토리지 엔진에서 커밋도 진행하고 나서 레플리카 서버의 응답을 받아 클라이언트에게 결과를 내보냄
레플리카 서버의 응답을 기다리는 상황에서 소스 서버에 장애가 발생한 경우, 사용자는 새로운 소스 서버로 승격된 레플리카 서버에서 데이터를 조회할 때 이전 소스 서버에서는 조회가 되었던 데이터를 보지 못할 수 있음 ⇒ Phantom Read

문제 7. 듀얼 소스 복제 구성에서 ACTIVE-PASSIVE 형태와 싱글 레플리카 복제 구성의 차이점은 무엇인가요.

두 구성 모두 하나의 MySQL 서버에서만 쓰기 작업이 수행되지만 ACTIVE-PASSIVE는 예비 서버인 다른 MySQL 서버가 바로 쓰기 작업이 가능한 상태이기 때문에 쓰기 작업이 수행되고 있는 서버에서 문제 발생시 별도의 변경 없이 바로 예비용 서버로 쓰기가 가능하다는 점이 다르다.

문제 8. 바이너리 로그 그룹 커밋을 할 때 트랜잭션이 어떻게 처리되는지 설명해주세요.

1. Flush : 대기 큐에 등록된 각 트랜잭션들을 순서대로 바이너리 로그에 기록한다.
2. Sync : 앞서 기록된 바이너리 로그 내용들을 디스크와 동기화하는 fsync() 시스템 콜이 수행된다.
3. Commit : 대기 큐에 등록된 트랜잭션들에 대해 스토리지 엔진 커밋을 진행한다.