[요약집] 백업과 복구

백업과 복구 - 장애에 대비하는 구조

DBMS의 세가지 구조

• 지속성과 서능이 양립하도록 일반적으로 DBMS에서는 3가지 구조를 사용한다.
  • 로그 선행쓰기, 데이터베이스 버퍼, 크래시 복구
• 로그 선행 쓰기(Write Ahead Log : WAL)
  • 데이터베이스 파일 변경을 직접 수행하지 않고, 우선 로그로 변경내용을 기술한 로그 레코드를 써서 동기화하는 구조이다. MySQL에서는 ‘InnoDB 로그’라고 부른다.
    • 디스크에 차례대로 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.
    • 디스크에 쓰는 용량과 횟수를 줄일 수 있다.
    • 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다
• 데이터베이스 버퍼

  • 일반적인 DBMS 에서는 데이터베이스 버퍼를 준비해 데이터 파일로의 입력을 데이터베이스 버퍼 경유로 일원화해서 단순화한다. 이로써 효율적으로 데이터의 일관성을 유지할 수 있다.

  • 갱신 흐름도

    1. 갱신 대상의 데이터를 포함한 페이지(버퍼나 캐시를 다루는 단위)가 버퍼풀에 있는지 확인하여 없다면 데이터 파일로 부터 읽어드린다.
    2. 버퍼풀의 해당 페이지에서 갱신을 수행한다.
    3. b번의 갱신 내용이 커밋과 함계 로그에 기록된다. 버퍼 풀에 갱신되었지만, 아직 데이터 파일에 써지지 않은 페이지는 버퍼풀 내에서 더티 페이지(일반적으로 메모리로 읽어서 갱신된 페이지)로 다룬다.
    4. 데이터 페이지는 나중에 적당한 타이밍에 정리되어 데이터 파일로 써진다. –> 체크포인트
    5. d번의 체크포인트 이전 로그 파일은 불필요해진다. 갱신과 함계 a번부터 순서를 반복한다.

    

• 크래시 복구

  • 크래시가 발생하면 다음과 같은 상태가 된다. WAL : 마지막으로 커밋된 트랜잭션의 갱신 정보를 가진다. 데이터베이스 버퍼 : 크래시로 내용이 전부 손실된다. 데이터베이스 파일 : 최후 체크 포인트까지의 갱신 정보를 가진다.

  • 크래시 이후 재시작하면 WAL과 데이터베이스의 체크포인트 이후 갱신정보를 사용해 데이터베이스 파일을 크래시 때까지 커밋된 최신 상태로 수정한다. 이 동작을 ‘롤 포워드(Roll Forward)’라고 한다.

    

백업과 복구

• PITR(Point-In-Time Recovery)
  • 일반 적인 DBMS에서는 데이터베이스에 실행된 갱신을 기록한 로그를 보존해서(Archive) 그것을 데이터베이스에 순차 반영하여 백업 이후의 임의 시점으로 복원할 수 있다. 즉, 백업시점으로 되돌리면서 그 시점 이후에 반영된 데이터 변경을 포함한 복원을 PITR 이라고 한다.
• 아카이브(Archive) 지정
  • 데이터 베이스 파일에 ‘쓰기’와 ‘크래시 복구’로 인해 로그 체크 포인트가 갱신되면 그 이전의 로그 영역을 삭제하거나 재이용(새로 쓰기)하지 않고 ‘PITR 용으로 보존하기 위한 모드’이다.
• 바이너리 로그
  • MySQL에서 크래시 복구에는 ‘InnoDB 로그를, PITR에는 ‘바이너리 로그’를 사용한다.
• 백업의 3가지 관점
  • 핫 백업과 콜드 백업
    • 핫 백업 : 백업 대상의 데이터베이스를 가동한 채로 백업 데이터를 얻는다. 주로 ‘데이터베이스의 기능’으로 백업 데이터를 얻는다. 트랜잭션의 구조, 특수한 로그 지정, OS 또는 하드웨어의 스냅샷을 이용해 해당 시점의 스냅샷을 백업 데이터로 취득하는 방법이 있다.
    • 콜드 백업 : ‘백업 대상의 데이터베이스를 정지한 후 백업 데이터를 얻는다. OS의 기능으로 백업 데이터를 얻는다. 서버를 셧다운해서 데이터 티렉터리에 있는 디렉터리와 파일을 전부 OS 명령으로 복사한다.
  • 논리 백업과 물리 백업
    • 논리 백업 : SQL 기반의 텍스트 형식으로 데이터가 기록된다. 백업된 내용 일부를 수정할 수 있고 다른 DBMS로의 이식성이 우수하나, 크기가 크며 백업과 복원의 동작 속도가 느리다.
    • 물리 백업 : 데이터 영역을 바이너리 형식으로 백업 데이터가 기록된다. 최소 크기로 백업 데이터를 얻을 수 있고 속도가 빠르지만, 일부 데이터의 교환이나 적용이 불가능하며 다른 DBMS와 호환이 어렵다.
  • 풀 백업과 부분 백업
    • 풀 백업 : 데이터베이스 전체 데이터를 매일 백업하는 방식이다. 백업데이터가 한군데에 모여 있어서 복원 처리가 단순하지만 백업 시간이 길고 충분한 용량이 필요하다.
    • 부분 백업 : 풀백업을 한 후, 이후에 갱신된 데이터를 백업하는 방식이다. 갱신 데이터만을 대상으로 하므로 백업 시간이 짧지만 복원 절차가 복잡하다.
      • 차등(Differential) 백업 : 풀백업 이후 갱신된 데이터와 갱신된(백업된) 이전의 데이터들을 묶어서 매번 백업한다. 백업시 최근에 백업된 차등 백업 데이터를 이용한다.
      • 증분(Incremental) 백업 : 최근 백업 이후 갱신된 데이터를 이전 백업 데이터와 묶지 않고 각각 백업한다(증분). 그렇기에 복원을 할 때에도 모든 증분 백업 데이터를 이용한다. 데이터의 양이 차등 백업보다 적지만 백업을 차례로 적용해야 해서 절차가 복잡하다.

      

• 롤 포워드 리커버리 (Roll-Forward Recovery)
  • 바이너리 로그를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원 가능한 것을 말한다.
  • 현재의 데이터베이스 백업 = 풀백업한 데이터 + 풀 백업후 얻은 모든 증분 백업