1. MySQL에서의 클러스터 환경
- MySQL에서 클러스터 환경은 데이터 가용성(HA)와 확장성을 위해 구성
- 일반적으로 MySQL 클러스터는 리더(마스터)와 레플리카(슬레이브)로 나뉘며, 다음 두 가지 주요 유형으로 구분
1.1 리더-레플리카 구조 (Master-Slave 또는 Primary-Replica 구조)
- 리더(Primary)
- 데이터 변경(INSERT, UPDATE, DELETE)이 발생하는 노드.
- 애플리케이션이 주로 읽기와 쓰기를 요청하는 데이터베이스.
- 레플리카(Replica)
- 리더의 데이터를 복제하여 동기화.
- 주로 읽기 요청(READ)을 처리하거나, 리더 장애 시 장애 복구(HA)를 위해 사용.
- 레플리카는 데이터 변경 작업을 직접 처리하지 않고 리더의 변경 사항을 반영.
구조 예시
Writes/Updates
(INSERT/UPDATE)
│
Primary
(리더)
│
┌──────────┴──────────┐
│ │
Replica 1 (읽기 전용) Replica 2 (읽기 전용)
• 애플리케이션은 쓰기 요청은 리더에, 읽기 요청은 레플리카로 분산.
• 장애 발생 시 레플리카가 리더 역할로 승격(Failover) 가능.1.2 고가용성 클러스터 구조 (Group Replication 또는 Galera Cluster)
-
MySQL Group Replication과 Galera Cluster는 모든 노드가 동등한 역할(리더-레플리카가 없음)을 수행
- 리더 노드를 특별히 지정하지 않아도 모든 노드가 쓰기와 읽기를 처리
- 데이터를 트랜잭션 단위로 동기화하여 데이터 일관성을 보장.
-
장애 복구와 데이터 일관성이 높은 수준으로 유지
구조 예시
Reads/Writes
┌──────────┬──────────┐
│ │ │
Node 1 Node 2 Node 3
• 장점: 단일 장애점(Single Point of Failure)이 없어 안정적.
• 단점: 노드 간 동기화로 인해 쓰기 성능이 낮아질 수 있음. 2. GTID의 구성
- GTID(Global Transaction Identifier)는 MySQL에서 복제(Replication) 환경을 관리하고, 데이터의 일관성을 보장하기 위해 각 트랜잭션에 부여하는 고유 식별자
- GTID는 마스터와 슬레이브(리더와 레플리카) 간 데이터 복제를 간소화하고 신뢰성을 높이는 데 사용됩니다.
구성
<server_uuid>:<transaction_id>
• server_uuid: 트랜잭션이 실행된 MySQL 서버를 고유하게 식별하는 값(UUID 형식).
• transaction_id: 해당 서버에서 실행된 트랜잭션의 순번.예시
3E11FA47-71CA-11E1-9E33-C80AA9429562:12345
• 3E11FA47-71CA-11E1-9E33-C80AA9429562: 트랜잭션이 실행된 서버의 UUID.
• 12345: 이 서버에서 실행된 12345번째 트랜잭션3. GTID의 동작 원리
3.1 GTID 생성
- 트랜잭션이 실행될 때, MySQL 서버는 고유한 GTID를 생성
- 마스터 서버에서 데이터 변경(INSERT/UPDATE/DELETE)을 수행하면 GTID가 생성
3.2 복제 환경에서 GTID 전파
- 마스터에서 생성된 GTID와 트랜잭션 정보는 Binary Log(Binlog)를 통해 슬레이브 서버로 복제
- 슬레이브 서버는 전송받은 GTID를 읽고, 이미 실행된 GTID는 무시하며, 새로 실행된 GTID만 적용
GTID와 Binlog의 관계
- GTID(Global Transaction Identifier)는 각 트랜잭션에 고유하게 할당된 식별자
- MySQL은 트랜잭션이 발생할 때, Binlog에 GTID와 트랜잭션 내용을 함께 기록
- 슬레이브 서버는 Binlog에서 GTID와 트랜잭션 내용을 읽고 이를 재실행하여 데이터를 복제
4. GTID 복제의 장점
4.1 트랜잭션 추적
- GTID는 각 트랜잭션을 고유하게 식별하므로, 어떤 트랜잭션이 어디에서 실행되었는지 쉽게 추적
4.2 자동화된 복제 관리
- GTID 기반 복제는 슬레이브가 복제 상태를 자동으로 조정할 수 있어, Binlog 파일과 오프셋을 수동으로 설정할 필요가 없다.
- 예: 슬레이브 서버가 누락된 트랜잭션만 복제하도록 자동으로 관리.
4.3 장애 복구 간소화
- 마스터 서버에 장애가 발생해도, 슬레이브 서버는 GTID를 기반으로 상태를 이어받아 새로운 마스터로 승격할 수 있다.
4.4 데이터 일관성 보장
- GTID를 통해 각 트랜잭션의 실행 순서가 보장되므로, 데이터 일관성을 유지할 수 있다.
5. GTID 복제 설정
5.1 MySQL 설정 파일(my.cnf)에서 GTID 활성화
[mysqld]
gtid_mode = ON # GTID 활성화
enforce-gtid-consistency = ON # 트랜잭션 일관성 보장
log_slave_updates = ON # 슬레이브도 Binlog를 기록- gtid_mode: GTID를 활성화.
- enforce-gtid-consistency: GTID 일관성을 보장(DDL과 트랜잭션에 제약 추가).
- log_slave_updates: 슬레이브가 실행한 트랜잭션도 Binlog에 기록.
MySQL 서버를 재시작한 후, 슬레이브와 마스터 간 복제를 설정
5.2 슬레이브에서 GTID 복제 시작
- 마스터 서버 정보를 슬레이브에 설정
CHANGE MASTER TO
MASTER_HOST='master-host',
MASTER_USER='replication-user',
MASTER_PASSWORD='replication-password',
MASTER_AUTO_POSITION=1; -- GTID 기반 복제 활성화- 슬레이브 복제 시작
START SLAVE;6. GTID 복제의 작동 예시
6.1. 마스터에서 트랜잭션 실행
- 마스터에서 트랜잭션을 실행하면 GTID가 할당
INSERT INTO users (id, name) VALUES (1, 'Alice');- 이 트랜잭션은 GTID로 식별
3E11FA47-71CA-11E1-9E33-C80AA9429562:16.2. 슬레이브로 복제
- 슬레이브는 마스터의 Binlog를 읽어, 해당 GTID의 트랜잭션을 실행
- 이미 실행된 GTID는 무시하고, 누락된 트랜잭션만 복제
Data Engineer