Loading...
MySQL 9.5 Reference Manual 9.5의 20.3.2 Group Replication Limitations의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
다음과 같은 Group Replication에 대한 알려진 제약 사항들이 존재합니다. 멀티프라이머리 모드 그룹에 대해 설명된 제약 사항과 이슈들은, 새로 선출된 프라이머리가 이전 프라이머리로부터 applier 큐를 비워 내리는 장애 조치 이벤트 동안 싱글프라이머리 모드 클러스터에도 적용될 수 있습니다.
참고
Group Replication은 GTID 기반 복제를 기반으로 구축되었으므로, Section 19.1.3.7, “Restrictions on Replication with GTIDs”에 설명된 내용도 숙지해야 합니다.
--upgrade=MINIMAL option.MINIMAL option (--upgrade=MINIMAL)을 사용하여 MySQL Server를 업그레이드한 후에는 Group Replication을 시작할 수 없습니다. 이 option은 복제 내부 동작이 의존하는 시스템 테이블을 업그레이드하지 않습니다.
Group Replication의 동시 트랜잭션에 대한 인증 프로세스는 gap locks를 고려하지 않습니다. gap lock에 대한 정보는 InnoDB 외부에서는 사용할 수 없기 때문입니다. 자세한 내용은 Gap Locks를 참조하십시오.
참고
멀티프라이머리 모드 그룹의 경우, 애플리케이션에서 REPEATABLE READ 시맨틱에 의존하지 않는 한, Group Replication과 함께 READ COMMITTED 격리 수준을 사용할 것을 권장합니다. InnoDB는 READ COMMITTED에서 gap lock을 사용하지 않으며, 이는 InnoDB 내의 로컬 충돌 감지를 Group Replication이 수행하는 분산 충돌 감지와 일치시키는 효과가 있습니다.
싱글프라이머리 모드 그룹의 경우에는 프라이머리만 쓰기를 허용하므로, READ COMMITTED 격리 수준은 Group Replication에 대해 중요하지 않습니다.
인증 프로세스는 테이블 락(참조: Section 15.3.6, “LOCK TABLES and UNLOCK TABLES Statements”)이나 네임드 락(참조: GET_LOCK())을 고려하지 않습니다.
MySQL 9.5의 Group Replication은 체크섬을 지원하므로, 그룹 멤버는 기본 설정인 binlog_checksum=CRC32를 사용할 수 있습니다. binlog_checksum 설정은 그룹의 모든 멤버에 대해 동일할 필요는 없습니다.
체크섬을 사용할 수 있는 경우에도, Group Replication은 group_replication_applier 채널에서 수신 이벤트를 검증하기 위해 체크섬을 사용하지 않습니다. 이벤트는 여러 소스로부터 해당 릴레이 로그에 기록되며, 실제로 원본 서버의 바이너리 로그에 기록되기 전에 기록되는데, 체크섬은 이 시점에 생성되기 때문입니다. 체크섬은 group_replication_recovery 채널 및 그룹 멤버의 기타 복제 채널에서 이벤트의 무결성을 검증하는 데 사용됩니다.
SERIALIZABLE 격리 수준은 기본적으로 멀티프라이머리 그룹에서는 지원되지 않습니다. 트랜잭션 격리 수준을 SERIALIZABLE로 설정하면, Group Replication은 해당 트랜잭션의 커밋을 거부하도록 동작합니다.
같은 오브젝트에 대해, 다른 서버에서 실행되는 동시 DDL과 DML 문장은 멀티프라이머리 모드를 사용할 때 지원되지 않습니다. 특정 오브젝트에 대해 DDL(Data Definition Language) 문장이 실행되는 동안, 동일한 오브젝트에 대해 다른 서버 인스턴스에서 동시 DML(Data Manipulation Language)을 실행하면, 서로 다른 인스턴스에서 실행되는 충돌하는 DDL이 감지되지 못할 위험이 있습니다.
멀티프라이머리 모드 그룹(모든 멤버가 group_replication_single_primary_mode=OFF로 설정된 경우)은 다단계 외래 키 종속성, 특히 CASCADING foreign key constraints가 정의된 테이블을 지원하지 않습니다. 이는 외래 키 제약 조건으로 인해 멀티프라이머리 모드 그룹에서 실행되는 캐스케이딩 연산이 감지되지 않은 충돌을 유발하고, 그룹 멤버 간의 데이터 불일치를 초래할 수 있기 때문입니다.
따라서 멀티프라이머리 모드 그룹에서 사용되는 서버 인스턴스에 대해서는 감지되지 않은 충돌을 피하기 위해 group_replication_enforce_update_everywhere_checks=ON를 설정할 것을 권장합니다.
싱글프라이머리 모드에서는 그룹의 여러 멤버에 대해 동시 쓰기를 허용하지 않으므로, 감지되지 않은 충돌의 위험이 없어 이 문제가 발생하지 않습니다.
그룹이 멀티프라이머리 모드로 동작할 때, SELECT .. FOR UPDATE 문장은 데드락을 유발할 수 있습니다. 이는 락이 그룹 멤버 간에 공유되지 않기 때문에, 이러한 문장에 대한 기대하는 동작이 충족되지 못할 수 있기 때문입니다.
Group Replication으로 설정된 MySQL 서버 인스턴스에서는 글로벌 복제 필터를 사용할 수 없습니다. 일부 서버에서 트랜잭션을 필터링하면, 그룹이 일관된 상태에 대해 합의를 이룰 수 없게 되기 때문입니다. 채널별 복제 필터는 Group Replication에 직접 관여하지 않는 복제 채널에서 사용할 수 있습니다. 예를 들어, 그룹 멤버가 그룹 외부의 소스에 대한 레플리카로도 동작하는 경우가 이에 해당합니다. 이러한 필터는 group_replication_applier나 group_replication_recovery 채널에서는 사용할 수 없습니다.
TLSv1.3 프로토콜에 대한 지원은 MySQL이 OpenSSL 1.1.1 이상을 사용하여 컴파일된 경우에 사용할 수 있습니다. Group Replication은 TLSv1.3을 지원하며, 그룹 통신 연결과 분산 복구 연결에 사용할 수 있습니다.
group_replication_recovery_tls_version과 group_replication_recovery_tls_ciphersuites는, 원하는 경우 기본값이 아닌 사이퍼 슈트만 포함하는 등, 선택한 사이퍼 슈트 집합에 대해 클라이언트 지원을 구성하는 데 사용할 수 있습니다. 자세한 내용은 Section 8.3.2, “Encrypted Connection TLS Protocols and Ciphers”를 참조하십시오.
Group Replication은 분산 복구를 위해 클로닝 연산을 시작하고 관리하지만, 클로닝을 지원하도록 설정된 그룹 멤버는 사용자가 수동으로 시작한 클로닝 연산에도 참여할 수 있습니다. Group Replication이 동작 중인 그룹 멤버가 대상인 클로닝 연산의 경우, 해당 연산이 대상의 데이터를 제거하고 교체하지 않는다면 수동으로 클로닝 연산을 시작할 수 있습니다.
따라서 Group Replication이 동작 중인 경우 클로닝 연산을 시작하는 문장에는 반드시 DATA DIRECTORY 절이 포함되어야 합니다. 자세한 내용은 Section 20.5.4.2.4, “Cloning for Other Purposes”를 참조하십시오.
단일 복제 그룹의 멤버가 될 수 있는 MySQL 서버의 최대 개수는 9개입니다. 추가 멤버가 그룹에 조인을 시도하면 해당 요청은 거부됩니다. 이 한계는 안정적인 로컬 영역 네트워크 환경에서 그룹이 신뢰성 있게 동작하는 안전한 경계값으로, 테스트와 벤치마킹을 통해 도출되었습니다.
개별 트랜잭션으로 인해 메시지 내용이 너무 커져서, 해당 메시지를 그룹 멤버 간에 네트워크를 통해 5초 이내에 복사할 수 없는 경우, 멤버는 실패한 것으로 의심되고, 단지 트랜잭션을 처리하는 중이었을 뿐인데도 그룹에서 제거될 수 있습니다. 대형 트랜잭션은 또한 메모리 할당 문제로 인해 시스템을 느리게 만들 수 있습니다.
이러한 문제를 피하기 위해 다음과 같은 완화 방안을 사용하십시오:
대형 메시지로 인해 불필요한 추방이 발생하는 경우, 시스템 변수 group_replication_member_expel_timeout을 사용하여, 실패한 것으로 의심되는 멤버가 그룹에서 제거되기 전까지의 시간을 추가로 허용하십시오. 초기 5초 감지 기간 이후 최대 1시간까지 허용할 수 있습니다. 기본적으로는 추가 5초가 허용됩니다.
가능한 경우, Group Replication에서 처리하기 전에 트랜잭션의 크기를 제한하도록 하십시오. 예를 들어, LOAD DATA에 사용되는 파일을 더 작은 조각으로 분할하십시오.
시스템 변수 group_replication_transaction_size_limit을 사용하여 그룹이 허용하는 최대 트랜잭션 크기를 지정하십시오. 기본 최대 트랜잭션 크기는 150000000 바이트(약 143 MB)이며, 이보다 큰 트랜잭션은 롤백되고 Group Replication의 Group Communication System(GCS)에 그룹으로의 배포를 위해 전송되지 않습니다. 그룹이 허용해야 하는 최대 메시지 크기에 따라 이 변수 값을 조정하되, 트랜잭션을 처리하는 데 걸리는 시간이 그 크기에 비례한다는 점을 염두에 두십시오.
시스템 변수 group_replication_compression_threshold을 사용하여 압축이 적용되는 메시지 크기를 지정하십시오. 이 시스템 변수의 기본값은 1000000 바이트(1 MB)이므로, 대형 메시지는 자동으로 압축됩니다. 압축은 Group Replication의 Group Communication System(GCS)이 group_replication_transaction_size_limit 설정에 의해 허용되었지만 group_replication_compression_threshold 설정을 초과하는 메시지를 수신했을 때 수행됩니다. 자세한 내용은 Section 20.7.4, “Message Compression”을 참조하십시오.
시스템 변수 group_replication_communication_max_message_size을 사용하여, 메시지가 분할되는 기준이 되는 최대 메시지 크기를 지정하십시오. 이 시스템 변수의 기본값은 10485760 바이트(10 MiB)이므로, 대형 메시지는 자동으로 분할됩니다. GCS는 압축된 메시지가 여전히 group_replication_communication_max_message_size 한계를 초과하는 경우, 압축 이후에 분할을 수행합니다. 자세한 내용은 Section 20.7.5, “Message Fragmentation”을 참조하십시오.
maximum 트랜잭션 크기, 메시지 압축 및 메시지 분할은 관련 시스템 변수에 0 값을 지정하여 모두 비활성화할 수 있습니다. 이러한 보호 장치를 모두 비활성화한 경우, 복제 그룹의 멤버에서 applier 스레드가 처리할 수 있는 메시지의 상한 크기는 해당 멤버의 replica_max_allowed_packet 시스템 변수 값입니다. 이 변수의 기본값 및 최대값은 1073741824 바이트(1 GB)입니다. 이 한계를 초과하는 메시지는 수신 멤버가 이를 처리하려고 시도할 때 실패합니다.
그룹 멤버가 생성하여 그룹으로 전송을 시도할 수 있는 메시지의 상한 크기는 4294967295 바이트(약 4 GB)입니다. 이는 Group Replication을 위한 그룹 통신 엔진(XCom, Paxos 변형)이 허용하는 패킷 크기에 대한 하드 리미트이며, GCS가 메시지를 처리한 후에 메시지를 수신합니다. 이 한계를 초과하는 메시지는, 원본 멤버가 이를 브로드캐스트하려고 시도할 때 실패합니다.
20.3.1 Group Replication Requirements
20.4 Monitoring Group Replication