9장 ) 백업과 복구

Reference : 데이터베이스 첫걸음

 

9장 ) 백업과 복구

 

지속성과 성능이 양립하는 구조

DBMS의 3가지 구조

트랜잭션의 ACID 중에서, C는 지속성으로, 이렬ㄴ의 데이터 동작을 완료하고 완료통지를 사용자가 받은 시점에서 그 동작이 '영속화'되어 결과를 잃어버리지 않는 것을 나타낸다.

데이터베이스의 쓰기는 기억장치의 임의 장소에 무작위로 액세스해서 쓰기를 수행하기 때문에 동기화 쓰기는 느려서 성능면에서 실용적이지 않다. 따라서 다음 구조를 사용한다.

1. 로그 선행 쓰기
   • 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 우선 로그로 변경 내용을 기술한 로그 레코드를 써서 동기화하는 구조이다.
   • 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.
   • 디스크에 쓰는 용량과 횟수를 줄일 수 있다.
   • 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다.
2. 데이터베이스 버퍼
   • 커밋 시에는 WAL에 변경 내용을 쓰기 때문에 데이터 파일의 변경 내용은 트랜잭션이 커밋되면서 동시에 동기화 할 필요가 없다.
3. 크래시 복구
   • 크래시 이후 MySQL 서버를 재시작했을 때 데이터베이스 파일과 WAL의 체크포인트 이후 갱신 정보를 사용해 데이터베이스 파일을 크래시 때까지 커밋된 최신상태로 수정한다.

 

 

백업과 복구

• 일반적인 DBMS에서는 데이터베이스에 실행된 갱신을 기록한 로그를 보존해서 그것을 복원한 데이터베이스에 순차 반영해 백업 이후의 임의의 시점으로 복원할 수 있다.
• 임의의 시점에서의 데이터 변경을 포함한 복원을 PITR이라고 부른다.

 

백업의 3가지 관점

• 핫 백업과 콜드 백업
  
  • 핫 백업 : 온라인 백업이라고도 하며, 백업 대상의 데이터베이스를 정지하지 않고 가동한채로 백업 데이터를 얻는다. 어떤 도구를 사용하는지, 획득 수단은 무엇인지에 따라 차이가 있다.
  • 콜드 백업 : 오프라인 백업으로 불리며, 백업 대상의 데이터베이스를 정지한 후 백업 데이터를 얻는다. 데이터베이스 정지 중에는 일반적으로 데이터 저장 파일을 OS로 다루는 상태가 되므로 이를 백업해 백업 데이터를 얻는다.
• 논리 백업과 물리 백업
  • 논리백업 : SQL 기반의 텍스트 형식으로 백업 데이터가 기록된다.
  • 물리백업 : 데이터 영역을 그대로 덤프하는 이미지로 바이너리 형식으로 기록된다.

  • 구분	논리백업	물리백업
    장점	편집할 수 있다. 텍스트를 변경해 백업된 내용 일부를 수정할 수 있다. 이식성이 우수하다. 텍스트 변경으로 동일한 DBMS의 다른 버전이나 다른 DBMS에 복원할 수 있다.	최소 크기로 데이터를 얻을 수 있다. 데이터의 교환이 없어서 백업과 복원속도가 빠르다.
    단점	물리 백업보다 크기가 크다. 바이너리 텍스트 상호교환에 들어가기 위한 백업과 복원의 동작 속도가 느리다.	복원 단위는 도구에 따라 다르며 일부 데이터의 교환이나 적용 등이 불가능하다. 플랫폼 의존 바이너리는 동일한 DBMS라도 호환되지 않는다.

• 풀 백업과 부분 백업
  • 풀백업 : 전체 백업이라고도 하며, 데이터베이스 전체 데이터를 매일 백업하는 방식
  • 부분 백업 : 우선 풀 백업을 한 후에 이후 갱신된 데이터를 백업한다.

  • 구분	풀백업	부분 백업
    장점	백업 데이터가 한군데에 모여 있어서 복원 처리가 단순하다.	갱신한 데이터만을 대상으로 하므로 백업에 필요한 시간이 짧고, 백업 데이터의 용량이 작아도 문제 없다.
    단점	데이터베이스 전체를 백업하므로 백업에 걸리는 시간이 길다. 갱신량이 적어도 매일 데이터베이스 전체를 백업하므로 백업 데이터를 저장하는데 충분한 용량이 필요하다.	복원에는 풀 백업과 부분 백업이 필요해서 복원 절차가 복잡하다.

 

롤 포워드 리커버리

• 바이너리 로그를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것.
• 현재의 데이터베이스 = 풀 백업한 데이터 + 풀 백업 후 얻은 모든 증분 백업

 

데이터베이스 관리 시 주의점

• 전체를 하나의 디스크에 보관해서는 안된다.
• 장치를 지리적으로 떨어진 장소에 둔다면 서버와 디스크가 설치된 장소 자체의 장애에서 데이터를 지킬 수 있다.
• '장애는 언제든지 일어날 수 있음'을 전제로 대책을 세워 되도록 그 비율을 줄이기 위해 노력해야한다.
• 장애 대비 방법을 선택할 때 현재 사용하는 DBMS에 어떠한 대책이 있으며 어떤 방법이 좋은가를 고민해야한다.