반응형
- RPM 으로 설치된 Replica Set 에 대해 Upgrade 방법 입니다.
- 기본적으로 Downtime 을 가지고 진행 합니다.
- Secondary 를 standalone 형태로 변경 후, 업그레이드 한다면 Downtime 없이 가능하며, 실제로 진행한 결과 문제 없이 업그레이드 진행 하였습니다.
- 이 부분에 대해서는 별도로 문서는 만들지 않았습니다.
- PSA 구조로 진행하였으며, PSS 구조로 진행 한다면 Arbiter 업그레이드 대신 Secondary 진행한 그대로 대신 진행 하면 됩니다.
- MongoDB 3.4 to 4.2 로 진행 합니다.
- aws ec2 - amazon2 에서 진행 하였습니다.
Repo 추가 및 설정
- 하나의 yum Repository 로도 가능하나, 별도의 repository 추가하여 진행 하였습니다. (별다른 이유는 없습니다.)
cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-3.6.repo
$ cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-4.0.repo
$ cp /etc/yum.repos.d/mongodb-org-3.4.repo /etc/yum.repos.d/mongodb-org-4.2.repo
# 3.6 추가
$ vi /etc/yum.repos.d/mongodb-org-3.6.repo
[mongodb-org-3.6]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/3.6/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc
# 4.0 추가
$ vi /etc/yum.repos.d/mongodb-org-4.0.repo
[mongodb-org-4.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc
# 4.2 추가
$ vi /etc/yum.repos.d/mongodb-org-4.2.repo
[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc
# yum 초기화 진행
$ yum clean all
$ yum update list
MongoDB 3.6 Upgrade 진행
- Secondary -> Arbiter -> Primary 순으로 진행 합니다.
############ Secondary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-3.6.23
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:SECONDARY> rs.status()
############ Arbiter ############
# mongo 서버 종료
$ systemctl stop mongod_arb.service
# yum 으로 update 진행
$ yum update mongodb-org-3.6.23
# mongodb 서버 시작
$ systemctl start mongod_arb.service
# mongodb 접속 후 확인
$ mongo --port 27018
# replica 접속 되었는지 확인
repl_set:ARBITER> rs.status()
############ Primary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-3.6.23
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:PRIMARY> rs.status()
############ 중요!!! ############
# featureCompatibilityVersion 수정
repl_set:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
# 정상적으로 변경되었는지 확인
repl_set:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
MongoDB 4.0 Upgrade 진행
- Secondary -> Arbiter -> Primary 순으로 진행 합니다.
############ Secondary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-4.0.27
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:SECONDARY> rs.status()
############ Arbiter ############
# mongo 서버 종료
$ systemctl stop mongod_arb.service
# yum 으로 update 진행
$ yum update mongodb-org-4.0.27
# mongodb 서버 시작
$ systemctl start mongod_arb.service
# mongodb 접속 후 확인
$ mongo --port 27018
# replica 접속 되었는지 확인
repl_set:ARBITER> rs.status()
############ Primary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-4.0.27
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:PRIMARY> rs.status()
############ 중요!!! ############
# featureCompatibilityVersion 수정
repl_set:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )
# 정상적으로 변경되었는지 확인
repl_set:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
MongoDB 4.2 Upgrade 진행
- Secondary -> Arbiter -> Primary 순으로 진행 합니다.
############ Secondary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-4.2.18
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:SECONDARY> rs.status()
############ Arbiter ############
# mongo 서버 종료
$ systemctl stop mongod_arb.service
# yum 으로 update 진행
$ yum update mongodb-org-4.2.18
# mongodb 서버 시작
$ systemctl start mongod_arb.service
# mongodb 접속 후 확인
$ mongo --port 27018
# replica 접속 되었는지 확인
repl_set:ARBITER> rs.status()
############ Primary ############
# mongo 서버 종료
$ systemctl stop mongod.service
# yum 으로 update 진행
$ yum update mongodb-org-4.2.18
# mongodb 서버 시작
$ systemctl start mongod.service
# mongodb 접속 후 확인
$ mongo admin -uadmin -p
# replica 접속 되었는지 확인
repl_set:PRIMARY> rs.status()
############ 중요!!! ############
# featureCompatibilityVersion 수정
repl_set:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )
# 정상적으로 변경되었는지 확인
repl_set:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
- 반복 작업이지만, MongoDB는 순차적으로 upgrade 하는 것이 권고 사항 입니다.
- 또한, featureCompatibilityVersion 을 수정하지 않는 경우 다음 version upgrade 이후 startup 이 되지 않는 이슈가 발생 합니다.
- 이 때, 이전 version으로 downgrade 이 후, featureCompatibilityVersion 수정 후 다시 업그레이드를 하게 되면 진행이 가능합니다.
- 모든 upgrade 작업은 백업은 필수! 입니다.
- 가령, 문제가 발생하여 repair 명령어를 이용하여 startup 을 하게 되면, 모든 collection repair 및 index rebuild 까지 진행 하기 때문에 데이터 size 가 작은 사이트에서는 크게 이슈가 발생하지 않겠지만, 저희처럼 테라바이트 단위라면 repair 시간을 예측 하기 힘든 상황이 발생 합니다. (6테라 size의 db를 repair 로 만 하루 넘어가도 끝나지 않아 포기하고 기존 ec2 snapshot 으로 복구 진행 하였습니다.)
- 이후, 다른 글에서 upgrade 과정에서 MinValidDocument.oplogDeleteFromPoint is an unknown field 이슈에 대해 해결 방법을 공유 하도록 하겠습니다.
반응형
'MongoDB' 카테고리의 다른 글
| [MongoDB] Logical Session / Causal Consistency (0) | 2022.12.08 |
|---|---|
| [MongoDB] tcmalloc memory cache 정리 (0) | 2022.08.22 |
| [MongoDB] taskExecutorPoolSize (0) | 2022.08.08 |
| [MongoDB] Replica Set to StandAlone (v4.2) (0) | 2022.07.04 |
| [MongoDB] Upgrade 이슈 (4.0 to 4.2) - MinValidDocument.oplogDeleteFromPoint is an unknown field (0) | 2022.07.02 |