MySQL 5.6 한글메뉴얼

17.1.3.4 GTID 기반 리플리케이션 제약

GTID 기반 복제는 트랜잭션에 의존하고 있기 때문에, 그렇지 않으면 MySQL에서 사용할 수있는 몇 가지 기능이 그것을 사용할 때 지원되지 않습니다. 이 섹션에서는 GTID 기반 복제의 제약과 한계에 대한 정보를 제공합니다.

비 트랜잭션 스토리지 엔진에 관련된 업데이트 GTID을 사용하는 경우 MyISAM 과 같은 비 트랜잭션 스토리지 엔진을 사용하는 테이블에 대한 업데이트는 InnoDB 등의 트랜잭션 스토리지 엔진을 사용하는 테이블에 대한 업데이트와 같은 문이나 트랜잭션에서 실행 수 없습니다.

이 제약은 비 트랜잭션 스토리지 엔진을 사용하는 테이블에 대한 업데이트 및 트랜잭션 스토리지 엔진을 사용하는 테이블에 대한 업데이트가 동일한 트랜잭션 내에 혼합하고 여러 GTID이 같은 트랜잭션에 할당 된 수 때문입니다.

이러한 문제는 마스터와 슬레이브가 서로 다른 스토리지 엔진을 각 버전의 같은 테이블에 사용하는 경우에도 발생할 수 있습니다 (하나의 스토리지 엔진은 트랜잭션 다른 하나는 그렇지 않다).

지금 꼽았다 어떠한 경우에도 트랜잭션과 GTID 간의 1 대 1 대응이 손상되어, GTID 기반 복제는 제대로 작동하지 않습니다.

CREATE TABLE ... SELECT 문 CREATE TABLE ... SELECT 명령문 기반 복제는 안전하지 않습니다. 열 기반 리플리케이션을 사용하는 경우이 문 로그는 실제로 두 가지 이벤트로 기록됩니다. 하나는 테이블을 만드는 것, 다른 하나는 소스 테이블에서 작성된 막 새 테이블에 행을 삽입하는 것입니다. 이 문은 트랜잭션 내에서 실행되는 동일한 트랜잭션 식별자를받는이 두 이벤트에 몇 가지 경우가 가능하며, 이것은 삽입이 포함 된 트랜잭션이 슬레이브에 의해 스킵되는 것을 의미합니다. 따라서 GTID 기반 복제를 사용하는 경우, CREATE TABLE ... SELECT 은 지원되지 않습니다.

임시 테이블 CREATE TEMPORARY TABLE 및 DROP TEMPORARY TABLE 문은 GTID를 사용할 때 (즉, 서버가 --enforce-gtid-consistency 옵션에서 시작되었을 때) 트랜잭션 내에서 지원되지 않습니다. GTID을 활성화 한 상태에서이 문을 사용하는 것은 가능합니다 (그러나 트랜잭션의 외부만을 및 autocommit=1 의 경우에만).

지원되지 않는 명령문 실행 방지 GTID 기반 복제가 실패하는 명령문의 실행을 방지하기 위해 GTID를 사용하면 모든 서버가 --enforce-gtid-consistency 옵션에서 시작되어야합니다. 따라서이 절에서 이미 언급 한 유형의 문은 오류로 실패합니다.

GTID을 활성화하는 데 필요한 다른 부팅 옵션은 섹션 17.1.3.2 "GTID를 사용한 복제 설정" 을 참조하십시오.

GTID를 사용하면 sql_slave_skip_counter 는 지원되지 않습니다. 트랜잭션을 스킵 할 필요가있는 경우 대신 마스터 gtid_executed 변수를 사용하십시오. 자세한 내용은 빈 트랜잭션의 주입 을 참조하십시오.

GTID 모드와 mysqldump MySQL 5.6.9 이후에서는 대상 서버의 바이너리 로그에 GTID이 없는지 경우 mysqldump를 사용하여 생성 된 덤프를 GTID 모드가 활성화 된 상태에서 동작하는 MySQL Server로 가져올 수 있습니다.

MySQL 5.6.9 이전에서는 mysqldump는 글로벌 트랜잭션 ID를 기록하지 않고 GTID을 복원하기 위해 바이너리 로그와 mysqlbinlog를 사용할 필요가있었습니다. (Bug # 14797808, Bug # 14832472)

GTID 모드와 mysql_upgrade MySQL 5.6.7 이전에서는 mysql_upgrade이 --write-binlog=OFF 에서 실행되지 않는 한, mysql_upgrade는 --gtid-mode=ON 에서 동작하는 MySQL Server에 연결할 수 없습니다. (그렇지 않은 경우, mysqld는 mysql_upgrade를 실행하기 전에 --gtid-mode=OFF 에서 다시 시작되고 나서 나중에 --gtid_mode=ON 으로 다시 시작해야했습니다.) 이것은 MySQL 5.6.7 이상에서 문제가 아니라 mysql_upgrade는 기본적으로 --write-binlog=OFF 로 작동합니다. (Bug # 13833710) 그러나 그렇게하는 것은 권장되지 않습니다. mysql_upgrade이 MyISAM 스토리지 엔진 (비 트랜잭션)을 사용하는 시스템 테이블을 변경할 수 있기 때문입니다.