- GTID ( Global Transaction IDentifiler )
- master 서버에서 commit 된 트랜잭션과 연관된 유일한 식별자로 생성됨
- 연관된 모든 서버에서 유일한 식별자이며, 모든 트랜잭션과 GTID 들은 1:1 관계이다.
- source_id, transaction_id 로 구성되어있고 (:) 로 나뉘어져있음.
GTID = source_id:transaction_id
- source_id 는 서버 식별자 ( server_uuid )
- transaction_id 는 해당 서버에서 커밋된 트랜잭션의 순서에 따라 결정된 순차적인 숫자이다.
예로, 첫 번째 트랜잭션은 transaction_id = 1 로 커밋되고, 동일한 서버에서 열 번째 트랜잭션은 transaction_id = 10 이 된다.
( GTID 에서 트랜잭션이 순차적인 숫자 0 은 될 수 없다 )
- 서버 id (UUID) 가 3E11FA47-71CA-11E1-9E33-C80AA9429562 인 23번째 트랜잭션은 GTID 가 아래와 같다.
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
- GTID 는 binary log 뿐만 아니라, SHOW SLAVE STATUS 구문에서 확인 가능하다.
- mysqlbinlog --base64-output=DECODE-ROWS 문장으로 log file 에서 확인하거나 SHOW BINLOG EVENTS 의 결과에서도 볼 수 있다.
- SHOW MASTER STATUS 나 SHOW SLAVE STATUS 명령의 결과와 같이,
동일 서버에서 생긴 GTID 의 순서는 단문으로 축소되어 아래와 같이 보여진다
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
=> server_uuid 가 3E11FA47-71CA-11E1-9E33-C80AA9429562 인 서버에서 생성된
다섯 번째 트랜잭션을 통한 첫 번째를 나타낸다.
- MySQL 5.6.6 이후에는 START SLAVE 옵션인 SQL_BEFORE_GTIDS 와 SQL_AFTER_GTIDS 변수를 제공한다.
- GTID sets
gtid_set :
uuid_set [, uuid_set] ... | ''
uuid_set :
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h :
[0-9|A-F]
interval:
n[-n]
(n >= 1)
- GTID set 은 MySQL 서버에서 여러 방법으로 사용된다.
예를들면, gtid_executed , gtid_purged system variables 로 값이 저장된 것들이 GTID set 으로 표현된다.
GTID_SUBSET() 함수와 GTID_SUBTRACT() 함수는 GTID sets 입력값을 필요로 한다.
- GTID 는 master 와 slave 사이에서 보존된다. 이 의미는, 당신이 언제나 binary log 를 검사하여
모든 slave 에 적용된 모든 트랜잭션에 대한 원인을 판별할 수 있음을 의미한다.
- 주어진 서버에서 커밋된 GTID 를 가진 트랜잭션은, 동일한 GTID 를 가진 이후 트랜잭션은 서버에서 무시된다.
결과적으로, master 서버에서 commit 된 트랜잭션은 한번 이상 slave 에 적용되지 않으며, 이는 일관성을 보장한다.
- GTID 를 사용할 때, slave 는 master 에 있는 파일 이름과 해당 파일의 포지션과 같은 로컬데이터가 전혀 필요하지 않다.
- master 와 싱크를 위한 모든 필요한 정보는 replication data stream 으로 부터 받는다.
- replication 을 위해 GTID 를 사용한다면, master 서버로 부터 복제를 위한 slave 서버에 사용되는
CHANGE MASTER TO 구문에서 MASTER_LOG_FILE, MASTER_LOG_POS 옵션을 필요로 하지 않는다.
- MySQL 5.6.5 부터 소개된 MASTER_AUTO_POSITION 옵션을 활성화 하는 것 만 필요하다.
GTID를 기반으로하는 replication 을 사용할 경우, master와 slave 를 시작하고 설정하려면 아래 url 을 참고한다.
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html
- GTID의 생성 및 주기는 다음과 같은 스텝으로 진행된다.
1. Master 에서 실행되고 커밋된 트랜잭션
- 이 트랜잭션은 master 의 UUID 와, 아직 사용되지 않은 0 이 아닌 가장 작은 트랜잭션 순차 숫자를 사용한 GTID 로 할당된다.
GTID 는 Master 서버의 binary log 에 쓰여진다 (log 내에서 즉시 트랜잭션 자체 선행)
slave 는 GTID 를 읽고, 해당 값으로 gtid_next 시스템 변수 값을 설정한다.
이는 slave 다음 트랜잭션도 반드시 해당 GTID 를 사용해 로깅 되어야 하는 것을 뜻한다.
슬레이브 session 문장에 gtid_next 를 셋팅하는 것이 중요하다.
3. 슬레이브는 이 GTID가 이미 자신의 바이너리 로그에있는 트랜잭션을 기록하는 데 사용되지 않았음을 확인하기 위해 검사합니다.
만일 GTID 가 사용되지 않았다면, slave 는 GTID 를 쓰고 트랜잭션을 적용한다. ( 그리고 binary log 에 트랜잭션을 작성한다.)
트랜잭션을 실행하기 전에 트랜잭션의 GTID 를 먼저 읽고 체크하는 것은,
slave 가 해당 GTID 를 가진 이전 트랜잭션이 slave 에 적용되지 않았음 과
다른 세션이 해당 GTID 를 읽지 않았음을 보장하는 것이다. 아직 커밋되거나 적용되지 않은 트랜잭션에 대해
다른 말로, 여러개의 클라이언트는 동일한 트랜잭션을 동시 적용이 허용되지 않음을 뜻한다.
4. gtid_next 값이 비어있지 않아서, slave 는 이 트랜잭션에 대한 GTID 를 생성하려고 시도하지 않는 대신,
이 변수에 GTID 를 저장한다. - 이는 master 로부터 획득한 GTID - binary log 내에 트랜잭션을 즉시 선행한다.