상황

읽기 부하 분산과 가용성을 위해 master slave 구조를 도입하고자 함

고려 사항

복제 방법으로 binlog, GTID, Semi-Synchronous Replication 3가지 방법 고려

binlog 복제는 장애 복구가 어렵고 Slave 추가 시 설정이 복잡함

GTID복제는 장애 시 자동 복구가 가능하고 Slave 서버 추가도 간편함

Semi-Synchronous 복제는 강한 일관성을 제공하지만 msa환경 확장시 slave 추가가 제한될 가능성 있음

의사 결정

• Docker Compose를 이용해 Master와 Slave 서버를 물리적으로 분리하여 구성
• 복제 방식은 GTID(Global Transaction ID) 복제를 선택:
  • 장애 발생 시 복제 복구가 자동으로 가능 (slave 필요한 binlog 파일이 master 에 살아 있을 시)
  • Slave 서버를 추가하거나 교체할 때 설정이 단순하고 안정적
  • MSA 특성상 강한 일관성보다는 가용성과 확장성을 우선 고려

구현 방식

1. master 서버 gtid 방식 설정

Services  
  db:  # Master
    image: mysql:8
    container_name: mysql-db
    environment:
      MYSQL_ROOT_PASSWORD: manager
      MYSQL_DATABASE: settlementdb
    ports:
      - "3306:3306"
    command: >
      --server-id=1   # 이 서버(MySQL 인스턴스)의 고유 ID (Master/Slave 구분용, 중복 금지)
      --log-bin=mysql-bin # 바이너리 로그 활성화 (복제나 장애 복구를 위해 트랜잭션 기록)
      --binlog-do-db=settlementdb # 바이너리 로그에 기록할 특정 데이터베이스 지정 (settlementdb만 복제 대상)
      --binlog-format=ROW # binlog 기록 방식 설정 (ROW: 데이터 변경 자체를 기록, 복제 정확도 높음)
      --gtid-mode=ON   # GTID(Global Transaction ID) 기능 활성화 (트랜잭션에 고유 ID 부여해서 복제 관리)
      --enforce-gtid-consistency=ON   # GTID 복제 일관성 강제 (트랜잭션이 GTID 복제에 적합한 방식으로만 실행되게 함)
    volumes:
      - master_data:/var/lib/mysql
      
   
volumes:
  master_data:  # Named Volume 선언
  slave_data:   # Named Volume 선언

1. Master 서버에 복제용 사용자 생성

(Slave가 Master binlog를 읽을 수 있게 허용)