[MySQL] Replication과 InnoDB Cluster, Sharding은 무엇이 다를까?

1. 문서 제목

• MySQL Replication과 InnoDB Cluster, Sharding은 무엇이 다를까?

---

2. 기술 개요 요약

DB 확장과 고가용성을 이야기할 때 Clustering, Replication, Sharding이 자주 함께 등장한다. 세 개념은 모두 DB를 여러 대로 구성한다는 공통점이 있지만 목적과 데이터 배치 방식이 다르다. Clustering은 주로 장애 전환과 가용성을 위해 여러 노드를 하나의 서비스처럼 묶는 개념이고, Replication은 동일한 데이터를 여러 서버에 복제해 읽기 분산과 장애 대응을 돕는다. Sharding은 데이터를 여러 조각으로 나누어 서로 다른 서버에 저장함으로써 쓰기 부하와 저장 용량을 분산한다.

핵심 구분 기준은 “데이터를 몇 벌 갖고 있는가”와 “각 서버가 같은 데이터를 갖는가, 다른 데이터를 갖는가”다.

---

3. 핵심 기능/개념 정리

3-1. 세 개념 비교

구분	데이터 배치	주요 목적	장점	단점
Clustering	구현 방식에 따라 공유 스토리지 또는 복제 기반	고가용성, failover	장애 시 서비스 지속성 향상	구성 복잡도, 네트워크/합의 비용
Replication	서버마다 같은 데이터 복사본 보유	읽기 분산, 백업, 장애 대응	read replica로 조회 부하 분산	replication lag, 쓰기 확장 한계
Sharding	서버마다 다른 데이터 조각 보유	쓰기/읽기 부하와 저장 용량 분산	수평 확장 가능	크로스 샤드 조인/트랜잭션 복잡

3-2. Clustering

항목	설명	실무 포인트
Clustering	여러 DB 인스턴스를 하나의 고가용성 구성으로 묶는 방식	제품마다 구현 방식이 다름
Active-Standby	하나가 active로 서비스하고 standby가 대기	장애 전환에 초점
Shared Storage	여러 인스턴스가 같은 스토리지를 공유	복제 지연은 없지만 공유 스토리지 의존
MySQL InnoDB Cluster	MySQL Group Replication, MySQL Router, MySQL Shell AdminAPI 조합	MySQL의 대표 HA 구성
Group Replication	여러 MySQL 인스턴스 간 복제와 합의를 통해 그룹 구성	네트워크 지연과 quorum 고려 필요

주의할 점:

• “클러스터링 = 항상 공유 스토리지”는 아니다.
• Oracle RAC처럼 공유 스토리지 기반인 제품도 있고, MySQL InnoDB Cluster처럼 Group Replication 기반인 구성도 있다.
• 따라서 면접에서는 특정 제품이 아니라 “가용성과 장애 전환을 위한 다중 노드 구성”으로 설명하는 것이 안전하다.

3-3. Replication

항목	설명	실무 포인트
Source	쓰기 기준이 되는 원본 서버	예전 문서에서는 Master라고 부름
Replica	Source 변경 사항을 복제받는 서버	예전 문서에서는 Slave라고 부름
Binary Log	Source의 변경 이벤트 기록	MySQL replication의 기반
Relay Log	Replica가 Source에서 받은 이벤트를 저장하는 로그	Replica가 이를 적용해 데이터 동기화
Replication Lag	Source 변경이 Replica에 반영되기까지의 지연	읽기 정합성 이슈 발생 가능

MySQL replication은 binary log를 기반으로 Source의 변경 사항을 Replica로 전달한다. Replica는 받은 이벤트를 relay log에 저장하고 이를 적용한다.

3-4. Sharding

항목	설명	실무 포인트
Sharding	데이터를 특정 기준으로 여러 DB 서버에 나누어 저장	쓰기 확장과 저장 용량 확장에 유리
Shard Key	데이터를 어느 샤드에 넣을지 결정하는 키	조회 패턴과 트랜잭션 경계 기준으로 선택
Cross-Shard Join	여러 샤드에 걸친 조인	애플리케이션 조인, 비정규화, CQRS 등 필요
Distributed Transaction	여러 샤드에 걸친 트랜잭션	2PC, Saga 등 별도 전략 필요

샤딩은 확장성은 좋지만 애플리케이션과 운영 복잡도를 크게 높인다. 자세한 분산 트랜잭션 문제는 [[Career/면접질문/2026-07-09_샤딩_분산트랜잭션_Saga_학습노트|샤딩·분산트랜잭션·Saga 학습노트]]를 참고한다.

---

4. 사용 예시 및 코드 스니펫

4-1. MySQL Replication 상태 확인

MySQL 8.0.22 이후에는 SHOW SLAVE STATUS가 deprecated 되었고 SHOW REPLICA STATUS가 권장된다.

SHOW REPLICA STATUS\G

구버전 또는 기존 자료에서는 다음 명령을 볼 수 있다.

SHOW SLAVE STATUS\G

주요 확인 항목:

항목	의미
Replica_IO_Running 또는 Slave_IO_Running	Source에서 로그를 가져오는 스레드 상태
Replica_SQL_Running 또는 Slave_SQL_Running	받은 로그를 적용하는 스레드 상태
Seconds_Behind_Source 또는 Seconds_Behind_Master	복제 지연 시간
Source_Log_File, Read_Source_Log_Pos	Source 로그 읽기 위치
Relay_Log_File, Relay_Log_Pos	Replica relay log 위치

4-2. Replication 구성 흐름 예시

1. Source에서 변경 트랜잭션 commit
2. Source binary log에 변경 이벤트 기록
3. Replica I/O thread가 Source binary log를 읽음
4. Replica relay log에 저장
5. Replica SQL thread가 relay log를 적용

4-3. Sharding 라우팅 예시

function getShardId(userId: number, shardCount: number): number {
  return userId % shardCount;
}

이 예시는 단순 modulo 방식이다. 실제 운영에서는 샤드 수 변경, hot shard, resharding 비용을 고려해 더 정교한 라우팅 전략을 검토할 수 있다.

4-4. 조합 예시

실무에서는 세 전략이 배타적이지 않다.

서비스 전체 데이터
  -> user_id 기준으로 4개 shard로 분산
  -> 각 shard마다 Source/Replica 구성
  -> 각 Source는 HA를 위해 cluster 구성

이 구조에서는:

• Sharding으로 쓰기/용량을 분산한다.
• Replication으로 읽기 부하를 분산한다.
• Clustering/HA 구성으로 장애 전환을 준비한다.

---

5. 실제 사용 시 주의점 / Best Practice

5-1. Replication은 쓰기 확장의 해답이 아니다

일반적인 Source-Replica 구조에서는 쓰기는 Source로 집중된다. Replica는 주로 읽기 분산, 백업, 분석용 조회, 장애 대응에 유리하다. 쓰기 부하 자체를 분산하려면 샤딩이나 multi-primary 계열 구성을 별도로 검토해야 한다.

다만 multi-primary 복제나 Group Replication 같은 구성은 별도의 충돌 처리, 합의, 운영 제약을 동반한다. 따라서 "replication은 읽기 분산 중심"이라는 설명은 일반적인 source-replica 구조를 전제로 한 요약이라고 말하는 것이 정확하다.

5-2. Replica 읽기는 최신 데이터가 아닐 수 있다

비동기 복제에서는 replication lag가 발생할 수 있다. 결제 직후 주문 상태 확인처럼 최신 데이터가 중요한 조회는 Source로 읽거나 read-your-writes 전략을 고려해야 한다.

5-3. Clustering은 제품별 의미가 다르다

Oracle RAC, MySQL InnoDB Cluster, PostgreSQL HA 구성은 내부 구조가 다르다. “클러스터링”이라는 단어만으로 공유 스토리지인지, 복제 기반인지, 합의 프로토콜 기반인지 단정하지 않는다.

5-4. Sharding은 마지막에 가까운 선택지다

샤딩은 수평 확장에 강하지만 조인, 트랜잭션, 운영, 장애 대응 복잡도를 크게 높인다. 먼저 인덱스 튜닝, 쿼리 개선, 캐싱, 파티셔닝, replication으로 해결 가능한지 검토하는 것이 좋다.

5-5. 세 전략은 계층적으로 함께 쓰인다

대규모 시스템에서는 “샤드마다 replication을 두고, 각 primary를 HA cluster로 보호”하는 식으로 조합한다. 중요한 것은 각 전략의 목적을 섞어 말하지 않는 것이다.

5-6. 면접 답변으로 압축하기

Clustering, Replication, Sharding은 모두 DB를 여러 대로 구성하지만 목적이 다릅니다. Clustering은 주로 고가용성과 failover를 위한 다중 노드 구성이고, Replication은 같은 데이터를 여러 서버에 복제해 읽기 분산과 장애 대응에 사용합니다. 반면 Sharding은 데이터를 여러 조각으로 나누어 서로 다른 서버에 저장해 쓰기 부하와 저장 용량을 수평 확장합니다. Replication은 복제 지연 때문에 Replica에서 오래된 데이터를 읽을 수 있고, Sharding은 크로스 샤드 조인과 분산 트랜잭션이 복잡해진다는 트레이드오프가 있습니다.

---

검증 메모

• MySQL InnoDB Cluster, Group Replication, Source/Replica 용어를 공식 문서 기준으로 확인했다.
• "Clustering = 공유 스토리지"로 단정하지 않도록 제품별 의미 차이를 유지했다.
• replication의 쓰기 확장 한계는 일반적인 Source-Replica 구성을 전제로 한다고 보완했다.

6. 참고자료 / 공식 문서 출처

• MySQL Reference Manual: InnoDB Cluster
  https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-introduction.html
• MySQL Reference Manual: Group Replication
  https://dev.mysql.com/doc/en/group-replication.html
• MySQL Reference Manual: InnoDB Cluster with MySQL Shell
  https://dev.mysql.com/doc/mysql-shell/en/mysql-innodb-cluster.html
• MySQL Reference Manual: InnoDB and MySQL Replication
  https://dev.mysql.com/doc/refman/8.2/en/innodb-and-mysql-replication.html
• MySQL Reference Manual: SHOW REPLICA STATUS Statement
  https://dev.mysql.com/doc/refman/8.1/en/show-replica-status.html
• MySQL Reference Manual: SHOW SLAVE | REPLICA STATUS Statement
  https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html