Mongo DB 백업
백업을 하는 이유
→ 데이터의 안전한 저장, 장애 발생시 가장 중요하게 필요한 것이 백업과 복구.
백업 방식
1. ShutDown & File copy
2. FSyncLock & Backup
3. MongoDump, MongoRestore
4. MongoExport, MongoImport
결정
→ MongoDump, MongoRestore
이유
가장 흔하게 사용하는 방법이기도 하고 Mongo DB를 끌 필요가 없다. 또한, BSON형태로 빠르게 백업과 복구가 가능하다.
mongodump 명령어를 통해 덤프를 시킬 수가 있다
$ mongodump -o 덤프지정위치(디렉터리) --host 127.0.0.1 --port 27017 -u계정명 -p계정비번 --db 선택적으로 복구하려는 db명그러나, 정해진 시간에 주기적으로 dump를 뜨고 싶다.
주기적으로 Mongo DB를 백업하는 방법, 자동화
정해진 시간에 주기적으로 dump를 뜨려면 작업 예약 스케쥴러인 Cron으로 쉘 스크립트(mongodump 명령어)를 돌리면 된다.
Cron : 작업 예약 스케쥴러
쉘 스크립트 (.sh) : shell의 명령어를 파일로 저장해서 파일을 실행하면 명령어가 실행된다.
crontab
→ cron작업을 설정하는 파일
→ 특정 시간을 정하고 그 시간에 맞춰 특정 sh파일을 실행시키는 역할
# crontab -e 로 등록 할 수 있다.
# 매일 00시
# m h day month week
0 0 * * * /home/workspace/mongo-dump/backup.shshell script
#!/bin/sh
#200911-0000 파일 생성됨
mongodump -u mysterico -p \!aiground2017 --authenticationDatabase admin -d social-monitor-prod -o /home/workspace/mongo-dump/$(date +%y%m%d-%H%M)여기서 잠깐!
만약 몽고DB 백업파일의 용량이 엄청나게 크다면 어떻게 될까?
-> 하루에 한번씩 로컬에 있는 백업파일을 최신 하나만 남겨두고 계속 삭제 시켜줘야 하는 불편함이 생김. 왜? SSD에 부담이 생기니까..
그러면 로컬로 부터 Aws S3에 백업파일을 이동시켜야 겠다!
백업한 Mongo DB 파일을 S3로 업로드(로컬 → S3)
방법 (Ubuntu)
→ awscli
$ sudo apt-get install awscli$ aws configure
# 4개의 항목이 나오는 데 key들은 AWS 계정 설정 시 다운 받을 수 있는 csv파일에 있고, region은 서울인 ap-northesast-2로 설정, 마지막은 enter로 넘어감
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:# 내 계정의 버킷 리스트
$ aws s3 ls# local -> s3 upload
# 다른 여러 명령어 옵션이 있음
# 참고 https://lovit.github.io/aws/2019/01/30/aws_s3_iam_awscli/
$ aws s3 cp localfile s3://[BUCKETNAME]/[FILENAME]
$ aws s3 mv localfile s3://[BUCKETNAME]/[FILENAME]→ 위의 명령어를 통해 백업파일을 생성한 버킷에 업로드 시킬 수가 있다.
→ 로컬에 파일을 저장하면 용량을 상당히 많이 차지하기 때문에 cp(복사) 말고 mv(이동)하는 방식으로 로컬 → s3로 파일들을 이동시켜주는 방식으로 진행
그러나 이 것 역시 계속해서 명령어를 사용하여 s3로 옮겨줘야 하기 때문에 특정 시간에 맞춰 자동화를 해야한다.
주기적으로 백업 파일을 감지하여 s3로 업로드, 자동화
inotifywait
-> 파일시스템의 변경이 발생할 때까지 대기하는 리눅스 명령어
파일, 폴더 모두 모니터링 가능
$ sudo apt-get install inotify-tools# inotify.sh
MONITOR_PATH=/home/workspace/mongo-dumps
inotifywait -m -e create "$MONITOR_PATH" |
while read dirname eventlist filename
do
aws s3 mv localfile s3://[BUCKETNAME]/[FILENAME]
done$ ./inotify.sh & (혹은 pm2로 데몬 실행)
# 위의 두 코드는 내가 지정한 PATH에 파일이 생성되면, 감지하고 생성(create 옵션을 사용했기 때문에)된 모든 파일을 aws s3 mv 명령어를 통해 s3로 업로드시킨다.- inotifywait을 사용할때 데이터 싱크 문제가 발생하여 모든 데이터가 다 s3로 안올라가는 현상 발생.
- inotify의 자체적인 문제
해결 방안
- 파일 명을 미리 파악한다.
- 백업 파일이 crontab을 통해 00시에 떨궈 졌을 때 해당 파일명을200911-0000(년월일-시분) 로 미리 설정해놓았다
- 이 파일 명을 이용해 03시에 crontab으로 해당 파일을 s3로 업로드시킨다.
# crontab
# 매일 03시 백업
# 백업 파일이 이미 다 생성 되었을 무렵에 s3로 업로드 하는 쉘 스크립트인 backup-to-s3.sh을 실행
0 3 * * * /home/mysterico/workspace/mongo-dump/backup-to-s3.sh #!/bin/sh
MONITOR_PATH=/home/workspace/mongo-dump
BUCKET_NAME=backup-test
aws s3 mv ${MONITOR_PATH}/$(date +%y%m%d-0000)/ s3://${BUCKET_NAME}/$(date +%y%m%d-0000)/ --recursive --storage-class STANDARD_IA
--> backup-to-s3.sh추가 설명
AWS S3 스토리지 클래스 (Storage class)
위의 shell script에서 (backup-to-s3.sh) aws s3명령어 옵션 중 --storage-class STANDARD_IA 라는 옵션을 주었다.
이게 바로 스토리지 클래스를 정해주는 옵션이다.
여러 사용 사례에 맞춰 설계된 스토리지 클래스.
대표적인 것 3가지만 뽑아보았다.
- Standard
- Standard-IA
- One Zone-IA
백업할때 사용하기 적합한 스토리지 클래스???
→ Standard-IA로 결정
standard는 자주 액세스하는 데이터의 범용 스토리지를 위한 것이고, Standard-IA는 수명이 길지만 자주 액세스하지 않는 데이터를 위한 것, One Zone-IA는 수명이 길고 자주 액세스하지 않는 데이터이며 중요하지 않은 데이터를 위한 것이다.
따라서 백업파일을 보관에 가장 적합한 기능 및 가격을 가진 Standard-IA를 사용하기로 결정하였다.
Aws S3 vs Aws Glacier ??
S3와 Glacier는 아카이브 백업을 위한 초기 투자 비용이 들지 않고, 저장한 만큼 비용을 지불한다는 면에서 동일하다. 내구성도 동일 (99.999999999%)
그러나 Glacier가 더욱 저렴한 가격에 제공됨.
그래서 S3 말고 Glacier를 사용하려고 하였음.
그러나 Glacier는 단점이 명확함
- 마음대로 검색이 불가능함.
- 마음대로 삭제가 불가능함.
- 데이터 업로드 및 검색의 경우 따로 UI를 제공해 주지 않음.
또한 테스트를 하려고 Glacier에 아카이브를 업로드 할 시 조회가 안됨. 하루에 한번 업데이트가 되어 다음날 확인해야함.
- 데이터 복구의 아쉬움
데이터를 복구하는 시간이 약 3~5시간이 필요하다고 함.
이러한 이유로 S3를 사용하였다.
끝!!
