[Backup & Recovery]DB 복구, 그 아찔한 기억(Table Level Recovery)

TL;DR

MongoDB Atlas에서 Table Level Recovery하는 방법입니다.

바쁘거나 급하신 분들은 아래 잡글은 스킵하시고, 목차 이후부터 보시기 바랍니다. 

IT Journeyman

어느날 오전 "테이블(Collection)이 날라갔어요"하는 전화에 우선 "금방 복구되니 저랑 같이 해보시면 된다"며 안심드리고 나니, 정작 떨리는 것은 내 목소리가 아닌가 하는 생각이 들었습니다. 방법을 찬찬히 설명드린 후 얼마 지나지 않아 잘 복구되어 업무가 정상이 되었다는 문자를 보면서 많이 놀라셨겠다는 생각과 예전과 다르게 SaaS 환경의 DB는 많이 편리해 졌구나 하는 생각이 들었습니다.

 

차장이라는 명함을 갖던 시절, 대형 시중은행의 DB의 기술 지원을 담당했었습니다. 스토리지 작업 후[1] DB가 정상 기동이 안된다는 연락을 받고 새벽에 수 십명의 은행 전산실 직원분들에게 둘러 싸여 은행 계정계 DB(3 node RAC)에 접속했습니다. 네, 여러분들의 계좌 잔액이 있는 바로 그 계정계 입니다. 새벽 5시 이전에 계정계가 정상화되지 못하면 입출금을 제외한 많은 업무가 정지되고, 9시까지 못하면 평일에 입출금 안되는 MBC 뉴스데스크에 나올 법한 상황이었습니다.(물론 DB 복구를 못해도 대응할 수 있는 방안이 이삼중으로 있습니다.)  

 

떨리는 손으로 'recover database' 입력하고 나서 한참을 log apply하다가 'media recovery complete'가 화면에 나왔을 때 "제발제발 정상 오픈만 되라" 맘 속으로 빌었습니다. 마침내 'alter database open'을 입력하고는 정말 심장이 쫄깃쫄깃해지는데, 드디어 'Database opened.' DB Open이 될 줄은 알았지만, resetlogs[2] 없이 올라와서 정말 정말 다행이었습니다.

 

백업 및 복구는 잘 해야 본 전이라 안하는 것이 좋지만, DBA라면 싫어도 항상 준비는 되어 있어야 합니다.

 

[1] 스토리지하니 생각이 나서 사족을 붙이자면, EMC의 TimeFinder와 SRDF는 그 기능은 비슷한 듯 하나 내부 작동 방식은 조금 다릅니다. 보통 시점복제본(TimeFinder BCV, Clone and Snapshot)으로 많이 쓰이는 스토리지 기반 시점 복제 방식은 기본적으로 "Crash Image"라는 원리를 사용하고 있습니다. 갑자기 서버가 죽었을 때처럼 복제본을 생성합니다. 아... 이거를 다 설명하기는 한 두줄로는 어렵고, 결론만 말씀드리면 'Begin Backup'을 찍지 않고 끊어 낸 TimeFinder Split은 Oracle DB의 Media Recovery가 필요할 수도 있습니다(Oracle은 Hot Backup Mode가 아닌 이런 시점복제본의 복구를 보장하지 않습니다.) 물론 재해복구(DR, Disaster Recovery)로 많이 쓰이는 SRDF는 그럴 가능성이 거의 없습니다.(그렇다고 EMC는 주장합니다, 그렇지 않을 경우 EMC와 Oracle은 서로에게 총질하며 질기고 기나긴 싸움을 할 겁니다.)

[2]DB를 resetlogs로 기동하게 되면, log sequence가 초기화되어 과거 백업과의 연결성이 끊어지게 되어 되도록 빠른 시간 내에 Full  Backup을 받아야 DB가 백업으로 보호될 수 있습니다. 보통 은행의 Legacy 시스템들은 크기가 커서 주말에 Full backup을 하고 주중에는 Incremental Backup이나 Archive Log Backup만 하는 경우가 많았습니다. 주중에 이런 상황이 발생했다면, 최악의 경우 주말까지 백업이 없는 상태로 운영을 해야 할 수도 있습니다. 

 

 

 

 

Table of Contents

 

1. Drop Collection 

2. 임시 Restore용 Cluster  생성(TEST01) 

3. Restore PROD01 into TEST01 

4. Restore Succeeded 

5. Connect String to TEST01 

6. Connecting to TEST01 using Compass

7. Check dropped collection at TEST01 

8. Export data from TEST01

9. Export completed

10. Connect to PROD01 using Compass

11. Create collection in PROD01 using Compass

12. Import collection with exported JSON using Compass

13. Check collection data

14. Miscellaneous

1. Drop Collection

삭제된 Table(Collection) 복구 테스트를 위해 M10 클러스터의 sample_mflix.users Collection 삭제 

 

2. 임시 Restore용 Cluster  생성(TEST01) 

 

3. Restore PROD01 into TEST01

임시로 만든 TEST01에 PROD01의 백업을 복구 

4. Restore Succeeded

15.46GB 9분만에 TEST01에 복구 완료

5. Connect String to TEST01

 새로 만든 TEST01로 접속하는 connect string 확인

6. Connecting to TEST01 using Compass

 

7. Check dropped collection at TEST01 

문제의  Collection을 확인합니다.

8. Export data from TEST01 

Compass의 Export Data 메뉴를 선택하고, 아래 JSON을 선택

 

9. Export completed

  SHOW FILE을 클릭하여 PC에 다운로드된 JSON 파일을 확인합니다.

10. Connect to PROD01 using Compass

 

11. Create collection in PROD01 using Compass

먼저 Dropped된 Collection을 만들어야 합니다. 물론 데이터는 없습니다.

12. Import collection with exported JSON using Compass

껍데기만 만든 Collection에서 ADD DATA를 클릭하고 Import JSON을 합니다.

 

13. Check collection data

Import JSON을 한 후 정상적으로 데이터가 로드되었는지 확인합니다.

10. 

14. Miscellaneous

  아래처럼 M10에서 백업 받은 것을 다른 Tier M30에 복구 가능합니다.(낮은 Tier로도 가능)