MariaDB - Replication 설정 (Master-Master / Master-Slave)

Replication이란?

Replication은 데이터베이스 서버의 데이터를 다른 데이터베이스 서버로 복제하는 과정을 말합니다. 

 

Replication을 왜 사용하는가?

1. 고가용성(High Availability): 한 서버에 장애가 발생해도 다른 서버에서 운영할 수 있어 서비스 중단을 방지합니다.
2. 백업(Backup): 실시간으로 데이터를 복제하여 데이터 손실을 최소화합니다.
3. 성능 향상(Performance Improvement): 읽기 작업을 여러 서버로 분산하여 성능을 최적화합니다.

---

Master-Master Replication과 Master-Slave Replication

1. Master-Master Replication

두 개 이상의 마스터 서버가 서로 데이터를 복제합니다.

 

장점

• 고가용성: 한 마스터 서버가 다운되더라도 다른 마스터 서버가 운영을 지속할 수 있습니다.
• 로드 밸런싱: 여러 마스터 서버에 읽기 및 쓰기 작업을 분산하여 성능을 향상시킬 수 있습니다.

단점

• 데이터 충돌 가능성: 동시에 여러 마스터 서버에서 쓰기 작업이 가능하므로, 데이터 충돌이 발생할 수 있습니다.
• 구성 및 관리의 복잡성: 설정 및 운영이 복잡하며, 데이터 일관성을 유지하기 위한 추가적인 관리가 필요합니다.
• 성능 저하: 데이터 충돌을 피하기 위한 잠금 메커니즘 등이 성능 저하를 일으킬 수 있습니다.

사용 예시

• 고가용성과 성능 향상이 중요한 대규모 시스템
• 여러 지역에 분산된 서버를 통해 데이터를 동기화해야 하는 경우

 

2. Master-Slave Replication

하나의 마스터 서버가 데이터를 쓰고, 슬레이브 서버가 마스터 서버의 데이터를 복제하여 읽기 작업을 수행합니다.

 

장점

• 구성의 단순성: 설정 및 관리가 비교적 단순합니다.
• 읽기 성능 향상: 여러 슬레이브 서버에서 읽기 작업을 분산하여 성능을 향상시킬 수 있습니다.
• 데이터 백업: 슬레이브 서버를 사용하여 데이터를 백업하거나 데이터 분석 용도로 사용할 수 있습니다.

단점

• 단일 실패 지점: 마스터 서버가 다운되면 모든 쓰기 작업이 중단됩니다.
• 쓰기 작업의 제한: 마스터 서버만 쓰기 작업을 하기 때문에 쓰기 작업이 많은 경우 성능이 제한될 수 있습니다.
• 데이터 일관성 문제: 데이터 동기화 지연이 발생할 수 있어 데이터 일관성 문제가 생길 수 있습니다.

사용 예시

• 읽기 작업이 많고 쓰기 작업이 상대적으로 적은 시스템
• 데이터 백업 및 분석이 필요한 경우

 

---

Master-Master Replication 설정 방법

1. MariaDB 설치 및 설정

각 서버의 my.cnf 파일의 아래 내용을 수정 및 추가합니다.

## A Master Server

[mysqld]
server_id=1  # 첫 번째 마스터는 1, 두 번째 마스터는 2로 설정
log_bin=mysql-bin
binlog_format=row
auto_increment_increment=2
auto_increment_offset=1  # 첫 번째 마스터는 1, 두 번째 마스터는 2로 설정

 

## B Master Server

[mysqld]
server_id=2
log_bin=mysql-bin
binlog_format=row
auto_increment_increment=2
auto_increment_offset=2

server_id, log_bin, binlog_format 등을 설정합니다. 각 서버의 ID는 고유해야 합니다.

 

 

2. 복제 사용자 생성 및 권한 부여

A, B 서버에 Replication을 위한 사용자 계정 생성 및 권한을 설정합니다.

## A Master B Master 모두 실행 필요

CREATE USER 'repl'@'%' IDENTIFIED BY 'repl';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

 

3. 데이터 덤프 및 복원

초기 복제를 위해 A 서버에서 데이터 덤프를 생성합니다.

# mysqldump -u root -p --all-databases --master-data > dump.sql

B 서버에 가져와서 덤프파일을 복원합니다.

# mysql -u root -p < dump.sql

 

4. Replication 설정

각 서버에서 다른 서버를 슬레이브로 설정합니다. (서로가 서로의 Master 이면서 Slave)

A서버에서 B서버로 슬레이브 설정 (B Master - A Slave)

CHANGE MASTER TO
    MASTER_HOST='B_Master_IP',
    MASTER_USER='repl',
    MASTER_PASSWORD='repl',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=4;
START SLAVE;

B서버에서 A서버로 슬레이브 설정 (A Master - B Slave)

CHANGE MASTER TO
    MASTER_HOST='A_Master_IP',
    MASTER_USER='repl',
    MASTER_PASSWORD='repl',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=4;
START SLAVE;

 

5. 상태 확인

SHOW SLAVE STATUS\G;

Slave_IO_Running 및 Slave_SQL_Running이 Yes로 표시되는지 확인합니다.

 

---

 

반응형

 

실제 구성 사례

Replication의 장/단점을 보완하여 고가용성, 데이터충돌을 줄이고 성능저하도 줄이는 방안으로 사용 중

1. L4 VIP 설정

• L4 로드 밸런서 구성:
  • VIP: db-vip.samso.com (L4 VIP)
  • 기본 서버: A Master (a-master.samso.com)
  • 백업 서버: B Master (b-master.samso.com)
  • 읽기 서버 : C D Slave (c-slave.samso.com / d-slave.samso.com)
  • 헬스 체크: A Master가 응답하지 않을 경우 B Master로 자동 전환

2. DB 서버 설정

## C Slave와 D Slave에서 실행
CHANGE MASTER TO
    MASTER_HOST='db-vip.samso.com',
    MASTER_USER='repl',
    MASTER_PASSWORD='repl',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=4;
START SLAVE;

장점

1. 마스터 전환 자동화
   • L4 로드 밸런서가 A Master의 상태를 모니터링하여 장애 발생 시 자동으로 B Master로 전환합니다.
   • 슬레이브 서버는 항상 VIP를 바라보므로 별도의 재설정이 필요 없습니다.
2. 고가용성 및 신뢰성
   • B Master 서버로 전환 시 서비스 중단 없이 지속적으로 운영할 수 있습니다.
   • 슬레이브 서버는 자동으로 새로운 마스터를 바라보게 됩니다.

단점 및 고려 사항

1. L4 로드 밸런서의 신뢰성
   • L4 로드 밸런서의 신뢰성이 매우 중요해 헬스 체크 설정이 정확하고 신뢰성 있게 구성되어야 합니다.
2. 복제 지연
   • 슬레이브 서버의 복제 지연 시간이 길어지지 않도록 모니터링이 필요합니다.
   • 특히 마스터 전환 시 슬레이브가 최신 데이터를 반영하고 있는지 확인해야 합니다.
3. 마스터 간 데이터 동기화:
   • A Master와 B Master 간의 데이터 동기화가 제대로 이루어져야 합니다.