MongoDB 일상 운영 및 장애 시나리오 (replica set 및 sharded cluster)

설치 가이드가 아닙니다. 이미 설치된 MongoDB replica set과 sharded cluster를 일상적으로 운영하고, 문제가 생겼을 때 복구하기 위한 시나리오 기반 runbook입니다. 상태 점검, 멤버 추가/제거, priority/hidden/delayed 멤버, arbiter를 데이터 멤버로 교체, 뒤처진 멤버 재동기화, 과반수 상실 시 force reconfig, 계획된 stepDown, oplog 크기, FCV, shard 추가/제거, balancer, jumbo chunk, reshardCollection을 다룹니다. 무엇을 해야 할지 모르겠다면 상태 점검부터 시작하십시오. 백업 복원, 보안 설정, 메이저 버전 업그레이드는 별도의 MongoDB 가이드에서 다룹니다.

구성: Replica set(멤버 3개 이상) 또는 sharded cluster(config server + shard replica set + mongos)

시나리오

• 상태 점검: 멤버, 지연, oplog 윈도우(sharded 구성에서는 shard와 balancer 포함) — 읽기 전용: 멤버 상태, 복제 지연, oplog 윈도우, 구성. sharded cluster에서는 shard 목록, balancer, chunk 분포도 확인합니다. 무엇을 해야 할지 확실하지 않으면 여기서 시작하십시오.
• Replica set에 새 멤버 추가 (initial sync) — 새 서버가 준비되었습니다(동일 버전, keyfile, replSetName). priority 0 / votes 0으로 추가한 뒤, initial sync가 끝나고 SECONDARY가 되면 투표권과 priority를 부여합니다. 다운타임은 없습니다.
• Replica set에서 멤버 제거 — 서버를 폐기하거나 영구적으로 잃은 경우입니다. 멤버를 구성에서 제거하고, 남은 투표 수가 과반수를 유지하는지 확인합니다. Primary라면 먼저 stepDown합니다.
• 멤버 역할 변경: priority, hidden, delayed 멤버 — 멤버가 primary가 될 우선순위를 바꾸거나, 리포팅/백업용 숨김(hidden) 멤버 또는 실수로 인한 삭제에 대비한 지연(delayed) 멤버로 만들거나, 일반 멤버로 되돌립니다.
• Arbiter를 데이터 멤버로 교체 (PSA → PSS) — Primary + secondary + arbiter 구성의 replica set에서는 데이터 멤버 하나가 다운되면 majority 쓰기와 cache 압박이 문제가 됩니다. 새 데이터 멤버를 추가하고 arbiter를 제거합니다.
• 뒤처지거나 손상된 멤버 재동기화 (resync) — 멤버가 RECOVERING 상태에 머물며 'too stale to catch up'을 보고하거나 데이터 파일이 손상된 경우입니다. 멤버의 데이터 디렉터리를 비우고 initial sync로 처음부터 다시 동기화합니다. 다른 멤버는 계속 동작합니다.
• 과반수 상실: 남은 멤버로 강제 재구성 (force reconfig) — 멤버 대부분을 영구적으로 잃었고(사이트/서버 상실) 남은 멤버가 primary를 선출하지 못하는 경우입니다. 남은 멤버로 rs.reconfig(cfg, {force: true})를 실행합니다. 최후의 수단이며, 잘못 사용하면 데이터 손실과 split brain 위험이 있습니다.
• 계획된 primary 변경 (rs.stepDown, 특정 멤버를 primary로 지정) — Primary 서버에 유지보수/패치가 예정된 경우입니다. Primary가 물러나고 따라잡은 secondary가 primary가 됩니다. 애플리케이션에서 몇 초간 쓰기 오류가 발생할 수 있습니다.
• Oplog 크기 변경 (replSetResizeOplog) — Oplog 윈도우가 짧은 경우입니다. 유지보수 후 secondary가 'too stale' 상태가 되거나, 백업이 oplog를 따라잡지 못하거나, 시점 복구에 충분하지 않습니다. 각 멤버에서 다운타임 없이 크기를 늘립니다.
• Feature Compatibility Version(FCV) 확인 및 완료 — 업그레이드 후 FCV가 이전 버전에 머물러 있거나 멤버 간 버전이 다른 경우입니다. 모든 멤버의 바이너리 버전과 FCV를 확인하고 FCV를 새 버전으로 올립니다.
• Cluster에 shard 추가 (sh.addShard) — 용량이 부족한 경우입니다. 새 shard replica set(shardsvr)을 구축해 cluster에 추가하면 balancer가 chunk를 점진적으로 이동합니다.
• Shard 제거 (removeShard: drain 및 movePrimary) — Shard를 폐기하는 경우입니다. chunk를 다른 shard로 비우고(drain), 이 shard가 primary shard인 데이터베이스를 이동(movePrimary)한 다음 cluster에서 제거합니다.
• Balancer: 시간 윈도우, 중지 / 시작, 컬렉션 단위 비활성화 — Chunk 마이그레이션이 피크 시간에 부하를 주거나, 유지보수/백업 중에 마이그레이션을 멈춰야 하거나, 특정 컬렉션을 밸런싱 대상에서 빼야 하는 경우입니다.
• 분포 불균형 또는 jumbo chunk (진단 및 해결) — 한 shard가 다른 shard보다 훨씬 많이 차 있거나, balancer가 이동하지 않거나, 'jumbo' 표시된 chunk가 있거나, moveChunk가 실패하는 경우입니다. 분포, jumbo chunk, balancer 오류를 조사합니다.
• Shard key 변경 (reshardCollection) — 현재 shard key가 hot shard, jumbo chunk 또는 scatter-gather 쿼리를 유발하는 경우입니다. 컬렉션을 새 shard key로 온라인 재분배합니다(5.0+). 마지막에 쓰기가 약 2초 차단됩니다.

시작하기 전에

• 관리 서버에 mongosh가 설치되어 있고 …mongos(…)…모든 멤버(…)…에 대한 이름 해석과 포트 접근이 가능합니다. 연결에 사용하는 이름은 rs.conf()의 멤버 이름과 같아야 합니다.
• … 사용자의 비밀번호를 알고 있으며, 역할은 root 또는 최소 clusterAdmin + readAnyDatabase입니다.… Shard 또는 config server replica set에 직접 연결할 때는 shard-local 관리자 사용자(mongo-sharded 가이드에서 생성)가 필요합니다.…
• 변경 요청 / 유지보수 윈도우가 승인되었고 애플리케이션 팀에 공지했습니다. Reconfig, stepDown, shard 작업은 몇 초간의 선출(election) 또는 라우팅 지연을 일으킬 수 있습니다.
• 새 멤버 …는 replica set 설치 가이드의 운영 체제, 설치, keyfile, 구성 단계로 준비되었습니다: 동일한 MongoDB 버전(…), 동일한 keyfile, replication.replSetName: …, mongod는 실행 중이지만 rs.initiate는 실행하지 않았습니다. 다른 멤버와 양방향으로 이름 해석과 포트 접근이 되며, 데이터 디스크에는 현재 데이터 이상의 여유 공간이 있습니다.
• Initial sync 동안 멤버 디스크에 모든 데이터가 다시 기록됩니다…. 이전 디렉터리를 옆으로 옮기므로 데이터 크기의 두 배 여유 공간이 필요합니다…. 남은 멤버가 과반수를 유지하고, 소스 멤버의 oplog 윈도우가 initial sync 소요 시간보다 깁니다.

가이드 단계

• 상태: 멤버, 지연, oplog (읽기 전용) — 멤버 상태와 지연 표시 · 구성 표시 (priority, votes, hidden, delay) · 결과 해석 및 시나리오 선택
• 상태: shard, balancer, chunk 분포 (읽기 전용) — Cluster 요약 표시 · Chunk 분포와 jumbo chunk · Shard replica set 상태 확인
• 1. 진단: 새 멤버가 준비되었는가? — 새 멤버의 서비스와 버전 확인 · 현재 세트의 상태와 데이터 크기 확인 · 새 멤버 접근 확인
• 2. 안전장치 — 현재 replica set 구성 저장
• 3. 적용: 멤버를 추가하고 동기화 대기 — 멤버를 priority 0 / votes 0으로 추가 · Initial sync 완료 대기 · 멤버에 투표권과 priority 부여
• 4. 검증 및 후속 작업 — 상태 검증 · 애플리케이션 연결 문자열과 모니터링 갱신
• 1. 진단: 제거할 멤버가 primary인가, 과반수가 유지되는가? — 멤버의 역할과 남은 투표 수 확인
• 2. 안전장치 — 현재 replica set 구성 저장
• 3. 적용: 멤버 제거 — 구성에서 멤버 제거 (rs.remove) · 제거된 서버에서 mongod 중지
• 4. 검증 및 후속 작업 — 상태 검증 · 연결 문자열, 모니터링, 방화벽 갱신
• 1. 진단 — 멤버의 현재 설정과 oplog 윈도우 확인
• 2. 안전장치 — 현재 replica set 구성 저장
• 3. 적용 — 멤버 설정 변경 (rs.reconfig)
• 4. 검증 — 결과 검증
• 1. 진단: arbiter와 새 멤버 — Arbiter와 write concern 확인 · 새 멤버 준비 상태 확인
• 2. 안전장치 — 현재 replica set 구성 저장
• 3. 적용: 데이터 멤버 추가, arbiter 제거 — 새 멤버를 priority 0 / votes 0으로 추가 · Initial sync 완료 대기 · 새 멤버에 투표권과 priority 부여 · Arbiter 제거 · Arbiter 서버에서 mongod 중지
• 4. 검증 및 후속 작업 — 상태와 write concern 검증
• 1. 진단: 멤버를 정말 재동기화해야 하는가? — 멤버의 상태와 마지막 메시지 확인 · 멤버 로그의 오류 확인
• 2. 안전장치 — 현재 replica set 구성 저장
• 3. 적용: 데이터 디렉터리를 비우고 initial sync — mongod 중지 · …데이터 디렉터리를 옆으로 옮김…데이터 디렉터리 비우기… · mongod 시작 (initial sync 시작) · Initial sync 완료 대기
• 4. 검증 및 후속 작업 — 상태 검증 · 이전 데이터 디렉터리 삭제
• 1. 진단: 과반수를 정말 영구적으로 잃었는가? — 살아 있는 멤버에서 상태와 optime 확인 · 잃은 멤버가 중지되었는지 확인
• 2. 안전장치 — 살아 있는 멤버의 구성 저장
• 3. 적용: force reconfig — 살아 있는 멤버만으로 강제 재구성 · Primary 선출 확인
• 4. 검증 및 후속 작업 — Majority 쓰기 시험 · 잃은 멤버를 다시 추가하고 근본 원인 해결
• 1. 진단: secondary가 따라잡았는가? — Primary와 지연 확인
• 2. 적용 — 다른 secondary 동결 (대상 멤버가 선출되도록) · Primary 물러나기 (rs.stepDown)
• 3. 검증 — 새 상태 검증
• 1. 진단: 현재 oplog 크기와 윈도우 — 각 멤버의 oplog 크기와 윈도우