MongoDB upgrade or 서버 이전

이번 글에서는 MongoDB에 대한 글을 처음으로 작성하려고 한다. 개발 중인 프로젝트에서 MongoDB를 사용하고 있는데 너무 오래된 과거 버전을 사용하고 있어서 업그레이드를 진행했다. 업그레이드하면서 ReplicaSet 구성, 인증 설정, mongodump/mongorestore를 통한 데이터 백업/복원을 진행했는데 정리를 하고자 한다.

 

물론 MongoDB 공식 문서에 설명이 잘 나와 있지만 한글로 정리하는 것도 의미가 있을 것 같았다. 작업을 진행할 때, 필자의 글로 전체적인 과정을 습득하고 세부적인 내용은 공식 문서에서 추가로 내용을 검토하는 것을 추천한다.

 

그리고 MongoDB는 업그레이드할 때, Rolling으로 업그레이드를 지원한다. 하지만 업그레이드 지원 버전의 한계가 있어서 너무 오래된 버전의 MongoDB를 사용하고 있으면 여러 번의 업그레이드를 거쳐야 한다. 그래서 필자는 새로운 MongoDB를 구축하고 과거 버전의 데이터를 복구하는 방식으로 진행했다. 그래서 Rolling 업그레이드를 원하시는 분은 공식문서를 참고하시고 필자의 글에서는 ReplicaSet 구성, 인증 설정, mongodump/mongorestore의 활용법을 익히는 용도가 더 적합하다.

 

참고로 4.2.14 버전으로 테스트를 했다.

 

1. ReplicaSet 구성

MongoDB는 여러대의 노드를 운영하며 데이터를 여러 복사본으로 구성할 수 있다. 하나의 서버가 죽더라도 복사본으로 구성된 서버로 바로 운영된다. 클라이언트가 Primary 노드에 데이터를 쓰고 읽지만 Secondary 노드들이 데이터를 Primary 노드에서 가져와서 복사한다.

Secondary 노드는 데이터를 포함한 노드인데, 데이터를 포함하지 않고 Primary 노드 선출에만 참여하는 Arbiter도 있다. ReplicaSet을 구성할 때 노드수에 따라 다운이 가능한 노드 수가 결정되는데 데이터를 포함한 서버를 유지할 리소스가 없을 때 Arbiter가 대안이 된다.

 

필자는 3대의 ReplicaSet을 구성하는데 Arbiter는 사용하지 않았다.

3대로 ReplicaSet을 구성할 때 한대가 Arbiter일 경우, Primary 노드가 죽으면 Secondary 노드로 데이터를 복사해야하는 이슈가 발생한다. 이때스토리지 캐시 부하가 발생할 수 있으며 majority 옵션을 꺼야 한다는 가이드가 있다. 관련된 내용은 공식문서 Disable Read Concern Majority를 참고하자.

 

그럼 실제로 ReplicaSet을 구성해보자.

먼저 3대의 MongoDB를 띄운다. 띄울 때 --replSet 옵션을 주의하자.

./mongod --fork --bind_ip mongo1 --logpath /data/logs/mongodb.log --dbpath /data/mongodb --port 27027 --replSet replsetTest
./mongod --fork --bind_ip mongo2 --logpath /data/logs/mongodb.log --dbpath /data/mongodb --port 27027 --replSet replsetTest
./mongod --fork --bind_ip mongo3 --logpath /data/logs/mongodb.log --dbpath /data/mongodb --port 27027 --replSet replsetTest

 

3대의 노드를 띄웠다면 mongo1 서버에서 mongo shell로 접근해서 아래 command를 실행한다.

rs.initiate()
rs.add("mongo2:27027")
rs.add("mongo3:27027")
rs.isMaster()
rs.status()

rs.status() command로 mongo1 ~ mongo3 까지의 노드가 Primary, Seconary로 설정됨을 확인할 수 있다.

 

 

2. 인증 설정

인증은 크게 사용자 인증과 ReplicaSet 노드 간의 내부 인증 설정으로 나눈다.

 

2.1. 사용자 인증

mongo shell로 접근해서 User를 생성하자.

User를 생성할 때, 권한을 함께 넣는데 권한은 사용자 타입에 따라 나눠서 부여할 수 있다. 데이터베이스 사용자/ 관리자, 클러스터 관리자 등으로 설정 가능하다. 권한은 Built-In Roles 문서를 확인하자.

 

아래 command는 데이터베이스 관리자 권한을 생성한 예이다.

admin = db.getSiblingDB("admin")
admin.createUser(
{
  user: "admin",
  pwd: "admin",
  roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
})

 

인증을 설정하고 난 다음에 사용자가 접근할 때는 uri에 다음과 같이 username:password를 추가하면 된다.

mongodb://admin:admin@mongo1:27027,mongo2:27027,mongo1:27027/test

 

2.2. ReplicaSet 내부 인증

이미 만든 ReplicaSet MongoDB에 Keyfile 설정을 추가해보자.

Keyfile은 SCRAM 방식을 사용하며 노드간에 공유된 비밀번호이다.

 

먼저 keyfile을 생성한다.

openssl rand -base64 756 > keyfile.txt
chmod 400 keyfile.txt

 

참고할 점은 keyfile의 권한을 400으로 맞춰줘야 한다. 권한을 너무 많이 줄 경우 mongod를 띄울 때 keyfile의 권한이 많아 정상적으로 실행되지 않는다.

 

실행할 때는 --keyFile 옵션을 추가하면 된다.

./mongod --fork --bind_ip mongo1 --logpath /data/logs/mongodb.log --dbpath /data/mongodb --port 27027 --replSet replsetTest --keyFile keyfile.txt

 

참고로 인증이 설정되지 않은 MongoDB에서 인증을 설정할 때, 인증이 없더라도 접근을 허용하는 옵션이 있다.

Rolling으로 서버 설정을 변경할 때 필요한데 --transitionToAuth 옵션을 붙이면 된다.

 

Downtime 없이 ReplicaSet에 인증을 추가하는 방법은 다음 문서Update Replica Set to Keyfile Authentication(No Downtime)를 참고하자.

 

 

3. mongodump/mongorestore

마지막으로 기존 MongoDB의 데이터를 새로운 MongoDB로 이관하는 방법이다.

 

데이터 추출은 mongodump를 활용한다.

mongodump --host=replsetTest/mongo1:27017,mongo2:27017,mongo3:27017 --port=27027 --username=admin --password='admin' --db=db --out=backup

참고로 uri 옵션으로 mongodb 주소를 넣을 수 있는데, uri로 접근하면 --username, --password 등의 옵션을 넣을 수 없다. (--uri 옵션 참고)

 

데이터 복원은 mongorestore로 한다. mongorestore는 mongodump로 추출한 데이터로 복원한다.

./mongorestore --host=replsetTest/mongo1:27017,mongo2:27017,mongo3:27017 --port=27027 --username=admin --password='admin' --db=db --collection=collection collection.bson

mongorestore에서 참고할 점이 한가지 있다. 버전 호환성이다.

사실 MongoDB의 최신 버전은 4.4 버전이다. 그런데 필자는 4.2.14 버전으로 테스트한 이유가 여기에 있다. mongorestore 4.4 버전에서는 최소 3.6 버전까지 지원한다. 필자의 경우 기존 MongoDB가 3.6 이전버전이라서 4.4 버전으로 바로 데이터 복원할 수 없었다.

 

업그레이드를 진행하실 때, 하위 버전 호환성은 한번 더 살펴보고 진행하시는 것이 좋다.

 

 

마무리

이번 글에서는 업그레이드 면밀히 따지면 서버 이전의 전체적인 과정을 살펴봤다. 실제로 수행하면서는 필자의 글을 토대로 공식문서의 내용을 더 살펴보며 진행하시는 것을 추천한다.

 

 

참고 문서

• MongoDB: The Definitive Guide, 3rd Edition
• Disable Read Concern Majority
• Built-In Roles
• Update Replica Set to Keyfile Authentication(No Downtime)