MongoDB 8.0 계열 안에서 패치 버전을 올리는 원노트를 정리했습니다. major 버전 전환 절차와는 다릅니다. 각 노드를 따로 갱신하고 정상 복제 상태로 돌아온 뒤 다음 노드를 진행합니다. 원본의 2대 서버와 동거 arbiter 구성은 권장 이중화 설계로 제시하지 않습니다.
작업 전 상태와 백업
지원되는 버전 조합, 패치 릴리스의 변경 사항, 디스크 여유와 복원 가능한 백업을 확인합니다. rs.status()에서 노드 상태·투표 과반·복제 지연을 확인하고 애플리케이션이 여러 seed와 replicaSet 이름으로 연결하는지 점검합니다.
rs.status()
db.runCommand({buildInfo: 1}).versionSECONDARY부터 한 대씩 갱신
해당 서버를 중지하고 현재 저장소 안에서 의도한 8.0 패치만 선택합니다. --assumeno로 변경 목록을 먼저 확인합니다. 도구 패키지와 서버 패키지의 버전 체계가 항상 같은 숫자는 아닙니다.
sudo systemctl stop mongod
sudo dnf upgrade --assumeno 'mongodb-org*'
sudo dnf upgrade 'mongodb-org*'
sudo systemctl start mongod재기동한 노드의 실제 버전과 SECONDARY 복귀, 동기화 완료를 확인합니다. 정상 복귀 전 다른 데이터 노드를 동시에 중지하지 않습니다. arbiter가 있는 구성은 해당 프로세스가 어느 패키지·유닛을 쓰는지도 확인합니다.
PRIMARY 역할 전환 후 갱신
동기화된 선출 가능 SECONDARY가 있는지 확인하고 PRIMARY에서 stepDown을 수행합니다. 잠깐의 쓰기 중단과 클라이언트 재연결이 발생할 수 있습니다.
rs.stepDown(60)이 명령은 기존 PRIMARY가 일정 시간 PRIMARY 선출 대상에서 빠지게 합니다. 60초 뒤 반드시 원래 PRIMARY로 돌아온다는 뜻은 아닙니다. 새 PRIMARY와 과반을 확인한 뒤 이전 PRIMARY였던 노드를 같은 순서로 갱신합니다.
최종 검증
모든 노드 버전·역할·지연·로그와 애플리케이션의 쓰기·읽기를 확인합니다. 같은 major의 패치 갱신을 위해 FCV를 임의로 바꾸지 않습니다. 실패한 노드는 로그와 호환성 원인을 확인하고 나머지 노드의 상태를 보존한 채 복구합니다.