17.1.3.1 GTID 개념
글로벌 트랜잭션 식별자 (GTID)은 발생원의 서버 (마스터)로 작성되어 거기서 커밋 된 각 트랜잭션에 연결된 고유 식별자입니다. 이 식별자는 서버는 물론 특정 복제 설정의 모든 서버에 고유합니다. 모든 트랜잭션 및 모든 GTID 사이에는 1 대 1 매핑이 있습니다.
GTID는 좌표 쌍으로 표현되며 다음과 같이 콜론 문자 ( : )으로 구분됩니다.
GTID =source_id:transaction_id
source_id 는 발생원 서버를 식별합니다. 일반적으로 서버의 server_uuid 는이 목적을 위해 사용됩니다. transaction_id 이 서버에서 커밋 된 순서에 의해 결정되는 시퀀스 번호입니다. 예를 들어, 커밋되는 첫 번째 트랜잭션에는 그 transaction_id 로 1 가 할당 같은 발생원 서버에서 커밋되는 10 번째 트랜잭션은 transaction_id 로 10 이 할당됩니다. 트랜잭션에 GTID 시퀀스 번호로 0 을 할당 할 수 없습니다. 예를 들어, UUID가 3E11FA47-71CA-11E1-9E33-C80AA9429562 의 발생원 서버에서 커밋 된 23 번째 트랜잭션 GTID은 다음과 같습니다.
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
이 형식은 SHOW SLAVE STATUS 등의 문 출력이나 바이너리 로그에서 GTID을 나타내는 데 사용됩니다. 그들은 mysqlbinlog --base64-output=DECODE-ROWS 에서 로그 파일을 볼 때 또는 SHOW BINLOG EVENTS 의 출력에서도 볼 수 있습니다.
GTID은 SHOW MASTER STATUS 와 SHOW SLAVE STATUS 등의 문 출력에 기록 될 때 동일한 서버에서 발생하는 GTID 순서는 다음과 같이 단일 표현으로 정리 될 수 있습니다.
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
이 예는 server_uuid 이 3E11FA47-71CA-11E1-9E33-C80AA9429562 의 MySQL Server에서 발생하는 1 번째부터 다섯 번째까지의 트랜잭션을 나타냅니다.
MySQL 5.6.6 이후에서는,이 형식은 START SLAVE 옵션 SQL_BEFORE_GTIDS 및 SQL_AFTER_GTIDS 에서 필요한 인수를 지정하는 데 사용됩니다.
GTID 세트
GTID 세트는 다음과 같이 표현되는 글로벌 트랜잭션 식별자 집합입니다.
gtid_set:uuid_set[,uuid_set] ... | ''uuid_set:uuid:interval[:interval]...uuid:hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhhh: [0-9|A-F]interval:n[-n] (n>= 1)
GTID 세트는 MySQL Server에서 여러 가지 방법으로 사용됩니다. 예를 들어, gtid_executed 과 gtid_purged 시스템 변수에 의해 저장되는 값은 GTID 세트로 표현됩니다. 또한 함수 GTID_SUBSET() 및 GTID_SUBTRACT() 는 입력으로 GTID 세트가 필요합니다.
GTID는 마스터와 슬레이브 사이에서 항상 유지됩니다. 이것은 바이너리 로그를 검사하여 슬레이브에 적용 된 트랜잭션의 소스를 언제든지 확인할 수있는 의미합니다. 또한, GTID 트랜잭션이있는 서버에서 커밋되면 같은 GTID 이후의 트랜잭션은 서버에서 무시됩니다. 이와 같이, 마스터 커밋 된 트랜잭션은 슬레이브에서 한 번만 적용하여 일관성 확보 할 수 있습니다.
GTID가 사용되는 경우, 마스터에서 파일 이름이나 파일에서의 위치 등 비 로컬 데이터가 슬레이브에 필요하지 않습니다. 마스터와 동기화하는 데 필요한 모든 데이터는 복제 데이터 스트림에서 직접 검색됩니다. 데이터베이스 관리자 또는 개발자는 GTID 파일 오프셋 쌍을 완전히 대체합니다 (이전은 마스터와 슬레이브 간의 데이터 흐름을 시작, 중지 또는 다시 시작 포인트를 결정하기 위해 필요했습니다). 이것은 복제에 GTID를 사용하는 경우에는 소정의 마스터에서 복제하도록 슬레이브에 지시하는 데 사용하는 MASTER_LOG_FILE 또는 MASTER_LOG_POS 옵션을 CHANGE MASTER TO 문에 포함되어야 없습니다 (포함하지 않습니다). 이 옵션 대신 필요한 것은 MySQL 5.6.5에서 도입 된 MASTER_AUTO_POSITION 옵션을 활성화 할뿐입니다. GTID 기반 복제를 사용하여 마스터와 슬레이브를 구성하고 실행하는 데 필요한 정확한 절차는 섹션 17.1.3.2 "GTID를 사용한 복제 설정" 을 참조하십시오.
GTID의 생성과 라이프 사이클은 다음과 같이 구성됩니다.
트랜잭션이 마스터에서 실행되고 커밋됩니다.
이 거래는 마스터의 UUID와이 서버에서 아직 사용되지 않은 최소의 제로가 아닌 트랜잭션 시퀀스 번호를 사용하는 GTID이 할당됩니다. GTID는 마스터의 바이너리 로그에 기록됩니다 (로그의 트랜잭션 자체의 직전).
바이너리 로그가 슬레이브에 전송 된 슬레이브 릴레이 로그에 저장된 후 (이 과정을 위해 설립 된 메커니즘을 사용합니다. 자세한 내용은 섹션 17.2 "복제 구현" 을 참조하십시오) 슬레이브 는 GTID을 읽고
gtid_next시스템 변수 값이 GTID로 설정합니다. 이것은 다음 트랜잭션 로그는이 GTID를 사용하여 기록 될 필요가 있음을 슬레이브에 전달합니다.슬레이브는 세션 컨텍스트에
gtid_next을 설정하는 것에 주목하는 것이 중요합니다.슬레이브는 자신의 바이너리 로그에 트랜잭션 로그를 기록하기 위해이 GTID가 확실히 아직 사용되지 않았 음을 확인합니다. 이 GTID가 사용되지 않은 경우에만 노예 GTID을 쓰기 트랜잭션을 적용합니다 (그리고 트랜잭션을 바이너리 로그에 기록합니다). 트랜잭션 자체를 처리하기 전에 먼저 트랜잭션 GTID를 읽고 체크함으로써 슬레이브는이 GTID을 가진 이전 트랜잭션이 슬레이브에 아직 적용되지 않았는지, 또한 다른 세션이 아직이 GTID을 읽고 않고 연결된 트랜잭션을 커밋하지 않는 것을 보증합니다. 즉, 여러 클라이언트가 병렬로 동일한 트랜잭션을 적용하는 것은 허용되지 않습니다.
gtid_next가 비어 있지 않은 슬레이브는이 트랜잭션 GTID을 생성하려고하지 않고, 대신에이 변수에 저장된 GTID (즉, 마스터로부터 취득한 GTID)을 바이너리 로그의 트랜잭션 직전에 기입합니다.