Loading...
MySQL 9.5 Reference Manual 9.5의 20.3.1 Group Replication Requirements의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
Group Replication에 사용하려는 서버 인스턴스는 다음 요구 사항을 충족해야 합니다.
데이터는 InnoDB 트랜잭션 스토리지 엔진에 저장되어야 합니다. 트랜잭션은 낙관적으로 실행된 다음 커밋 시점에 충돌 여부가 검사됩니다. 충돌이 있는 경우, 그룹 전체의 일관성을 유지하기 위해 일부 트랜잭션이 롤백됩니다. 이는 트랜잭션 스토리지 엔진이 필요함을 의미합니다. 또한 InnoDB는 Group Replication과 함께 동작할 때 충돌을 더 잘 관리하고 처리할 수 있도록 추가 기능을 제공합니다. 임시 MEMORY 스토리지 엔진을 포함한 다른 스토리지 엔진을 사용하면 Group Replication에서 오류가 발생할 수 있습니다. 다른 스토리지 엔진을 사용하는 모든 테이블은 Group Replication과 함께 인스턴스를 사용하기 전에 InnoDB를 사용하도록 변환해야 합니다. 그룹 멤버에서 disabled_storage_engines 시스템 변수를 설정하여 다른 스토리지 엔진의 사용을 방지할 수 있습니다. 예를 들면 다음과 같습니다:
1disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
그룹에서 복제 대상이 되는 모든 테이블에는 정의된 프라이머리 키 또는 non-null 유니크 키인 프라이머리 키와 동등한 키가 있어야 합니다. 이러한 키는 테이블 내의 모든 행에 대해 고유한 식별자로 필요하며, 시스템이 각 트랜잭션이 수정한 행을 정확히 식별하여 어떤 트랜잭션이 충돌을 일으키는지 판단할 수 있도록 합니다. Group Replication에는 프라이머리 키 또는 프라이머리 키와 동등한 키에 대한 자체 내장 검사 세트가 있으며, sql_require_primary_key 시스템 변수가 수행하는 검사는 사용하지 않습니다. Group Replication이 실행 중인 서버 인스턴스에 대해 sql_require_primary_key=ON을 설정할 수 있으며, Group Replication 채널에 대해 CHANGE REPLICATION SOURCE TO 문장의 REQUIRE_TABLE_PRIMARY_KEY_CHECK 옵션을 ON으로 설정할 수 있습니다. 그러나 Group Replication의 내장 검사에서는 허용되지만 sql_require_primary_key=ON 또는 REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON을 설정했을 때 수행되는 검사에서는 허용되지 않는 트랜잭션이 있을 수 있음을 유의해야 합니다.
MySQL Group Replication은 서버 인스턴스들이 서로 매우 가까이 있는 클러스터 환경에서 배포되도록 설계되었습니다. 그룹의 성능과 안정성은 네트워크 지연 시간과 네트워크 대역폭 모두의 영향을 받을 수 있습니다. 모든 그룹 멤버 간에는 항상 양방향 통신이 유지되어야 합니다. 인바운드 또는 아웃바운드 통신 중 하나라도 서버 인스턴스에 대해 차단되는 경우(예: 방화벽에 의해 또는 연결 문제로 인해), 해당 멤버는 그룹에서 기능을 수행할 수 없으며, 그룹 멤버(문제가 있는 멤버 포함)는 영향을 받는 서버 인스턴스에 대한 올바른 멤버 상태를 보고하지 못할 수 있습니다.
원격 Group Replication 서버 간의 TCP 통신을 위해 IPv4, IPv6 또는 이 둘의 혼합에 기반한 네트워크 인프라를 사용할 수 있습니다. 또한 가상 사설망(VPN)을 통해 Group Replication이 동작하는 것을 방해하는 요소는 없습니다.
Group Replication 서버 인스턴스가 동일 위치에 있고 로컬 그룹 통신 엔진(XCom) 인스턴스를 공유하는 경우, 가능한 경우 TCP 소켓 대신 오버헤드가 더 낮은 전용 입력 채널이 통신에 사용됩니다. 그룹에 조인하는 것과 같이 원격 XCom 인스턴스 간 통신이 필요한 특정 Group Replication 작업의 경우에는 여전히 TCP 네트워크가 사용되므로, 네트워크 성능은 그룹의 성능에 영향을 미칩니다.
그룹의 멤버인 서버 인스턴스에서는 다음 옵션들이 아래와 같이 설정되어야 합니다.
server_id 시스템 변수를 사용하여 복제 토폴로지의 모든 서버에 요구되는 대로 서버에 고유한 서버 ID를 설정합니다. 서버 ID는 1과 (232)−1 사이의 양의 정수여야 하며, 복제 토폴로지에서 사용 중인 다른 모든 서버 ID와 서로 달라야 합니다.
MySQL 9.5에서는 바이너리 로깅이 기본적으로 활성화되어 있습니다. 선택적으로 --log-bin[=log_file_name]을 사용하여 바이너리 로그 파일의 이름을 지정할 수 있습니다. Group Replication은 바이너리 로그의 내용을 복제하므로, 이를 동작시키기 위해서는 바이너리 로그가 켜져 있어야 합니다. Section 7.4.4, “The Binary Log”를 참조하십시오.
이미 활성화되어 있지 않다면 log_replica_updates=ON을 설정합니다.(MySQL 9.5에서는 이것이 기본값입니다.) 그룹 멤버는 조인 시 donor로부터 수신하여 복제 적용기(applier)를 통해 적용한 트랜잭션과, 그룹으로부터 수신하고 적용한 모든 트랜잭션을 로그해야 합니다. 이는 Group Replication이 기존 그룹 멤버의 바이너리 로그에서 상태 전송을 통해 분산 복구를 수행할 수 있도록 합니다.
필요하다면 binlog_format=ROW를 설정합니다. MySQL 9.5에서는 이것이 기본값입니다. Group Replication은 행 기반 복제 포맷에 의존하여 그룹 내 서버 간에 변경 사항을 일관되게 전파하고, 그룹 내 다른 서버에서 동시에 실행되는 트랜잭션 간의 충돌을 감지하는 데 필요한 정보를 추출합니다. REQUIRE_ROW_FORMAT 설정은 트랜잭션이 적용될 때 행 기반 복제의 사용을 강제하기 위해 Group Replication의 채널에 자동으로 추가됩니다. Section 19.2.1, “Replication Formats” 및 Section 19.3.3, “Replication Privilege Checks”를 참조하십시오.
gtid_mode=ON과 enforce_gtid_consistency=ON을 설정합니다. 이 설정은 기본값이 아닙니다. GTID 기반 복제는 Group Replication에 필요하며, Group Replication은 글로벌 트랜잭션 식별자를 사용하여 그룹 내 각 서버 인스턴스에서 커밋된 트랜잭션을 추적합니다. Section 19.1.3, “Replication with Global Transaction Identifiers”를 참조하십시오.
또한 gtid_purged의 값을 설정해야 하는 경우, Group Replication이 실행 중이지 않을 때 설정해야 합니다.
default_table_encryption을 모든 그룹 멤버에서 동일한 값으로 설정합니다. 기본 스키마 및 테이블스페이스 암호화는 모든 멤버에서 설정이 동일한 한, (ON)으로 활성화하거나 (OFF, 기본값) 비활성화할 수 있습니다.
default_table_encryption의 값은 Group Replication이 실행 중일 때는 변경할 수 없습니다.
lower_case_table_names를 모든 그룹 멤버에서 동일한 값으로 설정합니다. 이 설정 값 1은 Group Replication에 필요로 되는 InnoDB 스토리지 엔진을 사용하는 데 적합합니다. 이 설정은 모든 플랫폼에서 기본값이 아니라는 점에 유의하십시오.
Group Replication 멤버는 멀티스레드 복제본으로 구성할 수 있으며, 이를 통해 트랜잭션을 병렬로 적용할 수 있습니다. 모든 복제본은 기본적으로 멀티스레드로 구성되어 있습니다. 기본값은 4개의 병렬 적용기 스레드이며, 최대 1024개의 병렬 적용기 스레드를 지정할 수 있습니다. 멀티스레드 복제본의 경우 다음 설정 또한 필요합니다:
replica_preserve_commit_order=ON
이 설정은 병렬 트랜잭션의 최종 커밋 순서가 원래 트랜잭션 순서와 동일하도록 보장하는 데 필요합니다. Group Replication은 모든 참여 멤버가 커밋된 트랜잭션을 동일한 순서로 수신하고 적용한다는 보장에 기반한 일관성 메커니즘에 의존합니다.
MySQL 9.5 이상은 분리(detached)된 XA 트랜잭션을 지원합니다. 분리된 트랜잭션은 한 번 prepare되면 더 이상 현재 세션에 연결되어 있지 않은 트랜잭션입니다. 이는 XA PREPARE를 실행하는 과정에서 자동으로 발생합니다. prepare된 XA 트랜잭션은 다른 커넥션에 의해 커밋되거나 롤백될 수 있으며, 현재 세션은 방금 prepare된 트랜잭션이 완료되기를 기다리지 않고 또 다른 XA 트랜잭션이나 로컬 트랜잭션을 시작할 수 있습니다.
분리된 XA 트랜잭션 지원이 활성화되어 있을 때(xa_detach_on_prepare = ON), 이 서버에 대한 임의의 커넥션이(XA RECOVER를 사용하여) 모든 prepare된 XA 트랜잭션을 나열, 롤백 또는 커밋할 수 있습니다. 또한 분리된 XA 트랜잭션 내에서는 임시 테이블을 사용할 수 없습니다.
xa_detach_on_prepare를 OFF로 설정하여 분리된 XA 트랜잭션 지원을 비활성화할 수 있지만, 이는 권장되지 않습니다. 특히 이 서버를 MySQL Group Replication의 인스턴스로 설정하는 경우, 이 변수는 기본값(ON)으로 유지해야 합니다.
자세한 내용은 Section 15.3.8.2, “XA Transaction States”를 참조하십시오.
20.3 Requirements and Limitations
20.3.2 Group Replication Limitations
