MySQL InnoDB Cluster 일상 운영 및 장애 시나리오 (MySQL Shell 8.4)

설치 가이드가 아닙니다: 이미 운영 중인 InnoDB Cluster(Group Replication + MySQL Router, MySQL Shell AdminAPI로 구성)의 일상 운영과 장애 복구를 위한 시나리오별 runbook입니다. 시나리오 카드를 선택하십시오: 상태 점검, 멤버 추가(clone / incremental)와 제거(force 포함), 장애 멤버 재합류, 클러스터 전체가 내려간 뒤 재시작(rebootClusterFromCompleteOutage), 과반 상실 시 forceQuorumUsingPartitionOf, 계획된 primary 전환, Router 추가 / 재 bootstrap, 클러스터 옵션(consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction), 메타데이터용 rescan(). 모든 시나리오는 진단 → 안전장치 → 실행 → 검증 → 후속 조치 순서를 따릅니다. 클러스터를 처음 구축한다면 InnoDB Cluster 설치 가이드를, 기존 source–replica 복제는 복제 운영 가이드를, 8.0 → 8.4 전환은 업그레이드 가이드를 여십시오.

구성: MySQL node 3–9대(single-primary) + MySQL Router

시나리오

• 클러스터 상태 및 헬스 체크(모두 정상인가?) — 읽기 전용: cluster.status({extended: 1}), 멤버의 역할/상태/버전, applier 큐, Router 목록, error log를 확인합니다. 아무것도 변경하지 않으며 중단도 없습니다. 확실하지 않거나 알림이 왔다면 여기서 시작하십시오. 마지막 단계에서 알맞은 시나리오로 안내합니다.
• 새 멤버 추가(addInstance: clone / incremental) — 클러스터에 새 MySQL node를 추가하거나, 장애 허용 수준을 높이거나(3 → 5), 제거했던 node를 다시 넣으려는 경우입니다. 클러스터는 계속 쓰기 가능합니다. clone 중에는 donor에 디스크/네트워크 부하가 생기고 새 node가 재시작됩니다.
• 멤버 제거(removeInstance, 필요 시 force) — node를 클러스터에서 영구히 제거하려는 경우(하드웨어 반납, 축소)이거나, node를 잃어 메타데이터에서 삭제해야 하는 경우(force)입니다. Secondary 제거 시에는 중단이 없고, primary를 제거하면 몇 초간 쓰기가 중단됩니다.
• 장애 멤버 재합류(MISSING / ERROR / OFFLINE) — 멤버가 재시작되었거나, 네트워크가 끊겼거나, 그룹에서 추방(expelled)되었습니다. 과반은 동작 중이고 애플리케이션은 쓸 수 있습니다. rejoinInstance로 멤버가 누락분을 받아 복귀합니다. 클러스터 중단은 없습니다.
• 클러스터 전체 다운: 재시작(rebootClusterFromCompleteOutage) — 정전 / 데이터센터 / 하이퍼바이저 장애 등으로 모든 node가 내려갔다가 다시 올라왔습니다. 어느 멤버에서도 Group Replication이 동작하지 않고 애플리케이션은 쓸 수 없습니다(중단 진행 중). 가장 최신 멤버에서 클러스터를 재시작합니다.
• 과반 상실(NO_QUORUM): 남은 멤버로 quorum 강제 구성 — 멤버 대부분이 동시에 사라졌고(예: 3대 중 2대) 남은 멤버는 NO_QUORUM으로 쓰기를 멈췄습니다(쓰기가 멈춘 채 대기). 사라진 멤버가 실제로 내려가 있음이 확실하다면 남은 파티션으로 클러스터를 다시 가동합니다. 잘못 사용하면 split-brain이 발생합니다. 멤버 하나만 잃은 경우(과반 유지)는 이 시나리오가 아닙니다.
• 계획된 primary 전환(setPrimaryInstance) — 유지 보수(OS 패치, 하드웨어), 부하 분산, DR 훈련을 위해 primary 역할을 특정 secondary로 계획적으로 넘기려는 경우입니다. 쓰기가 몇 초간 대기하고 열린 트랜잭션은 완료되며, Router가 새 primary로 자동으로 라우팅합니다.
• Router 추가 또는 재 bootstrap — 새 애플리케이션 서버에 Router를 설치하거나, Router를 재 bootstrap하거나(버전 업그레이드, 클러스터 재구축, routerErrors 경고), 오래된 Router 항목을 정리하려는 경우입니다. 재 bootstrap 중에는 해당 Router를 거치는 애플리케이션 연결이 잠시 끊깁니다.
• 클러스터 옵션 변경(consistency, expelTimeout, memberWeight…) — Failover 일관성, 네트워크 불안정 시 멤버 추방까지의 시간, failover 우선순위, 자동 재합류, 오류 시 멤버 동작을 조정하려는 경우입니다. 클러스터 운영 중에 변경하며 재시작이 필요 없습니다. consistency는 새 세션부터 적용됩니다.
• 메타데이터를 실제 그룹과 동기화(rescan) — cluster.status()가 메타데이터에 없는 멤버나 더 이상 그룹에 없는 오래된 항목을 표시합니다(START GROUP_REPLICATION을 수동 실행했거나, 이전 멤버를 제거하지 않았거나, 서버를 재구축한 경우). 중단은 없으며 메타데이터만 갱신합니다.

시작하기 전에

• 작업 대상 node에 MySQL Shell …와 MySQL …가 설치되어 있고, 클러스터는 InnoDB Cluster 설치 가이드 또는 이와 동등한 방식으로 AdminAPI로 구성되어 있습니다(메타데이터 존재). OS root가 로컬 mysql에 비밀번호 없이 접속할 수 있습니다. 폼의 클러스터 이름은 dba.getCluster().getName()에서, 멤버 주소는 cluster.status() 토폴로지의 ip:port 줄에서 가져오십시오.
• … 계정의 비밀번호를 알고 있습니다(모든 node에서 동일). MySQL Shell은 접속할 때마다 비밀번호를 묻고, --save-passwords=never이므로 저장하지 않습니다.
• Node들이 서로 MySQL 포트(……:……, ……)와 Group Replication 통신 포트로 접근할 수 있습니다.
• 새 node에 MySQL …가 클러스터 멤버와 같은 마이너 버전으로 설치되어 있고(clone 조건), GTID가 켜져 있으며, server_id가 다른 node와 다르고, 설치 가이드의 Group Replication 설정이 my.cnf에 있습니다. firewall/SELinux 포트가 열려 있습니다.
• Router 서버가 MySQL 포트로 node에 접근할 수 있습니다…. 또한 repo.mysql.com에 접속할 수 있습니다….
• 변경 승인, (필요 시) 유지 보수 시간, 애플리케이션 팀과의 소통이 준비되어 있습니다.

가이드 단계

• 상태: 클러스터, 멤버, Router(읽기 전용) — 상세 클러스터 상태 조회 및 저장 · SQL로 멤버와 큐 확인 · Group Replication 오류 기록 검사 · Router를 통한 RW/RO 라우팅 확인 · 결과 해석 및 알맞은 시나리오 선택
• 1. 진단: 새 node와 클러스터가 준비되었는가? — 새 node의 버전과 식별 정보 확인 · 클러스터 상태와 멤버 버전 확인
• 2. 안전장치 — 현재 토폴로지 저장
• 3. 실행: 멤버 추가 — 새 node 구성 및 관리자 계정 생성 · 클러스터 측에서 새 node의 적격성 검사 · 클러스터에 node 추가(…)
• 4. 검증 — 새 멤버가 ONLINE인지 확인
• 5. 후속 조치 — Router, 모니터링, 인벤토리 갱신
• 1. 진단: 멤버를 제거해도 안전한가? — 대상 멤버의 상태와 남은 장애 허용 수준 표시
• 2. 안전장치 — 현재 토폴로지 저장
• 3. 실행: 멤버 제거 — 클러스터에서 멤버 제거…(force)…
• force로 제거한 node가 돌아오면 — 돌아온 node에서 Group Replication 중지 및 정리
• 4. 검증 — 남은 멤버 확인
• 5. 후속 조치 — 홀수 멤버, Router, 모니터링
• 1. 진단: 멤버가 왜 이탈했고, 재합류할 수 있는가? — 클러스터 관점에서 본 대상 멤버의 상태 · 대상 node의 MySQL 및 Group Replication 상태 표시 · Errant 트랜잭션 확인(대상에는 있고 클러스터에는 없는 것)
• 2. 안전장치 — 현재 상태 저장
• 3. 실행: 멤버 재합류 — rejoinInstance로 멤버 재합류
• 4. 검증 — 멤버가 ONLINE인지 확인
• 5. 후속 조치 — 근본 원인과 자동 재합류
• 1. 진단: 클러스터 전체가 정말 내려갔는가, 가장 최신 멤버는 어느 것인가? — 모든 node에서 MySQL을 시작하고 Group Replication 상태 표시 · Shell에 가장 최신 멤버 확인(dryRun)
• 2. 안전장치 — 모든 node의 GTID 세트 저장
• 3. 실행: 가장 최신 멤버에서 클러스터 시작 — 클러스터 재시작
• 4. 검증 — 모든 멤버가 ONLINE인지 확인
• 5. 후속 조치 — Router, 애플리케이션, 근본 원인
• 1. 진단: quorum을 정말 잃었는가? — 살아남은 node에서 클러스터 상태 표시
• 2. 안전장치: 사라진 멤버 격리 — 사라진 node가 내려가 있는지 확인(fencing) · 살아남은 파티션의 상태 저장
• 3. 실행: quorum 강제 구성 — 살아남은 파티션으로 quorum 구성
• 4. 검증 및 사라진 멤버 복귀 — 쓰기가 열렸는지 확인 · 사라진 멤버 재합류(…)
• 5. 후속 조치 — 토폴로지 검토
• 1. 진단: 대상이 primary가 될 자격이 있는가? — 멤버 상태와 버전 확인
• 2. 안전장치 — 현재 상태 저장
• 3. 실행: primary 변경 — Primary 역할을 …에 이양