MySQL 8.4 LTS Group Replication에서 split-brain이 발생합니다

8.4에서 Group Replication 기본 동작이 의도적으로 바뀌었습니다 — 데이터 안전 우선에서 가용성 우선으로 일부 기본값이 이동했고, 이걸 그대로 두면 보고하신 split-brain이 발생합니다.

핵심 변경

설정8.0 기본8.4 기본의미group_replication_consistencyEVENTUALBEFORE_ON_PRIMARY_FAILOVER일부 일관성 강화group_replication_unreachable_majority_timeout0 (영구 대기)0 (영구 대기)변동 없음group_replication_member_expel_timeout530관용 시간 6배 증가group_replication_autorejoin_tries310재합류 시도 강화

관용 시간이 늘어난 것이 split-brain 노출 시간을 길게 만든 주범입니다.

진단 — 현재 상태 확인

-- 모든 노드에서
SELECT * FROM performance_schema.replication_group_members;

-- 노드별로 본 그룹 멤버가 다르면 이미 split 상태
SELECT @@group_replication_group_seeds;

처방 1) 안전 기본값 복원

SET PERSIST group_replication_unreachable_majority_timeout = 5;
SET PERSIST group_replication_member_expel_timeout = 5;
SET PERSIST group_replication_consistency = 'BEFORE_ON_PRIMARY_FAILOVER';

-- 영구 적용 위해 GR 재시작
STOP GROUP_REPLICATION;
START GROUP_REPLICATION;

처방 2) 다수파에 대한 명시적 강제

3노드 환경에서 minority(1노드)가 살아남는 것을 방지하려면:

-- minority 측에서 자동 SUPER_READ_ONLY로 떨어지게
SET PERSIST group_replication_unreachable_majority_timeout = 5;
-- 5초 동안 majority와 통신 못 하면 자동 read-only

처방 3) 자동 재합류 활성화

SET PERSIST group_replication_autorejoin_tries = 5;
-- exit 후 자동으로 5번까지 재합류 시도
-- 실패 시 super_read_only=ON으로 안전 정지

운영 체크리스트

1. 3노드 → 5노드로 확장 권장 (3노드는 minority 발생 시 운영 정지 필연)
2. 네트워크는 별도 VLAN — application 트래픽과 GR 통신 분리
3. 모든 노드 동일 가용영역에 두지 말기 (하나의 AZ 장애 = majority 상실)
4. SET GLOBAL super_read_only=ON 자동화 — application은 read-only 노드로 fallback
5. 주기적 fault injection — chaos test로 split-brain 시나리오 검증

대안 — InnoDB Cluster + MySQL Router

Group Replication 직접 운영 부담이 크면 InnoDB Cluster로 묶고 MySQL Router를 앞단에 두는 구조가 더 안정적입니다. Router가 자동으로 read/write 분리·failover를 처리합니다.

마지막 한 줄

8.4 Group Replication은 "수동 개입을 줄이는 방향"으로 기본값이 바뀐 결과 split-brain 가능성이 약간 늘었습니다. 데이터 무결성이 우선이라면 timeout 값을 5초 이하로 명시 설정하세요.