로그기반 복제와 마스터–슬레이브 구조: 전산학 데이터베이스를 안전하게 분산하는 방법

데이터를 “복제”한다는 말이 불안하게 들리는 이유부터 정리해야 한다

서버를 두 대로 늘렸는데도 장애가 나면 데이터가 사라질까 걱정되는 경우가 있다.

읽기 성능을 올리려고 복제본을 붙였는데, 어느 순간 화면에 보이는 값이 서로 달라져 혼란이 생기기도 한다.

로그 기반 복제와 마스터–슬레이브(Primary–Replica) 구조는 “어떻게 복제하고, 어디를 기준으로 진실을 정할지”를 정리하는 방식이다.

• 로그 기반 복제가 데이터를 옮기는 실제 과정
• 마스터–슬레이브에서 읽기/쓰기 역할이 나뉘는 이유
• 비동기·준동기·동기 복제 선택 기준
• 복제 지연과 장애 상황에서 흔히 벌어지는 실수
• 운영자가 따라 할 수 있는 확인·해결 절차

로그 기반 복제는 “변경 기록”을 전달해 같은 상태로 따라가게 만든다

개념 1: 로그 기반 복제는 “데이터 전체”가 아니라 “변경분”을 보낸다

정의: 로그 기반 복제는 테이블의 최종 결과를 통째로 복사하는 대신, 데이터가 바뀌는 순서대로 기록된 로그(WAL, binlog, redo/undo 계열)를 복제본에 전달해 같은 변경을 재생하는 방식이다.

핵심 특징: 변경이 발생할 때마다 로그가 쌓이고, 복제본은 그 로그를 순서대로 적용하면서 마스터의 상태를 따라간다. 대량 데이터에서도 “추가 변경분만” 흘려보내는 구조라 전송량과 적용 비용을 예측하기 쉽다.

• 내부 동작 원리: 마스터는 트랜잭션을 처리하면서 로그를 기록하고, 복제본은 로그 위치(오프셋/LSN 등)를 기준으로 “어디까지 반영했는지”를 추적한다.
• 범위: 같은 엔진/같은 호환성 규칙 아래에서 안정적으로 동작한다. 서로 다른 버전이나 설정 차이가 크면 로그 적용 단계에서 충돌이 날 수 있다.
• 수명: 로그는 영구 보관 대상이 아니라 “복제와 복구가 끝나면 정리될 수 있는 중간 산출물”이다. 다만 보관 기간이 너무 짧으면 지연이 생겼을 때 따라잡지 못한다.
• 정리 필요성: 로그 보관이 늘면 디스크가 빠르게 차며, 디스크 압박은 곧 쓰기 지연으로 이어질 수 있다. 보관 정책과 모니터링이 함께 필요하다.

주의점: 복제는 곧 백업을 대체하지 못한다. 잘못된 삭제나 잘못된 업데이트는 “로그로 정확히 전파”되어 복제본까지 동일하게 망가질 수 있다.

주의점: 복제 지연이 있는 구조에서는 “방금 쓴 데이터가 복제본에서 즉시 보인다”는 가정을 하면 화면에 어긋난 값이 나타날 수 있다.

 

로그 기반 복제에서 변경 로그가 복제본으로 전달되는 흐름

 

개념 2: 마스터–슬레이브 구조는 “쓰기 기준점”을 하나로 고정해 충돌을 줄인다

정의: 마스터–슬레이브 구조는 쓰기(INSERT/UPDATE/DELETE)를 담당하는 노드(마스터/Primary)를 하나로 두고, 슬레이브/Replica는 그 결과를 따라가며 주로 읽기(SELECT) 처리에 참여하는 구성이다.

핵심 특징: 쓰기 기준점이 한 곳이라서 “누가 최종 값을 정하는가”가 분명해진다. 읽기는 복제본으로 분산해 트래픽을 나눌 수 있다.

• 범위: 쓰기 트래픽은 기본적으로 마스터로 모인다. 읽기 확장은 가능하지만 쓰기 확장은 다른 설계(샤딩, 멀티-라이터 등)가 필요해진다.
• 내부 동작 원리: 애플리케이션은 쓰기 요청을 마스터로 라우팅하고, 읽기 요청은 용도에 따라 마스터 또는 복제본으로 보낸다. “방금 쓴 값”이 필요한 화면은 마스터로 읽기를 보내는 경우가 많다.
• 제약: 복제본은 마스터보다 뒤처질 수 있다. 뒤처짐(복제 지연)이 커지면 읽기 결과가 오래된 상태로 보인다.
• 정리 필요성: 장애 대비를 위해 복제본을 붙였더라도, 승격(Replica → Primary) 절차가 문서와 자동화로 정리되지 않으면 실제 장애에서 시간을 잃기 쉽다.

주의점: 슬레이브를 “장애 시 자동으로 마스터가 되는 예비 서버”라고만 생각하면 빈틈이 생긴다. 승격 조건, 데이터 손실 허용 범위, 애플리케이션 연결 전환 방식이 같이 정해져야 한다.

주의점: 읽기 분산을 하면서도 정합성을 요구하는 화면이 섞여 있으면, 어떤 요청이 마스터로 가야 하는지 기준이 없다면 오류처럼 보이는 현상이 반복된다.

안전과 성능을 동시에 잡으려면 “복제 방식”부터 선택해야 한다

복제는 하나의 기능이 아니라, 데이터 손실 가능성과 지연을 어떻게 교환할지 결정하는 선택지 묶음이다.

현장에서 가장 자주 부딪히는 선택은 비동기·준동기·동기 복제의 차이이며, 마스터–슬레이브 구조에서도 이 조합이 성격을 바꾼다.

방식	데이터 손실 가능성	지연(응답 속도) 영향	특징	적합한 상황
비동기 복제	장애 시 최신 변경 일부 유실 가능	낮음	마스터는 로그를 기록하고 바로 응답하며, 복제본은 뒤에서 따라간다	응답 속도를 우선하고, 소량 유실을 허용하거나 별도 보완책이 있는 경우
준동기 복제	유실 가능성 감소(구성에 따라 달라짐)	중간	마스터가 “복제본이 로그를 받았는지”를 어느 정도 확인한 뒤 응답한다	유실을 줄이되, 전체 동기 비용은 부담스러운 경우
동기 복제	유실 가능성 최소화(단, 장애 유형에 따라 예외가 있을 수 있음)	높음	복제본 반영을 확인하고 트랜잭션을 확정하는 구조가 많다	지연을 감수하고 정합성 요구가 강한 업무, 짧은 거리/안정적 네트워크가 전제되는 경우

표 제목: 마스터–슬레이브 환경에서의 복제 방식 핵심 비교

어떤 상황이면 무엇을 선택하는가: YES/NO 체크리스트

• 질문: 장애 시 “최근 몇 초의 변경”도 잃으면 안 되는가. YES: 동기 또는 준동기 방향을 검토한다. NO: 비동기도 후보가 된다.
• 질문: 사용자 체감 지연이 민감한 서비스인가. YES: 비동기 또는 준동기로 시작하고, 유실을 보완하는 별도 설계를 같이 둔다. NO: 동기를 포함한 강한 정합성 구성이 가능하다.
• 질문: 복제본에서 읽은 값이 약간 오래돼도 업무상 괜찮은가. YES: 읽기 분산을 적극적으로 적용할 수 있다. NO: 중요한 화면은 마스터 읽기로 고정하거나 지연 허용 기준을 좁혀야 한다.
• 질문: 복제본 승격(장애 전환)을 자동으로 할 계획이 있는가. YES: 승격 조건과 데이터 손실 허용 범위를 먼저 문서화한다. NO: 수동 전환 절차라도 반복 훈련 가능한 형태로 정리한다.
• 질문: 로그 보관이 늘어도 디스크 여유가 충분한가. YES: 지연 상황에서도 따라잡을 여지가 커진다. NO: 로그 보관 정책과 경보 임계치를 더 보수적으로 잡아야 한다.

실전 예시: 읽기 분산을 붙였는데 “방금 결제한 주문이 안 보이는” 상황

문제: 주문 결제를 완료한 직후 주문 내역 화면을 열었는데, 방금 만든 주문이 목록에 보이지 않는 현상이 간헐적으로 발생한다.

왜 발생: 쓰기는 마스터에 기록되었지만, 읽기 요청이 복제본으로 보내졌고 복제본이 아직 해당 로그를 적용하기 전이라서 결과가 늦게 반영되는 경우다. 트래픽이 늘거나 네트워크가 흔들리면 복제 지연이 커질 수 있다.

어떤 선택이 적합: “결제 직후 확인”처럼 최신성이 필요한 화면은 마스터 읽기로 고정하거나, 특정 시간 동안은 마스터를 우선 조회하는 정책을 둔다. 동시에 복제 지연을 모니터링해 임계치를 넘으면 자동으로 읽기 라우팅을 마스터로 되돌리는 방식도 선택지가 된다.

잘못 쓰면 어떤 문제: 모든 읽기를 마스터로 몰아버리면 복제본을 붙인 의미가 약해지고, 피크 타임에 마스터가 먼저 한계에 도달할 수 있다. 반대로 모든 읽기를 복제본으로 보내면 최신성이 필요한 화면에서 “데이터가 사라졌다”로 오해되는 문제가 반복된다.

확인/해결: 복제 지연이 실제로 얼마나 되는지 수치로 확인하고, 지연이 커지는 원인이 로그 적용 속도인지, 네트워크인지, 디스크 압박인지부터 분리해야 한다.

 

복제 지연과 장애 전환을 함께 점검하는 운영 플로우

 

따라할 수 있는 확인 방법: “지연 수치 → 오류 → 적용 속도” 순서로 점검한다

1. 모니터링 화면에서 마스터와 복제본의 복제 지연 지표를 확인한다(Cloud 콘솔의 Replication 탭, DB 대시보드의 Replica 상태 등).
2. 지연이 순간적으로 튄 시간과 사용자 불만이 발생한 시간을 맞춘다. 같은 시간대에 디스크 사용률 또는 네트워크 오류가 같이 증가했는지 본다.
3. DB 엔진이 제공하는 복제 상태 조회 기능으로 “복제본이 어디까지 적용했는지”를 확인한다(예: MySQL 계열은 Replica/Slave 상태 조회, PostgreSQL 계열은 복제 통계 뷰 확인).
4. 복제 오류가 기록되어 있는지 확인한다. 로그 적용 중단은 지연이 “계속 누적”되는 형태로 나타날 수 있다.
5. 복제본의 디스크 여유와 I/O 지연을 확인한다. 로그를 받아도 적용이 느리면 복제본이 병목일 수 있다.
6. 읽기 라우팅 정책을 점검한다. 최신성이 필요한 요청이 복제본으로 가는지, 또는 지연이 큰 상황에서 자동 전환 규칙이 있는지 확인한다.
7. 장애 전환을 계획하고 있다면 승격 절차를 문서로 확인한다. 승격 시점의 손실 허용 범위와 애플리케이션 연결 전환 방식(DNS, 프록시, 라우터)을 함께 점검한다.

복제가 “안전”으로 이어지려면 함께 갖춰야 하는 두 가지

첫째, 복제는 실수와 오작동을 되돌리지 못하므로 별도의 백업과 복구 전략이 필요하다. 특정 시점 복구가 가능한 형태로 백업을 설계해 두면 운영 실수의 피해 범위를 줄일 수 있다.

둘째, 승격과 복구는 기술보다 절차가 문제를 만든다. 누가 어떤 조건에서 어떤 버튼을 누르는지, 자동 전환이 실패했을 때 수동으로 어디를 확인하는지까지 문서화되어야 장애에서 시간이 줄어든다.

결론

로그 기반 복제는 변경 기록을 전달해 복제본이 같은 상태로 따라가게 만드는 방식이다.

마스터–슬레이브 구조는 쓰기 기준점을 하나로 고정해 충돌과 혼선을 줄이는 구성이다.

비동기·준동기·동기 선택은 손실 가능성과 지연을 어떻게 교환할지 결정하는 문제다.

• 다음에 읽으면 좋은 연계 주제: 백업과 복제의 역할 분리, 특정 시점 복구 전략
• 다음에 읽으면 좋은 연계 주제: 샤딩과 읽기 분산의 차이, 확장 설계의 단계

FAQ

복제본이 있으면 백업을 안 해도 되는가

그렇지 않다. 잘못된 삭제나 잘못된 업데이트는 복제본에도 그대로 전파될 수 있다. 복제는 가용성을 돕고, 백업은 되돌리기를 돕는 역할로 분리되는 경우가 많다.

마스터–슬레이브에서 읽기를 복제본으로 보내면 무조건 문제가 생기는가

무조건은 아니다. 다만 복제 지연이 존재할 수 있으므로 최신성이 필요한 화면은 마스터를 읽도록 분리하는 기준이 필요하다. 지연이 커질 때 읽기 라우팅을 조정하는 운영 규칙도 함께 쓰인다.

복제 지연은 어떤 때 급격히 커지는가

복제본의 디스크 I/O가 느릴 때, 네트워크가 흔들릴 때, 대량 쓰기 트래픽이 몰릴 때, 또는 복제 오류로 적용이 멈췄을 때 지연이 빠르게 커질 수 있다. 지연 수치와 오류 로그를 함께 확인하는 순서가 흔히 쓰인다.