[MySQL] MySQL 아키텍처 : Replication(복제)

Replication

MySQL의 복제는 Replication이라고 합니다.

2대 이상의 MySQL 서버가 동일한 데이터를 담도록 실시간으로 동기화하는 기술입니다.

 

마스터(Master)

• DML(INSERT, UPDATE, DELETE), DDL(CREATE, DROP 등)을 통해 데이터를 변경할 수 있는 서버

슬레이브(Slave)

• SELECT 쿼리로 데이터를 읽기만 할 수 있는 서버

하나의 서버는 마스터 또는 슬레이브 가운데 하나의 역할만 수행하는 것이 일반적이지만 때로는 서버 하나가 마스터이면서 슬레이브 역할까지 수행하도록 설정하는 것도 가능합니다. 이 경우 MySQL 서버가 모두 마스터이면서 동시에 슬레이브가 되는 형태로 구성됩니다.

 

바이너리 로그 및 릴레이 로그

• 바이너리 로그(Binary Log)
  • 마스터 서버에서 실행되는 DML과 DDL 가운데 데이터의 구조나 내용을 변경하는 모든 "쿼리 문장( Statement 포맷 방식 )" 또는 "변경된 레코드 값( Row 포맷 방식 )"은 바이너리 로그에 기록됩니다.
  • 슬레이브 서버에서 변경 내역을 요청하면 마스터 장비의 프로세스 가운데 Binlog dump 스레드가 그 바이너리 로그를 읽어 슬레이브로 넘깁니다. 
  • 만약 하나의 마스터 서버에 10개의 슬레이브가 연결돼 있다면 Binlog dump 스레드는 10개가 표시될 것입니다.
  • 기술적으로 바이너리 로그가 활성화되면 어떤 MySQL 서버든 마스터가 될 수 있습니다.

• 릴레이 로그(Relay Log)
  • 마스터 서버가 바이너리 로그를 가지고 있다면 슬레이브 서버는 릴레이 로그를 가지고 있습니다.
  • 슬레이브 서버의 I/O 스레드는 마스터 서버에 접속해 변경 내역을 요청하고, 받아온 변경 내역을 릴레이 로그에 기록합니다.
  • 그리고 슬레이브 서버의 SQL 스레드가 릴레이 로그에 기록된 변경 내역을 재실행함으로써 슬레이브의 데이터를 마스터와 동일한 상태로 유지합니다.
  • I/O 스레드와 SQL 스레드는 마스터 서버에서는 기동되지 않습니다.

 

바이너리 로그 기록 방식

• Statement 포맷 방식 : 쿼리 문장 기록
  • 장점 :
    1) 네트워크 트래픽을 많이 유발하지 않음
    (아무리 데이터의 변경을 많이 유발하는 쿼리라 하더라도 SQL 문장 하나만 슬레이브로 전달)
  • 단점 :
    1) REPEATABLE-READ 이상의 트랜잭션 격리 수준 사용 필요
    2) Lock 경합 증가 (InnoDB 테이블에서는 레코드 간의 간격을 잠그는 Gap Lock이나 Next Key Lock이 필요)
• Row 포맷 방식 : 변경된 레코드 값 기록
  • 장점 :
    1) READ-COMMITTED 트랜잭션 격리 수준에서도 작동
    2) InnoDB 테이블에서의 Lock 경합은 감소
  • 단점 :
    1) 마스터와 슬레이브 간의 네트워크 트래픽을 많이 발생시킬 수 있음

 

Replication 사용 시 주의 사항

• 슬레이브는 하나의 마스터만 설정 가능
• 마스터와 슬레이브의 데이터 동기화를 위해 슬레이브는 읽기 전용(Read-Only)으로 설정
  • 슬레이브를 읽기 전용으로 설정하지 않은 상황에서 슬레이브에서 변경이 일어나면 데이터 동기화가 꼬이게 됩니다.
  • 이러한 실수를 사전에 방지하기 위해 슬레이브는 읽기 전용으로 설정하면 좋습니다.
• 슬레이브 서버용 장비는 마스터와 동일한 사양이 적합
  • 마스터 서버에서 수많은 동시 사용자가 실행한 데이터 변경 쿼리 문장이 슬레이브에서는 하나의 스레드(SQL 스레드)로 모두 처리되어야 합니다.
  • 따라서, 변경이 매우 잦은 서버일수록 마스터 서버의 사양보다 슬레이브 서버의 사양이 더 좋아야 마스터에서 동시에 여러 개의 스레드로 실행된 쿼리가 슬레이브에서 지연되지 않고 하나의 스레드로 처리될 수 있습니다.
  • 일반적으로 데이터 변경은 조회에 비해 1/10 이하 수준으로 유지되기 때문에 보통 마스터와 슬레이브를 같은 사양으로 유지할 때가 많습니다.
  • 뿐만 아니라 슬레이브는 마스터가 다운될 경우 복구 대안으로 사용될 때도 많기 때문에 서버 사양을 동일하게 맞추는 경우가 대부분입니다.
• 복제가 불필요한 경우는 바이너리 로그 중지
  • 바이너리 로그를 작성하기 위해 MySQL은 많은 리소스를 소모합니다.
    (바이너리 로그를 안정적으로 기록하기 위해 Gap Lock을 유지하고, 매번 트랜잭션이 커밋될 때마다 데이터를 변경시킨 쿼리 문장을 바이너리 로그에 기록해야 합니다-어떤 경우 바이너리 로그에 정확히 기록되고 나서야 사용자가 요청한 쿼리 문장이 완료될 때도 있습니다) AutoCommit이 활성화되어 있다면 더 심각한 부하로 나타날 때가 많습니다. MyISAM 테이블은 항상 AutoCommit 모드로 동작하기 때문에 InnoDB 테이블보다 바이너리 로그를 기록하는 데 더 많은 리소스를 사용하게 됩니다.

 

---

참고 도서 및 사이트

• 도서 : Real MySQL 8.0