17.1.3.3 GTID Auto-Positioning

원문: https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-auto-positioning.html

GTIDs는 원본과 리플리카 사이의 데이터 흐름을 시작하고, 멈추고, 또는 재개하려는 지점을 결정하기 위해서 이전에 필요로했던 파일 오프셋(file-offset)쌍을 대체한다. GTIDs가 사용될 때, 리플리카가 소스와 동기화하는데에 필요한 모든 정보는 리플리케이션 데이터 스트림으로부터 직접 획득하게 된다.

GTID-based 리플리케이션을 사용해서 리플리카를 시작하려면, 리플리카가 주어진 소스로부터 복제하기 위해서 사용하는 CHANGE MASTER TO 문장에 MASTER_LOG_FILE 이나 MASTER_LOG_POS 옵션을 포함시키면 안된다. 이 옵션들은 로그 파일의 이름과 파일 내의 시작 지점을 명시하는데, GTIDs를 사용하는 리플리카는 이러한 논로컬(nonlocal)의 데이터가 필요하지 않다. 대신 MASTER_AUTO_POSITION 옵션을 활성화할 필요가 있다. GTID-based 리플리케이션을 사용해서 소스와 리플리카를 구성하고 시작하기 위한 전체 지침은 17.1.3.4, "Setting Up Replication Using GTIDs" 부분을 참고한다.

MATER_AUTO_POSITION 옵션은 기본적으로 비활성화되어 있다. 만약 리플리카에서 멀티 소스(multi-source)리플리케이션이 활성화되어 있다면, 각각 해당되는 리플리케이션 채널마다 이 옵션을 설정해야 한다. MASTER_AUTO_POSITION 옵션을 다시 비활성화한다는 것은 리플리카를 file-based 리플리케이션으로 되돌아가는 것이며, 이러한 경우에 MASTER_LOG_FILE이나 MASTER_LOG_POSITION을 하나 또는 둘 다 지정해야 한다.

리플리카가 GTIDs를 설정(GTID_MODE=ON, ON_PERMISSIVE or OFF_PERMISSIVE)하고, MASTER_AUTO_POSITION 옵션을 설정했을 때, 소스로의 연결에 대해서 오토 포지셔닝(auto-positioning)은 활성화된다. 연결이 성공하기 위해서 원본은 반드시 GTID_MODE=ON으로 설정해야 한다. 초기의 핸드쉐이크(handshake)에서, 이미 수신했거나 커밋된, 또는 둘다 적용된 트랜잭션들을 포함하는 GTID 셋을 보낸다. 이 GTID의 셋은 gtid_executed(@@GLOBAL.gtid_executed 시스템 변수 내의 GTIDs 집합, 그리고 Performance Schema의 replication_connection_status 테이블에 수신된 트랜잭션으로서 기록된 GTIDs의 집합 (SELECT RECEIVED_TRANSACTION_SET FROM PERFORMANCE_SCHEMA.replication_connection_status 문장의 결과)의 합집합과 동일하다.

소스는 리플리카가 보낸 GTID 셋에 GTID가 포함되지 않는 바이너리 로그 내에 기록된 모든 트랜잭션들 전송함으로써 응답한다. 이렇게 하기 위해서, 소스는 먼저 가장 최근의 것을 시작으로 각 바이너리 로그 파일의 헤더에 있는 Previous_gtids_log_event를 체크함으로써 작업을 시작할 적절한 바이너리 로그 파일을 식별한다. 소스가 리플리카가 누락한 트랜잭션을 포함하지 않는 첫 번째 Previous_gtids_log_event를 찾으면, 그 바이너리 로그로 시작한다. 이 방법은 효율적이고, 리플리카가 매우 많은 수의 바이너리 로그 파일만큼 소스에 뒤쳐져있을 경우에만 상당한 시간이 걸린다. 그리고 나서 소소는 그 바이너리 로그 파일과 현재의 것까지 후속 파일들로부터 트랜잭션을 읽고, 리플리카가 누락한 GTIDs를 가진 트랜잭션은 보내고, 리플리카가 보낸 GTID 셋에 있는 트랜잭션은 건너뛴다. 리플리카가 첫번째 누락된 트랜잭션을 받기까지의 소요 시간은 바이너리 로그 파일의 오프 셋에 달려 있다. 이러한 교환은 소스는 리플리카가 아직 받지 않았거나 커밋하지 않은 GTID의 트랜잭션반 보내도록 한다. 만약 리플리카가 다이아몬드 토폴로지와 같은 경우처럼 둘 이상의 소스로부터 트랜잭션을 수신하게 된다면, 오토 스킵(auto-skip) 기능은 그러한 트랜잭션이 두 번 적용되지 않도록 한다.

소스가 보내야하는 어떤 트랜잭션이 소스의 바이너리 로그로부터 퍼지(purge)되었거나, 또는 또 다른 방법으로 gtid_purged 시스템 변수에 GTIDs의 셋에 추가된 경우에, 소스는 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS 에러를 리플리카로 보내고, 리플리케이션은 시작되지 않는다. 누락되어버린 퍼지된 트랜잭션의 GTIDs는 식별되어, 소소의 에러 로그내의 경고 메시지 ER_FOUND_MISSING_GTIDS에 나열된다. 소소를 따라잡기 위해서 필요한 트랜잭션의 히스토리의 일부가 퍼지되었기 때문에, 리플리카는 이 에러로부터 자동으로 복구할 수 없다. MASTER_AUTO_POSITION 옵션을 활성화하지 않고 재연결하려는 시도는 리플리카에서 퍼지된 트랜잭션들의 손실로 끝날 뿐이다. 이러한 상황으로부터 복구하기 위한 올바른 접근법은 ER_FOUND_MISSING_GTIDS에 나열된 누락된 트랜잭션을 또 다른 소스로부터 복제하거나, 또는 좀 더 최신의 백업으로부터 만든 새로운 리플리카로 대체하는 것이다. 이러한 상황이 다시 발생하지 않도록 소스에서 바이너리 로그 만료 기간(binlog_expire_logs_seconds)을 수정하는 것을 고려해야 한다.

만약 트랜잭션을 교환하는 동안 리플리카가 GTID에 엤는 소스의 UUID로 받았거나 커밋한 트랜잭션이지만, 소스 그 자신은 그 트랜잭션들의 레코드들을 가지고 있지 않다는 것을 발견하게 된다면, 소스는 ER_SLAVE_HAS_MORE_GTIDS_THAN_MASTER 에러를 리플리카로 보내고, 리플리케이션은 시작되지 않는다. 이 상황은 sync_binlog=1을 설정하지 않은 소스가 전원 관련 장애나 OS 크래시 등을 겪고, 이미 커밋된 트랜잭션들을 손실했을 때, 그 트랜잭션들이 바이너리 로그에는 아직 동기화되지 못한 상태에서 리플리카까지는 이미 전송이 된 경우에 발생할 수 있다. 만약 소스가 재시작된 이후에 어떤 클라이언트가 소스에서 트랜잭션을 커밋한다면, 소스와 리플리카가 서로 갈라질 수가 있고, 이로 인해 소스와 리플리카가 서로 다른 트랜잭션에 대해서 같은 GTID를 사용하는 상황으로 이어질 수 있다. 이 상황으로부터 복구하기 위한 올바른 접근법은 소스와 리플리카가 서로 갈라졌는지 수동으로 체크하는 것이다. 현재 동일한 GTID가 서로 다른 트랜잭션에 대해서 사용되고 있다면, 개별 트랜잭션에 대해서 수동으로 충돌을 해결하거나, 또는 리플리케이션 토폴로지에서 소스나 리플리카를 제거해야 한다. 만약 이 이슈가 소스에서만 누락된 트랜잭션이 있는 것이라면, 대신 소스를 리플리카로 만들어 리플리케이션 토폴로지 내의 다른 서버를 따라잡도록 할 수 있고, 그 다음에 필요하다면 다시 소스로 만들 수도 있다.

다이아몬드 토폴로지(리플리카는 두 개 이상의 소스를 복제하고, 그 소스들이 다시 하나의 일반적인 소스로부터 복제하도록 하는)내의 멀티 소스(multi-source) 리플리카에 대해서 GTID-based 리플리케이션을 사용할 때, 어떤 리플리케이션 필터나 다른 채널 구성이 멀티 소스 리플리카의 모든 채널에세 동일하도록 해야한다. GTID-based 리플리케이션에서 필터는 트랜잭션 데이터에 대해서만 적용되고, GTIDs는 필터되지 않는다. 이것은 리플리카의 GTID 셋이 소스의 GTID 셋과 일관성을 유지하기 위해서 발생하며, 매번 필터된 트랜잭션을 재획득하지 않고 GTID 오토 포지셔닝(auto-positioning)이 사용할 수 있다는 것을 의미한다. 다운스트림 리플리카가 멀티 소스이고, 다이아몬드 토폴로지 내에서 여러 소스로부터 동일한 트랜잭션을 수신하는 경우에, 다운스트림 리플리카는 현재 트랜잭션의 여러 버전을 가지고, 그 결과는 어떤 채널이 트랜잭션을 먼저 적용하는지에 따라 다르다. 첫 번째 채널에 의해서 트랜잭션의 GTID가 gtid_executed 셋에 추가가 되었기 때문에, 트랜잭션을 적용하려고 시도하는 두 번째 채널은 GTID 오토 스킵(auto-sckip)을 이용해서 그 트랜잭션을 건너뛰게 된다. 채널에서 동일한 필터링은 문제가 없다. 왜냐하면 트랜잭션의 모든 버전이 동일한 데이터를 포함하고, 그래서 결과도 같기 때문이다. 하지만 채널에서 서로 다른 필터링을 사용하면, 데이터베이스는 부정합성이 발생할 수 있고, 리플리케이션은 중단될 수 있다.