- 글로벌 트랜잭션 아이디
- 글로벌 트랜잭션 아이디란?(GTID)
- Global Transaction ID의 약자
- 바이너리 로그 파일명이나 위치는 해당 이벤트가 저장된 물리적인 위치를 가리키지만 글로벌 트랜잭션 아이디는 논리적인 의미
- 주로 서버의 노드 아이디와 트랜잭션 아이디로 구성되어있어서 마스터와 슬레이브 간에 중복될 가능성이 없음
- DML, DDL 이 발생할 때마다 트랜잭션 아이디가 1씩 증가하면서 글로벌 트랜잭션 아이디가 생성되며 바이너리 로그 이벤트와 매핑됨
- 글로벌 트랜잭션 아이디가 슬레이브로 전달되면 릴레이 로그 파일이나 슬레이브 바이너리 로그 파일로 기록
- 글로벌 트랜잭션 아이디의 필요성
- 동기화 시 파일 내의 위치를 찾아서 (물리적) 복제를 수행하기는 어려움
- 글로벌 트랜잭션을 사용하면 적용된 글로벌 트랜잭션 이후부터 동기화를 할 수 있음
- MariaDB 10.0 글로벌 트랜잭션 아이디
- 글로벌 트랜잭션 아이디는 도메인아이디 – 서버 아이디 – 트랜잭션 아이디로 구성
- GTID를 이용한 복제 구축
- 마스터 서버의 데이터 백업
- 슬레이브 서버에서 1번 백업 파일로 복구
- 슬레이브에서 바이너리 로그 파일명과 위치 확인
- 3번을 이용하여 마스터의 GTID 확인
- 슬레이브의 GTID를 4번 결과값으로 변경
- 슬레이브에서 복제 설정
- GTID를 사용한 복제 관리
- 바이너리 로그 파일명과 위치로 글로벌 트랜잭션 아이디 찾기: BINLOG_GTID_POS('로그파일명','위치')
바이너리 로그 파일명과 위치 확인
BINLOG_GTID_POS로 GTID 확인
- 글로벌 트랜잭션 아이디까지 대기: MASTER_GTID_WAIT('GTID','시간')
- 초기 복제 연결; MASTER_USE_GTID=SLAVE_POS
- 바이너리 로그 파일과 위치 기반의 복제를 GTID 기반으로 변경: MASTER_USE_GTID=CURRENT_POS
- 마스터 MariaDB 변경: CHANGE MATSER TO MASTER_HOST='변경할 마스터 IP'
- 특정 위치까지 실행 후 복제 멈춤: START SLAVE UNTIL MASTER_GTID_POST='GTID'
- GTID를 이용한 슬레이브에서 트랜잭션 건너뛰기
- 서버의 비정상 종료로 슬레이브에서 중복키 에러가 발생할 때 해당 이벤트를 건너뛰고 복제를 진행해야 함
- 이벤트를 건너뛰는 시스템변수(SQL_SLAVE_SKIP_COUNTER)는 MariaDB 10.0에서는 사용할 수 없음
- 에러가 발생한 GTID를 확인해서 GTID값을 증가시켜 재설정 후 복제를 다시 시작
- 멀티 소스 복제
- 멀티 소스 복제 관련 명령
- 멀티 소스 복제란 하나의 슬레이브가 두 개 이상의 마스터 MariaDB로부터 데이터를 복제하는 것을 의미
- 복제 관련 명령을 사용할 때 어느 마스터 서버와 연결된 복제에 대해서 실행될지 선택할 수 있도록 복제 연결의 이름을 명시해야 함
- 멀티 소스 복제 구축
- A와 B서버 모두 데이터가 크지 않을 경우: mysqldump 사용
- A 서버의 데이터는 크고 B서버의 데이터는 적을 경우: A 서버는 XtraBackup으로 백업 및 복구한 후 B서버의 mysqldump파일로 적재
- A, B 모두 데이터가 많을 경우: 두 서버에서 XtraBackup 백업을 진행한 후, 둘 중 테이블 개수가 많은 서버의 백업 파일로 슬레이브에 적재, B서버의 백업 파일 중 innoDB/XtraDB 파일의 ibd를 이용해서 슬레이브에 임포트
- 멀티 소스 복제와 글로벌 트랜잭션
- gtid_slave_pos에 각 마스터의 GTID 값을 ','로 연결해서 설정
- 멀티 스레드 복제
- MySQL 5.6의 멀티 스레드 복제
- 데이터베이스 단위로 병렬 처리를 지원하기 때문에 데이터베이스 수 만큼 슬레이브의 스레드 개수를 설정해주는 것이 좋음
- 실제 바이너리 로그 파일에 기록된 이벤트 순서대로 슬레이브에서 실행하지는 않음
- MariaDB 10.0의 멀티 스레드 복제
- 도메인 아이디를 기준으로 작동하며 여러 마스터로부터 전달된 바이너리 로그에 각각의 스레드가 할당되어서 바이너리 로그 이벤트를 처리함
- 사용자가 멀티 스레드 복제 여부를 결정할 수 있음
- 다음 쿼리에 대해서 멀티 스레드로 복제 가능
- 마스터에서 하나의 그룹 커밋에 속한 쿼리
- 다른 도메인 아이디를 가진 쿼리
- 멀티 소스 복제에서 서로 다른 마스터로부터 가져온 쿼리
- 크래시 세이프 슬레이브
- IO 스레드 : 마스터로부터 바이너리 로그 이벤트를 슬레이브 로컬 디스크에 파일로 저장하는 역할
- SQL 스레드 : 바이너리 로그 이벤트를 실제 서버에서 재실행해서 슬레이브에 적용하는 역할
- 바이너리 파일이 복제될 때마다 파일의 내용을 변경하고 디스크에 동기화하는 작업이 필요 -> 비동기로 처리할 경우 서버가 비정상적으로 종료했을 때 파일의 내용 손실이 있을 수 있음 -> 서버 재가동 시 파일의 내용은 이전의 값을 가지고 있기 때문에 복제됐던 부분이 다시 복제되면서 중복키 에러가 발생할 수 있음 -> 파일의 내용을 테이블로 저장할 수 있는 기능 추가 (크래시 세이프 복제)
- MariaDB 10.0의 크래시 세이프 복제
- 글로벌 트랜잭션 아이디를 사용하는 경우 슬레이브가 실행한 복제 위치 정보가 gtid_slave_pos라는 테이블에 자동 저장
- MySQL 5.6의 크래시 세이프 복제
- 글로벌 트랜잭셩 아이디 사용 여부에 관계없이 크래시 세이프 복제를 사용할지를 설정할 수 있음
- ROW 기반의 복제 기능 개선
- ROW 포맷의 용량 최적화
- STATEMENT 포맷: 용량이 작음, 실행한 SQL 문장이 그대로 기록됨/UUID 함수와 비결정적 함수(NOT DETERMINITIC) 의 기능들에 대해서는 복제를 수행할 수 없음
- ROW 포맷: 최종적으로 테이블에 적용된 컬럼의 값을 바이너리 로그에 기록하기 때문에 복제에 대한 제한 사항이 없음/용량이 큼
- MIXED 포맷: STATEMENT 포맷과 ROW 포맷의 장점을 혼합
- ROW 포맷 바이너리 로그를 위한 정보성 로그 이벤트
- MariaDB 주석 이벤트
- 변경된 레코드 정보가 바이너리 로그에 기록되기 전에 사용자가 실행한 SQL 문장을 바이너리 로그 이벤트로 기록할 수 있도록 보완
- SHOW BINLOG EVENTS IN '로그파일명';
- MySQL 5.6의 정보성 로그 이벤트
- MariaDB와 동일하게 주석 이벤트 기능 도입
- 지연된 복제
- 일부러 지연시켜서 복제를 수행할 수 있음
- CHANGE MASTER TO… MASTER_DELAY=시간(초);
- 마스터의 바이너리 파일은 즉시 슬레이브에 복사되지만 적용을 지연시키는 것이며 이 파일을 이용해서 바로 복제할 수도 있음
- MariaDB와 Mysql 서버간의 복제
- 그 외의 기타 기능 개선
- 바이너리 로그 체크섬
- 바이너리 로그 API
- 바이너리 로그 그룹 커밋
- 여러 개의 트랜잭션 바이너리 로그를 모아서 한 번에 플러시를 수행
'MariaDB > Admin' 카테고리의 다른 글
| [MariaDB][운영] CentOS7에서 logrodate로 로그 파일이 rotation되지 않을 경우 (0) | 2016.08.09 |
|---|---|
| [MariaDB][Admin] DB 생성 과 테이블 조작(DDL, DML) (0) | 2016.08.07 |
| 기타 기능2 (0) | 2015.10.26 |
| [MariaDB][Admin]스토리지 엔진 - InnoDB (0) | 2015.10.20 |
| 스토리지 엔진 2 (0) | 2015.10.20 |