문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

복제본 세트를 4.4로 업그레이드

이 페이지의 내용

  • 업그레이드 권장 사항 및 체크리스트
  • 전제 조건
  • 4.4 바이너리 다운로드
  • 업그레이드 프로세스
  • 추가 업그레이드 절차

경고

MongoDB 3.0 메타데이터가 포함된 MongoDB 4.2 시리즈 배포를 4.4 시리즈 배포로 업그레이드할 때는 MongoDB 4.4.1 이상 으로 업그레이드해야 합니다. 다운타임의 심각한 위험 없이는 MongoDB 3.0 메타데이터가 포함된 배포를 MongoDB 4.4.0으로 성공적으로 업그레이드할 수 없습니다.

자세한 내용은 WT-6623 를 참조하세요.

MongoDB 4.4로 업그레이드하기 전에 사전 요구 사항을 철저히 검토하는 것을 포함하여 이 문서의 내용을 숙지하십시오.

4 으)로의 업그레이드에 대한 지침이 필요한 경우.4, MongoDB 전문 서비스 는 MongoDB 애플리케이션의 중단 없이 원활하게 전환할 수 있도록 주요 버전 업그레이드 지원을 제공합니다.

업그레이드할 때는 다음 사항을 고려하세요:

기존 MongoDB 배포를 4.4로 업그레이드하려면 4.2 시리즈 릴리스를 실행 중이어야 합니다.

이전 버전에서 4 업그레이드합니다. -series의 경우 으)로 업그레이드할2때까지 주요 릴리스를 연속적으로 업그레이드해야 4 2합니다. -series. 예를 들어 을(를) 실행 중인 경우입니다.4 0-series, 먼저 로 업그레이드해야 4 합니다. 로2 업그레이드 하기 전에 4.4.

MongoDB를 업그레이드하기 전에 MongoDB 4 을(를) 사용하고 있는지 확인하세요.4-호환 드라이버. 특정 드라이버의 드라이버 설명서 를 참조하여 MongoDB 4 와의 호환성을 확인하세요.4.

호환되지 않는 드라이버에서 실행되는 업그레이드된 배포에서 예기치 않거나 정의되지 않은 동작이 발생할 수 있습니다.

업그레이드를 시작하기 전에 MongoDB 4.4의 호환성 변경 사항 문서를 참조하여 애플리케이션 및 배포가 MongoDB 4.4와 호환되는지 확인하십시오. 업그레이드를 시작하기 전에 배포의 비호환성을 해결하세요.

MongoDB를 업그레이드하기 전에 프로덕션 환경에 업그레이드를 배포하기 전에 항상 스테이징 환경에서 애플리케이션을 테스트하십시오.

4 으)로 업그레이드한 후 4, 다운그레이드해야 하는 경우 4 의 최신 패치 릴리스로 다운그레이드 하는 것이 좋습니다.2.

경고

다운그레이드 플로어

버전 4.4에서 다운그레이드해야 하는 경우 4.2.6 이상 버전으로 다운그레이드합니다. 4.2.5 이하 버전으로 다운그레이드할 수 없습니다.

모든 복제본 세트 멤버는 버전 4 을(를) 실행 중이어야 합니다.2. 4 에서 복제본 세트를 업그레이드합니다.0-series 및 이전 버전에서는 먼저 복제본 세트의 모든 멤버를 최신 4 로 업그레이드합니다.2-series 릴리스로 이동한 다음 MongoDB 4 에서 업그레이드하는 절차를 따릅니다.2 ~ 4.4.

복제본 세트의 구성원을 업그레이드하기 전에 해당 구성원이 완전히 종료되었는지 확인합니다.

4.2 복제본 세트에는 featureCompatibilityVersion"4.2" 로 설정되어 있어야 합니다.

복제 세트의 모든 구성원이 featureCompatibilityVersion ("4.2") 로 설정되었는지 확인하려면 각 복제 세트 구성원에 연결하고 featureCompatibilityVersion 를 확인합니다.

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

모든 멤버는 "featureCompatibilityVersion" : { "version" : "4.2" }을 포함하는 결과를 반환해야 합니다.

0}을 설정하거나 업데이트하려면 featureCompatibilityVersion 기본값에서 다음 명령을 실행합니다. 데이터를 포함하는 구성원의 대부분을 사용할 수 있어야 합니다.

db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

자세한 내용은 setFeatureCompatibilityVersion를 참조하세요.

2} 또는 상태의 ROLLBACK RECOVERING 복제본 집합 구성원이 없는지 확인합니다.

MongoDB apt, yum, dnf 또는 zypper 리포지토리에서 MongoDB를 설치한 경우 패키지 관리자를 사용하여 4.4로 업그레이드해야 합니다.

Linux 시스템에 적합한 4.4 설치 지침 을 따르세요. 여기에는 새 릴리스에 대한 리포지토리를 추가한 다음 실제 업그레이드 프로세스를 수행하는 작업이 포함됩니다.

패키지 관리자를 사용하여 MongoDB를 설치하지 않은 경우, MongoDB 다운로드 센터 에서 MongoDB 바이너리를 수동으로 다운로드할 수 있습니다.

자세한 내용은 4.4 설치 지침 을 참조하세요.

경고

기존 MongoDB 인스턴스를 MongoDB 4.4.19로 업그레이드할 때 mongod.conf 파일에 fork: true 이 설정되어 있으면 해당 인스턴스가 시작되지 않을 수 있습니다.

업그레이드 문제는 .deb 또는 설치 패키지를 사용하는 모든 MongoDB .rpm 인스턴스에 영향을 미칩니다. tarball(.tgz) 릴리스 또는 기타 패키지 유형을 사용하는 설치는 영향을 받지 않습니다. 자세한 내용은 SERVER-74345 를 참조하세요.

fork: true 설정을 제거하려면 시스템 터미널에서 다음 명령을 실행합니다.

systemctl stop mongod.service
sed -i.bak '/fork: true/d' /etc/mongod.conf
systemctl start mongod.service

두 번째 systemctl 명령은 설정이 제거된 후 업그레이드된 인스턴스를 시작합니다.

"롤링" 업그레이드를 사용하여 MongoDB 4.2에서 4.4로 업그레이드하면 다른 멤버를 사용할 수 있는 동안 멤버를 개별적으로 업그레이드하여 다운타임을 최소화할 수 있습니다.

1

복제본 세트의 보조 멤버를 한 번에 하나씩 업그레이드합니다.

  1. mongod 인스턴스를 종료하고 4.2 바이너리를 4.4 바이너리로 바꿉니다.

  2. 멤버를 다시 시작합니다.

2

프라이머리에 mongo shell 을 연결하고 를 rs.stepDown() 사용하여 프라이머리를 물러나게 하고 새 프라이머리를 강제로 투표합니다.

3

2}에서 기본 구성원이 물러나고 다른 구성원이 상태를 rs.status() 맡게 PRIMARY 되면, 물러난 기본 구성원을 업그레이드합니다.

  1. 물러난 프라이머리를 종료하고 mongod 바이너리를 4.4 바이너리로 바꿉니다.

  2. 멤버를 다시 시작합니다.

4

현재 4.2와 호환되지 않는 4.4 기능 없이 4.4 바이너리를 실행할 수 있습니다.

이러한 4.4 기능을 사용하려면 기능 호환성 버전(fCV)을 4.4로 설정합니다.

이전 버전과 호환되지 않는 이러한 기능을 활성화하면 다운그레이드하기 전에 이전 버전과 호환되지 않는 지속적인 기능을 제거해야 하므로 다운그레이드 프로세스가 복잡해질 수 있습니다.

업그레이드 후에는 다운그레이드 가능성을 최소화하기 위해 번인 기간 동안 이러한 기능을 활성화하지 않고 배포를 실행하도록 허용하는 것이 좋습니다. 다운그레이드 가능성이 매우 낮다고 확신하는 경우 이러한 기능을 활성화하십시오.

초기 동기화가 진행 중이 아닌지 확인합니다. 초기 동기화가 진행 중일 때 setFeatureCompatibilityVersion 명령을 실행하면 초기 동기화가 다시 시작됩니다.

기본 데이터베이스에서 admin 데이터베이스의 setFeatureCompatibilityVersion 명령을 실행합니다.

db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

featureCompatibilityVersion(fCV) : "4.4" 설정 replSetReconfig 를 암시적으로 수행하여 구성 문서에 term 필드를 추가하고 새 구성이 대부분의 복제본 세트 구성원에 전파될 때까지 차단합니다.

이 명령은 내부 시스템 컬렉션에 대한 쓰기를 수행해야 합니다. 어떤 이유로든 명령이 성공적으로 완료되지 않는 경우 작업은 무력하므로 주 서버에서 명령을 안전하게 재시도할 수 있습니다.

← 독립형을 3.6으로 업그레이드