Loading...
MySQL 9.5 Reference Manual 9.5의 20.4.1 GTIDs and Group Replication의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
Group Replication은 GTID(global transaction identifier)를 사용하여
각 서버 인스턴스에서 어떤 트랜잭션이 커밋되었는지를 정확하게
추적합니다. 설정
gtid_mode=ON과
enforce_gtid_consistency=ON는
모든 그룹 멤버에서 필요합니다. 클라이언트로부터 들어오는 트랜잭션은
이를 수신한 그룹 멤버에 의해 GTID가 할당됩니다. 그룹 외부의
소스 서버로부터 비동기 복제 채널을 통해 그룹 멤버에
전송되는 복제된 트랜잭션은, 그룹 멤버에 도달할 때 가지고 있는
GTID를 그대로 유지합니다.
클라이언트로부터 들어오는 트랜잭션에 할당되는 GTID는,
identifier의 UUID 부분으로 개별 그룹 멤버의 서버 UUID가 아니라,
group_replication_group_name
시스템 변수에 의해 지정되는 그룹 이름을 사용합니다. 따라서
그룹이 직접 수신한 모든 트랜잭션은 식별할 수 있고 GTID 집합으로
묶을 수 있으며, 어떤 멤버가 처음으로 그것을 수신했는지는 중요하지
않습니다. 각 그룹 멤버는 자신의 사용을 위해 연속된 GTID 블록을
예약하고, 이들이 소진되면 더 많은 블록을 예약합니다.
group_replication_gtid_assignment_block_size
시스템 변수는 블록의 크기를 설정하며, 기본값은 각 블록당
100만 개의 GTID입니다.
새로운 멤버가 조인될 때 그룹 자체에 의해 생성되는
뷰 변경 이벤트(View_change_log_event)는, 바이너리 로그에 기록될 때
GTID가 부여됩니다. 기본적으로, 이러한 이벤트에 대한 GTID 역시
identifier의 UUID 부분으로
group_replication_group_name
시스템 변수에 의해 지정되는 그룹 이름을 사용합니다. Group Replication
시스템 변수
group_replication_view_change_uuid를
설정하여 뷰 변경 이벤트의 GTID에 대체 UUID를 사용하도록 할 수 있으므로,
이들을 그룹이 클라이언트로부터 수신한 트랜잭션과 쉽게 구분할 수 있습니다.
이는 설정에서 그룹 간 페일오버를 허용하고, 백업 그룹에만 해당하는
트랜잭션을 식별하여 폐기해야 할 필요가 있을 때 유용할 수 있습니다.
대체 UUID는 멤버들의 서버 UUID와 달라야 합니다. 또한,
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS 옵션을 사용하여
익명 트랜잭션에 적용된 GTID의 UUID와도 달라야 합니다.
이 옵션은 CHANGE REPLICATION SOURCE TO 구문에서 사용됩니다.
GTID_ONLY=1, REQUIRE_ROW_FORMAT = 1, SOURCE_AUTO_POSITION = 1은
Group Replication 채널인
group_replication_applier와
group_replication_recovery에 대해 적용됩니다. 이 설정들은
Group Replication 채널이 생성될 때나 복제 그룹의 멤버
서버가 업그레이드될 때 자동으로 Group Replication 채널에 설정됩니다.
이 옵션들은 일반적으로
CHANGE REPLICATION SOURCE TO
구문을 사용하여 설정되지만, Group Replication 채널에 대해서는
이를 비활성화할 수 없다는 점에 유의하십시오. 이러한 옵션이 설정되면,
그룹 멤버는 해당 채널에 대한 복제 메타데이터 저장소에
파일 이름과 파일 위치를 영구 저장하지 않습니다. 필요한 경우
올바른 리시버와 어플라이어 위치를 찾기 위해 GTID 자동 위치 지정과
GTID 자동 스킵이 사용됩니다.
조인하는 멤버의 GTID 집합에 그룹의 기존 멤버에는 존재하지 않는 트랜잭션이 있는 경우, 해당 멤버는 분산 복구 프로세스를 완료할 수 없으며 그룹에 조인할 수 없습니다. 원격 클로닝 작업이 수행되었다면, 조인하는 멤버의 데이터 디렉터리가 삭제되기 때문에 이러한 트랜잭션은 삭제되고 손실됩니다. 도너의 바이너리 로그에서 상태 전송이 수행되었다면, 이러한 트랜잭션은 그룹의 트랜잭션과 충돌할 수 있습니다.
Extra 트랜잭션은 Group Replication이 중지된 동안 인스턴스에서
관리용 트랜잭션이 수행된 경우 멤버에 존재할 수 있습니다.
이런 방식으로 새로운 트랜잭션이 도입되는 것을 피하려면,
항상 관리용 구문을 실행하기 전에
sql_log_bin 시스템 변수의 값을
OFF로 설정하고,
이후에 다시 ON으로 되돌리십시오:
1SET SQL_LOG_BIN=0; 2<administrator action> 3SET SQL_LOG_BIN=1;
이 시스템 변수를 OFF로 설정하면,
그 시점부터 다시 ON으로 설정할 때까지 발생하는 트랜잭션은
바이너리 로그에 기록되지 않으며 GTID도 할당되지 않습니다.
조인하는 멤버에 extra 트랜잭션이 있는 경우, 해당 extra 트랜잭션에 실제로 어떤 내용이 있는지 확인하기 위해 영향을 받은 서버의 바이너리 로그를 확인하십시오. 조인하는 멤버의 데이터 및 GTID 집합을 현재 그룹의 멤버와 조정하는 가장 안전한 방법은 MySQL의 클로닝 기능을 사용하여 그룹에 있는 서버의 내용을 영향을 받은 서버로 전송하는 것입니다. 이를 수행하는 방법에 대한 지침은 Section 7.6.6.3, “Cloning Remote Data”를 참조하십시오. 해당 트랜잭션이 필요한 경우, 멤버가 성공적으로 다시 조인한 후에 이를 다시 실행하십시오.
20.4 Monitoring Group Replication
20.4.2 Group Replication Server States