by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

08. 레플리케이션 (61p)




1. 글로벌 트렌젝션 ID




  • Replication 이란 고가용성 및 부하 분산을 위한 기능
  • 마스터 노드 에서 수행 된 Transaction 을 슬레이브 노드에 로그를 이용해 읽기 전용으로 복제
    GTID 사용 이전 버전에서는

    *마스터 노드의 바이너리 로그 파일 이름과 위치를 전달하는 방법 사용
    *파일 위치와 정보 등은 서버 내에서만 의미 있는 정보이므로 여러 슬레이브 노드 간 호환되지 않음



1) GTID 란




  • 파일의 물리적 위치정보가 아니라 전체 node 간 호환 가능한 가상의 트렌젝션 ID
  • 각 노드들의 바이너리 로그파일 및 Offset 정보가 다를지라도 글로벌 ID 값은 동일
  • 트렌젝션을 지원하는 스토리지 엔진에서는 거의 트렌젝션 단위로 GTID 채번, 미 지원 엔진에서는 SQL 단위로 채번

    MySQL 의 GTID 는
  • GTID 시퀀스에서 누락 값을 허용하지 않음
  • 멀티 스레드 복제 시 바이너리 로그의 순서와 무관하게 수행 가능
MariaDB 의 GTID 는
  • GTID 시퀀스에서 누락 값을 허용
  • 멀티 스레드 복제 시 바이너리 로그의 순서대로 수행



2) GTID 의 필요성





하나의 마스터에 두 개 이상의 슬레이브가 연결 된 복제 DB 에서 마스터 서버에 장애 발생 시
  • 슬레이브 중 하나의 노드를 마스터로 승격시키고
  • 다른 하나의 슬레이브를 새로 생긴 마스터 노드를 바라보게 전환
  • 이 때 장애 발생 전 슬레이브 노드 간 전송 지연등에 의해 시점 차이가 있었을 경우 장애 이후 자동 동기화 불가



글로벌 ID 를 사용한다면
  • 모든 노드 간 동일한 ID 값을 사용하므로
  • 마스터 노드가 바뀌더라도 무관
  • 전송 지연이 된 슬레이브라도 새로 승격 된 마스터에서 동일한 GTID 값을 이용해 따라잡을 수 있다



1) Maria DB 의 GTID



  • "도메인 ID - 서버 ID - 트렌젝션 ID" 의 형식
  • 도메인 ID 는 멀티 소스 레플리케이션 시 사용할 수 있는 마스터 노드의 정보

GTID 를 스용한 복제 구축 절차



1. 바이너리 로그 파일과 위치 기반 복제를 GTID 로 변경
2. 기존 DB 서버의 데이터 백업
3. 새 슬레이브에 데이터 복구
4. 백업 시점의 바이너리 로그 파일명과 위치 확인
5. 바이너리 로그와 위치로 GTID 확인
6. 슬레이브의 GTID 값을 마스터의 GTID 로 변경
7. 슬레이브에서 CHANGE MASTER 명령 수행하여 마스터와 연결

GTID 를 사용한 복제 관리



GTID 를 이용하여 슬레이브에서 복제 건너뛰기



*사용자의 실수나 장애로 인해 특정 이벤트의 중복 키 에러가 자주 발생한는 편이다
*복제가 에러로 멈췄을 때 마지막 TGID 값을 확인하여 그 다음 GTID 값으로 재 설정



1) MySQL 의 GTID



*"서버 UUID : 트렌젝션 번호" 의 체계를 갖춤

  • GTID 컨시스턴스 모드를 활성화 해야 한다는 제약이 있음
    --> 이 때 CTAS와 같은 명령을 사용할 수 없다 - DML 과 DDL 이 결합 된 형태이므로 에러 발생 시 롤백이 불가능하다고 함

GTID 를 스용한 복제 구축 절차


  • Maria DB 와 동일


GTID 관련 함수



GTID 를 이용하여 슬레이브에서 복제 건너뛰기



  • Marai DB 와 다르게 트렌젝션 번호의 누락을 허용하지 않는다.
  • 건너 뛸 GTID 로 슬레이브 DB 의 파라메터 값을 맞춰주고 더미 트렌젝션(BEGIN; COMMIT 을 수행



2. 멀티 소스 복제




  • Maria 10.0 부터(MySQL 은 5.7 부터 예상) 부터 구현 가능함
  • 일반적인 복제에서는 CUD 작업은 마스터 노드에서만 가능하기 때문에 쓰기 성능을 확장 하고자 만들어 진 개념



1) 멀티소스 복제 관련 명령



1) 멀티소스 복제 구축



  • 기존 복제와 큰 차이가 있는것은 아님
  • 마스터의 데이터를 슬레이브에 백업-복구 시 시스템 테이블스페이스 등 공통 데이터 충돌에 대한 고려 필요

백업-복구 방식


  • mysqldump 와 같은 논리적 백업-복구

물리적 백업/복구가 아니라 실 데이터만 이동하므로 병합 시 문제가 생기지 않는다
데이터가 크다면 구축에 오랜 시간이 소요

  • XtraBackup 과 같은 물리적 백업-복구

DB 모든 데이터 파일을 복사하므로 시스템 테이블스페이스에 대한 충돌을 막을 수 없다

충돌을 고려한 백업 복구 방안


1. 마스터 두 노드의 데이터가 모두 크지 않을 경우

  • mysqldump 와 같은 논리적 백업으로 양 DB 데이터 모두 이관

2. 마스터 두 노드의 한쪽이 큰 경우

  • 대용량 DB 쪽을 XtraBackup 으로 물리적 이행, 작은쪽을 mysqldump 로 논리적 이행

3. 마스터 두 노드 모두 대용량일 경우

  • 둘 다 XtraBackup 으로 물리 백업 수행
  • 테!11.JPG!이블 갯수가 많은쪽을 먼저 슬레이브로 이행
  • 남은 백업에서 테이블의 ibd 파일을 하나씩 추출하여 슬레이브에 임포트



1) 멀티소스 복제와 글로벌 트렌젝션



  • 일반 복제 구성과 다르지 않게 구성 가능하다
  • GTID 의 첫 부분이 도메인 값으로 구성 되어 있으므로 슬레이브에서 GTID 끼리 충돌은 발생하지 않는다



3. 멀티 스레드 복제




  • 성능 향상을 위한 병렬처리 개념

1) MySQL 의 멀티 스레드 복제




멀티 쓰레드는 데이터베이스 단위로 병렬 처리를 지원함
  • 데이터베이스가 하나 일 경우 아무 장점이 없다
  • 사용하는 데이터베이스의 개수만큼 슬레이브의 쓰레드 개수 설정
멀티 쓰레드 코디네이터의 기능과 역할




  • 릴레이 로그 파일의 바이너리 로그 이벤트를 읽어 데이터베이스 단위로 분리하고 슬레이브의 각 스레드에 분배
  • 이벤트 간 충돌에 대한 제어 - 테이블이나 row 단위의 lock 을 제어하는게 아닌 데이터베이스 단위로 수행
마스터에서 이벤트 발생 순서대로 슬레이브에서 처리되지 않는다


  • DB 단위로 분배되므로 빠른 순서가 먼저 수행 됨
  • 하나의 GTID 에 복제 된 시점의 바이너리 로그 위치를 표현할 수 없음
  • 이로 인해 GTID Set 의 개념 사용 - "서버UUID:시작 Transaction 번호 - 마지막 Transaction 번호" 의 연속으로 구성
  • 누락된 Transaction 번호가 있을 경우 "UUID:Start#-End#" 의 나열이 너무 많아질 수 있어서 누락을 아예 허용하지 않는다고 함

1) Maria DB 의 멀티 스레드 복제



  • 순차/비순차의 두 가지 방식 지원

비 순차 복제


*도메인 ID 를 기준으로 동작하며 데이터베이스 단위의 멀티 스레드는 지원하지 않음
*하나의 마스터만 있는 경우에는
도메인 ID 는 세션 단위로 설정 가능한 변수이므로
배치 프로그램 등에서 임의로 도메인 ID 를 지정하여 수행 하면 슬레이브에서 멀티 스레드로 동작 가능



순차 복제



  • 바이너리 로그의 그룹 커밋이란?
    쓰기 성능 향상을 위해 여러 이벤트를 한번에 모아 커밋 처리

*순차 복제 시 동일 그룹의 트렌젝션을 대상으로 처리
*코디네이터 스레드가 각 SQL 스레드에 커밋 그룹 단위로 작업 분배
*커밋 그룹 간의 충돌이 없다는게 이미 마스터에서 검증 되었으므로 가능
*하나의 그룹 내에 트렌젝션이 많을 수록 - 빠르고 가벼운 쿼리들이 빈번하게 사용되는 환경에서 유용 함




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



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


IO 스레드

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

SQL 스레드

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

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

크래시 세이프 복제




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

1) Maria DB 의 크래시 세이프 복제



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

1) MySQL DB 의 크래시 세이프 복제



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


ROW 기반의 복제 성능 개선



1) ROW 포맷의 용량 최적화



STATEMENT 타입을 사용한 용량 최적화
  • 전통적인 방법 - SQL 문장을 저장하는 방법인 듯
  • UUID 함수와 같이 비 결정적(NOT DETERMINISTIC) 함수나 기능들에 대해서는 복제 불가능
ROW 타입
  • 최종적으로 테이블에 저장 된 값을 저장하므로 제약이 없음
  • STATEMEMTN 타입보다 많은 저장공간 필요
MIXED TYPE
  • STATEMENT 타입과 ROW 타입의 장점을 결합

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



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" 이벤트로 기록






문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.