[MongoDB] 3.0 업그레이드 (upgrade MongoDB to 3.0)

MongoDB 3.0 버전으로 업그레이드를 하려면 반드시 업그레이드할 클러스터가 2.6 이상이어야 함.

[참고]

http://docs.mongodb.org/master/release-notes/3.0-upgrade

[사전체크]

아래 페이지의 내용을 검토하여 업그레이드를 위해 준비해야 할 사항 등을 체크할 것.

http://docs.mongodb.org/master/release-notes/3.0-compatibility

[binary upgrade]

1. balancer 중지

mongos> sh.stopBalancer()

2. metadata upgrade

3.0 버전의 mongos로 2.6 버전의 config DB에 접속하여 upgrade를 수행.

[root@localhost]# $MONGO_3.0_PATH/bin/mongos --configdb config-01.bloodguy.com:27018,config-02.bloodguy.com:27018,config-03.bloodguy.com:27018 --keyFile $MONGO_KEY_PATH --upgrade

// metadata upgrade가 성공했다면 아래와 같은 로그가 남음

upgrade of config server to v6 successful

Config database is at version v6

// --upgrade 옵션을 빼고 mongos를 재시작 해볼 것. 만약 실패하면 로그를 확인하고 조치를 취할 것

3. mongos upgrade

metadata 업그레이드 완료 후 2.6 버전의 mongos를 하나씩 shutdown 하면서 3.0 버전의 mongos로 대체.

// 2.6 버전 mongos 접속

[root@localhost]# $MONGO_2.6_PATH/bin/mongo mongos-01.bloodguy.com:27017

// admin db 선택 후 shutdown

mongos> use admin

switched to db admin

mongos> db.auth('USER', 'PASS')

1

mongos> db.shutdownServer()

...

...

> quit()

// 3.0 버전 mongos 시작

[root@localhost]# $MONGO_3.0_PATH/bin/mongos -f $MONGO_3.0_CONF_PATH

4. config mongod upgrade

mongos의 --configdb 설정에서 가장 처음에 있는 configDB mongod를 가장 마지막에 upgrade할 것.

// 3.0 버전 mongod(config) 접속

[root@localhost]# $MONGO_2.6_PATH/bin/mongo config-03.bloodguy.com:27018

// 인증하고 shutdown

> use admin

switched to db admin

> db.auth('USER', 'PASS')

1

configsvr> db.shutdownServer()

...

...

> quit()

// 3.0 버전 mongod 시작

[root@localhost]# $MONGO_3.0_PATH/bin/mongod -f $MONGO_3.0_CONF_PATH

5. shard mongod upgrade

shard의 mongod binary upgrade 방법은 config mongod 와 동일함.

단, ARBITER, SECONDARY부터 먼저 upgrade를 한 후,

PRIMARY는 rs.stepDown()을 통해 새로운 PRIMARY 선출을 확인한 후 upgrade를 진행할 것.

6. balancer 재시작

mongos> sh.startBalancer()

[사용자 인증모델 upgrade]

MongoDB 3.0부터 사용자 인증모델이 기존의 MONGODB-CR에서 SCRAM-SHA-1로 바뀌었음.

upgrade 하기 전 체크해야 할 사항들이 많다. 

사용자 인증모델을 upgrade하면 백업을 복구하지 않는 한 되돌리기가 불가능하므로 심사숙고할 것.

사용자 인증모델을 upgrade하기 전에 MongoDB의 모든 binary가 3.0 이상인지 체크할 것.

사용하는 언어별 MongoDB 드라이버가 SCRAM-SHA-1을 지원하는 버전인지 확인할 것. (중요!)

사용자 인증모델을 upgrade하고 나면 downgrade하기가 상당히 어려우므로 binary upgrade 후 1~2일 정도 경과를 지켜보고 문제가 없을 경우 사용자 인증모델을 upgrade할 것. 만약 곧바로 사용자 인증모델을 upgrade 하려고 해도 binary upgrade 후 최소한 10초 이상은 기다린 후 진행 할것.

다음 페이지 참고: http://docs.mongodb.org/master/release-notes/3.0-scram

모든 체크가 완료되었다면 아래 순서대로 사용자 인증모델 upgrade 진행.

1. mongos로 접속한 후 admin DB를 선택하고 userAdminAnyDatabase 권한 이상을 가진 사용자로 로그인 인증.

mongos> use admin

switched to db admin

mongos> db.auth('USER', 'PASS')

1

2. authSchemaUpgrade 명령어 실행.

mongos> db.adminCommand({authSchemaUpgrade: 1})

성공하면 2.4 -> 2.6 처럼 새로운 collection이 생성되는건 아니고 admin db의 system.users document가 바뀐다.

credentials가 MONGODB-CR에서 SCRAM-SHA-1로 변경됨을 확인할 수 있다.

[WiredTiger - ReplicaSet]

3.0부터 storage engine을 고를 수 있게 되었고, wiredTiger가 최초의 storageEngine 선택사항으로 나왔음.

(기존의 storage engine은 MMAPv1)

compression이나 document level lock이라든지, 각종 벤치마크에서 높은 성능을 보인다고 나오므로 한 번 테스트 해보고 도입하는 것도 나쁘지 않은 듯.

ReplicaSet의 PRIMARY, SECONDARY만 storageEngine을 교체한다.

ARBITER는 어차피 데이터를 핸들링하는 노드가 아니므로 생략하고,

config의 경우엔 오피셜 문서에서 아직은 MMAPv1을 쓰라고 강력히 권장하므로 생략.

ReplicaSet의 각 멤버별로 다른 StorageEngine이 섞여있어도 돌아가므로 역시 기본적으로 rolling upgrade 방식이라 간주하고 진행하면 된다.

다만 data는 initSync 방식이므로 binary drop-in 방식에 비해 시간은 좀 더 걸린다.

1. SECONDARY shutdown

2. WiredTiger용 dbpath로 지정할 새 디렉토리 생성. (혹은 내부의 데이터만 날리거나 뭐 각자 편한 방식으로 준비)

3. storageEngine 설정옵션을 WiredTiger로 지정하고 shutdown했던 SECONDARY 재시작.

mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> // 뭐 이런식으로...

설정파일을 이용한다면 storage.engine을 wiredTiger로 지정.

기타 관련 옵션은 아래 페이지 참조.

http://docs.mongodb.org/manual/reference/configuration-options/#storage-wiredtiger-options

4. 정상적으로 instance가 시작되었다면 initial sync가 시작됨. sync가 완료될 때까지 대기.

5. PRIMARY는 rs.stepDown()으로 새로운 PRIMARY가 선출되는 것을 확인한 후 shutdown 하고 2~4까지의 과정 진행.

[WiredTiger - config]

config 노드를 굳이 WiredTiger로 변경하겠다면 아래 페이지 참조.

http://docs.mongodb.org/master/release-notes/3.0-upgrade/#change-config-server-to-use-wiredtiger

개략적으로 정리하면 순서는 아래와 같다.

1. sh.stopBalancer()

2. mongos의 --configdb 옵션에서 가장 마지막에 설정한 3번째 config 서버 shutdown

3. mongos의 --configdb 옵션에서 2번째로 지정한 config 서버의 데이터 export

mongodump --out <exportDataDestination> // 기타 적절한 옵션과 함께

4. 2번째 config 서버의 WiredTiger용 dbpath로 지정할 새 디렉토리 생성.

5. 2번째 config 서버를 shutdown 하고 storageEngine 옵션을 WiredTiger로 설정하여 재시작.

mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --configsvr --기타옵션

6. 2번째 config 서버의 export 했던 데이터를 restore

mongorestore <exportDataDestination> // 적절한 옵션과 함께

7. restore 완료 후 2번째 config 서버 shutdown

8. 3번째 config 서버 재시작 후 mongodump부터 mongorestore까지 2번째 config 서버와 동일하게 진행. (마지막 shutdown은 하지 않음)

9. 1번째 config 서버도 mongodump부터 mongorestore까지 2번째 config 서버와 동일하게 진행. (마지막 shutdown은 하지 않음)

10. 2번째 config 서버 재시작 (물론 WiredTiger로)

11. config 서버 3개 모두 정상동작하는 것을 확인했다면 sh.startBalancer()