7. Requirements and Limitations

1. Group Replication Requirements 

Group Replication에 사용할 서버 인스턴스는 다음의 요구 사항을 따라야 한다. 

1.1 구조 

1.1.1. InnoDB Storage Engine 

데이터는 InnoDB 스토리지 엔진으로 만든 테이블에 저장해야 한다. 트랜잭션으로 데이터가 저장되어야 충돌에 대한 검사를 할 수 있다. 만약, 트랜잭션 간의 충돌이 있는 경우 그룹 전체에 일관성을 유지하기 위해 일부 트랜잭션을 롤백하기도 한다. 그래서, 트랜잭션을 지원하는 스토리지 엔진을 사용하여 데이터를 저장해야 한다. 또한, InnoDB는 Group Replication에서 동작할 때 트랜잭션 충돌을 잘 처리할 수 있는 몇가지 기능을 제공한다. 

1.1.2 Primary Keys

Group Replication 구성 안에서 복제되는 모든 테이블은 PK를 명시적으로 정의하여 사용해야 한다. Primary Key는 각 트랜잭션이 수정한 행을 정확히 식별하여 트랜잭션의 충돌을 판별하는데 중요한 역할을 수행한다. 

1.1.3 IPv4 Network 

MySQL Group Replication에 사용되는 group communication engine은 IPv4만을 지원한다. 그래서 Group Replication을 구성하려는 서버들의 네트워크는 IPv4를 지원해야 한다. 

1.1.4 Network Performance 

Group Replication은 서버 인스턴스가 서로 밀접한 클러스터 환경에 배포되도록 설계되었으며, 네트워크 대기 시간과 네트워크 대역폭의 영향을 받는다. 

1.2 Server Instance 설정 

각 구성 서버별로 다음과 같이 구성되어야 한다. 

1.2.1 Binary Log 활성화 

MySQL Group Replication 은 바이너리 로그를 사용하여 데이터 동기화를 진행한다. 그래서 바이너리 로그를 활성화하여 사용하는 것이 필수이다. 

1.2.2 log-slave-updates 활성화 

각 서버는 Replication Applier를 통해 바이너리 로그를 적용한다. 그래서, 그룹안의 각 구성 서버들은 그룹안에서 행해지는 모든 트랜잭션을 전부 기록해야 한다. 이는 그룹의 각 서버의 바이너리 로그에 따라 복구가 수행되기 때문이다. 따라서, 서버 자체에서 시작되지 않은 트랜잭션의 경우에도 각 트랜잭션의 복사본이 모든 서버에 존재해야 한다. 

1.2.3 ROW Type Binary Log Format 

Group Replication은 그룹의 서버간에 일관되게 데이터의 변경내역을 전달하기 위해 ROW 방식의 바이너리 로그를 사용하는 것을 권장한다. ROW 기반의 구조에 따라 그룹 내의 다른 서버에서 동시에 실행되는 트랜잭션 간의 충돌을 감지하는데 필요한 정보를 추출할 수 있다. 

1.2.4 Global Transaction Identifiers 활성화 

Group Replication은 gtid_mode 시스템 변수값을 ON으로 해서 사용해야 한다. Group Replication은 GTID 값을 사용하여 모든 서버 인스턴스에서 커밋된 트랜잭션을 정확히 추적하여 정확하게 적용할 수 있게 진행한다. 다시말해 명시적인 트랜잭션 식별자는 충돌 할 수 있는 트랜잭션을 결정할 수 있는 프레임워크의 기본 부분이다. 

1.2.5 Replication Information Repository 

Replication과 관련된 정보는 테이블을 통해 관리해야 한다. 즉, master_info_repository와 relay_log_info_repository는 모두 TABLE값을 가지고 있어야 한다. 이렇게 설정해야지만, Group Replication안에 복제 메타 데이터의 일관된 복구 가능성과 트랜잭션 관리가 보장된다. 

1.2.6 Transaction Write Set Extraction

transaction_write_set_extraction 시스템 변수의 값은 XXHASH64 이어야 한다. 이렇게 설정함으로서, 바이너리 로그내의 Write Set에 추가 정보를 넣음으로서 이 정보를 통해 충돌 감지를 쉽게 할 수 있게 한다. 

2. Limitations 

Group Replication은 다음과 같은 제약사항이 있다. 

2.1 Replication Event Checksums

Group Replication에서는 CheckSum을 사용할 수 없다. binlog_checksum 시스템 변수의 값을 NONE으로 설정한다. 

2.2 Gap Locks

InnoDB 외부에서는 Gap Lock에 대한 정보를 얻을 수 없다. 그래서 인증 프로세스는 Gap Lock을 고려하지 않는다. 응용프로그램안에서 REPEATABLE READ를 사용해야 하는 요구사항이 있는 것이 아니라면 READ COMMITTED로 변경하는 것을 추천한다. READ COMMITTED에서는 Gap Lock을 사용하지 않기 때문에 좀 더 높은 동시성을 보장할 수 있다. 

2.3 Table Locks and Named Locks

Group Replication안의 인증 프로세스는 테이블 락이나 Named Lock을 고려하지 않는다. 

2.4 Savepoints Not Supported

Transaction에서 사용하는 SavePoint는 지원하지 않는다. 

2.5 SERIALIZABLE Isolation Level 

SERIALIZABLE Isolation Level은 지원하지 않는다. 

2.6 Concurrent DDL versus DML Operations 

Multi-Pirmary Mode에서 다른 서버에서 DDL문과 DML문이 동시에 실행되는 것을 지원하지 않는다. 각각 다른 서버에서 DDL과 DML이 동시에 실행되는 경우 충돌을 감지하지 못할 가능성이 있다. 

2.7 Foreign Keys with Cascading Constraints

group_replication_single_primary_mode 변수가 OFF로 구성된 Multi-Primary 모드 그룹에서는 FK 특히 CASCADE 설정이 있는 FK를 지원하지 않는다. FK 설정된 데이터까지 추가해서 충돌감지를 하지 않기 때문에 데이터의 일관성이 깨질 가능성이 높다. 이런 경우에는 감지되지 않는 충돌을 막기 위해 group_replication_enforce_update_everywhere_checks=ON을 설정하는 것이 좋다. 

단일 기본 모드에서는 그룹의 여러 구성원이 동시에 쓰기 작업을 진행하지 않으므로 데이터 충돌과 관련된 문제는 발생하지 않는다.