4. 크래시 세이프 슬레이브

• 복제 구성에서는 IO 스레드와 SQL 스레드가 필요

IO 스레드

• 마스터로부터 바이너리 로그 이벤트를 네트워크를 통해 가져온 후 슬레이브의 로컬 디스크에 파일로 저장
• master.info 파일에 저장

SQL 스레드

• IO 스레드가 기록한 이벤트를 슬레이브에서 재 수행
• relay-log.info 파일에 저장

• 바이너리 로그 이벤트가 복제 될 때마다 디스크에 IO 를 발생하므로 부하가 크다
• 일반적으로 부하를 줄이기 위해 비 동기 방식으로 처리한다
• 이 경우 서버 비 정상 종료 후 재 시작 시 이미 수행 된 정보가 다시 수행되어 중복 키 에러가 발생 가능하다

크래시 세이프 복제

• 이러한 문제점을 막기 위해 디스크가 아닌 테이블에 저장하도록 개선
• 복제 위치 정보 테이블에 대한 기록과 실제 테이블 변경을 하나의 트렌젝션으로 묶어 처리 하므로 원자성(Atomicity) 보장 가능
• 트렌젝션 처리가 지원 되는 innoDB 나 XtraDB 스토리지 엔진 필요

Maria DB 의 크래시 세이프 복제

• 글로벌 트렌젝션 ID 사용 시 gtid_slave_pos 에 수행한 복제 위치 정보가 자동 저장
• GTID 를 사용하지 않을 경우 크래시 세이프 복제는 구현 불가능

MySQL DB 의 크래시 세이프 복제

• 글로벌 트렌젝션과 무관하게 시스템 변수로 구현 가능

STATEMENT 타입을 사용한 용량 최적화

• 전통적인 방법 - SQL 문장을 저장하는 방법인 듯
• UUID 함수와 같이 비 결정적(NOT DETERMINISTIC) 함수나 기능들에 대해서는 복제 불가능
  
  

ROW 타입

• 최종적으로 테이블에 저장 된 값을 저장하므로 제약이 없음
• STATEMEMTN 타입보다 많은 저장공간 필요
  
  

MIXED TYPE

• STATEMENT 타입과 ROW 타입의 장점을 결합

시스템 변수를 사용한 용량 최적화

MySQL 5.6 에서의 시스템 변수 binog_row_image

• FULL
  • ROW 포맷과 같이 변경 레코드의 모든 컬럼을 기록
  • INSERT 의 경우 변경 후 모든 컬럼
  • UPDATE 의 경우 전/후 컬럼
  • DELETE 의 경우 변경 전 모든 컬럼 기록

• MINIMAL
  • 변경 될 내용을 슬레이브에 적용 시 꼭 필요한 컬럼만 기록
  • PKE(Primary Key Equivalent) - PK 처럼 취급할 수 있는 값
  • 테이블에 PK 가 있을 경우는 PK 를 PKE 로 사용
  • 테이블에 PK 가 없을 경우는 Not Null UK 사용, UK 도 없을 경우는 모든 컬럼 조합을 PKE 로 사용
  • INSERT 의 경우 변경 후 모든 컬럼(AutoIncrement 사용 시 값 포함)
  • UPDATE 의 경우 변경 전은 PKE, 변경 후는 값이 명시 된 모든 컬럼
  • DELETE 의 경우 변경 전 PKE

• NOBLOB
  • 기록하지 않음

2) ROW 포맷 바이너리 로그의 정보성 로그 이벤트

• 많은 사용자들이 STATEMEMT 방식을 사용하는 이유는 사용자가 수행 한 SQL 이 어떤건지 그대로 확인 가능하기 때문
• ROW 포맷에서는 값 자체를 기록하므로 SQL 은 확인 불가
• MariaDB 5.3 의 주석 이벤트, MySQL 5.6 의 정보성 로그 이벤트 도입으로 보완

MariaDB 주석 이벤트

• 사용자가 수행 한 문장을 "Annotate_rows" 이벤트로 기록

MySQL 정보성 로그 이벤트

• 사용자가 수행 한 문장을 "Rows_query" 이벤트로 기록