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

트랜잭션의 특성 중 Durability(지속성)은 시스템이 정상일 때뿐만 아니라 비정상적 종료 등의 시스템 장애에 견딜 수 있다는 것을 의미

DBMS 구조

지속성과 성능의 양립을 위한 DBMS 구조

로그 선행 쓰기 (WAL. Write Ahead Log)

• 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고 우선 로그 변경 내용을 기술한 로그 레코드를 작성하여 동기화하는 구조
• MySQL에서는 InnoDB log라고 부름
• 디스크에 연속하여 write하므로 무작위로 쓰는 것보다 성능이 높음
• 디스크에 쓰는 용량과 횟수를 줄일 수 있음
• 데이터베이스 버퍼를 이용하므로 DB 데이터 파일로 변경 시 효율성이 높음
• Commit 시에는 WAL에 변경 내용을 write하므로 트랜잭션 커밋과 동시에 데이터 파일을 동기화할 필요가 없음

데이터베이스 버퍼

• 트랜잭션마다 비동기 write를 수행하면 로그와 데이터 파일 간의 일관성 유지가 어려움
• 데이터 파일의 입력을 데이터베이스 버퍼로 경유하여 단순화
• 효율적으로 데이터 일관성 유지 가능
• WAL과 버퍼 풀에 갱신이 반영되고, 이후 check point에서 데이터파일에 수정사항이 반영되는 것이 반복됨

• MySQL 갱신 흐름
  1. 갱신 대상의 데이터를 포함한 page가 버퍼 풀에 존재하는지 확인 후 없다면 데이터 파일로부터 읽기
  2. 버퍼 풀의 해당 page에서 갱신 수행
  3. 2번의 갱신 내용이 commit과 함께 log에 기록됨
     • 버퍼 풀에 갱신되었지만, 아직 데이터파일에 써지지 않은 page는 버퍼 풀 내에서 dirty page로 다룸
  4. 데이터 page는 Check Point 때 데이터 파일로 write
  5. Check Point 이전의 로그 파일은 불필요. 갱신과 함께 1번부터 다시 반복

복구

크래시 복구 (Crash Recovery)

• Crash 발생 시 상태
  • WAL : 마지막으로 commit된 트랜잭션의 갱신 정보를 가짐
  • 데이터베이스 버퍼 : 내용이 모두 소실됨
  • 데이터베이스 파일 : 마지막 check point까지의 갱신 정보를 가짐

• Crash 이후 MySQL 서버 재시작 시 Roll-Forward 수행
  • 데이터베이스 파일과 WAL의 check point 이후 갱신 정보를 사용하여 데이터베이스 파일을 Crash 이전까지 commit된 최신 상태로 수정
  • Roll-Forward Recovery: 바이너리 로그를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것
• 논리적 파괴(DDL 문에 의한 테이블 파기 등)나 물리적 파손(디스크 장치 고장 등)에는 이와 같은 대응 불가능
  • 주기적 백업 필요. 장애 발생 시 백업으로 복원

PITR (Point-in-time Recovery)

• 백업을 통한 복구는 백업 이후 갱신이 반영되지 않음
• PITR: 데이터베이스에 실행된 갱신을 기록한 로그를 보존하여(Archive) 로그를 통해 임의의 시점으로 복원하는 것

DBMS	Oracle	MySQL	PostgreSQL	DB2	SQL Server
로그 이름	REDO 로그	바이너리 로그	WAL 로그	트랜잭션 로그	트랜잭션 로그
Archive 지정	O	X	O	O	O
Archive 시 이름	ARCHIVELOG	X	WAL Archive	Archive 로깅	완전 복구 모델
비 Archive 시 이름	NOARCHIVELOG	X	(없음)	순환 로깅	완전 복구 모델

• Archive 지정
  • Crash 복구를 위해 check point 이전의 로그도 보존하는 모드
• 바이너리 로그
  • InnoDB 로그는 InnoDB 전용 crash 복구에만 이용
  • PITR에는 MySQL에서 이용하는 바이너리 로그 사용

백업

핫 백업과 콜드 백업

• Hot Backup
  • 온라인 백업
  • 백업 대상의 데이터베이스를 정지하지 않고 가동한채로 백업 데이터를 얻음
  • MySQL에서의 Hot Backup
    • 주로 OS의 기능으로 백업 데이터를 얻음
    • 트랜잭션 구조 이용, 특수 로그 지정, OS 또는 하드웨어의 스냅샷 등의 방법 존재
    • mysqldump 커맨드라인 클라이언트 유틸리티 사용 가능
• Cold Backup
  • 오프라인 백업
  • 백업 대상의 데이터베이스를 정지한 후 백업 데이터를 얻음
  • MySQL에서의 Cold Backup
    • 주로 데이터베이스의 기능으로 백업 데이터를 얻음
    • MySQL 서버를 셧다운하고 데이터 디렉터리 안의 디렉터리와 파일을 OS 명령어로 모두 복사

논리 백업과 물리 백업

• Logical Backup
  • SQL 기반의 텍스트 형식으로 백업 데이터 기록
  • 오픈 소스 데이터베이스에서 주로 이용
• Physical Backup
  • 데이터 영역을 그대로 dump하여 이미지로 바이너리 형식 기록
  • 클로즈드 소스 데이터베이스에서 주로 이용
• 논리 백업과 물리 백업의 장단점
  

풀 백업과 부분(증분/차등) 백업

• Full Backup

  • 전체 백업
  • 데이터베이스 전체 데이터를 백업

• Partial Backup
  

  • 풀 백업 이후 갱신된 데이터 백업
  • 차등(Differential) 백업
    • 풀 백업 이후 갱신된 데이터 백업
  • 증분(Incremental) 백업
    • 어떠한 백업 이후 갱신된 데이터 백업
    • 차등 백업보다 데이터 양이 작지만 복원시 모든 증분 백업을 차례로 적용해야하므로 절차가 복잡함

• 풀 백업과 부분 백업의 장단점
  

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

• 백업 파일들을 물리적으로 떨어진 장치에 각각 보관
• 장치를 지리적으로 떨어진 장소에 보관하면 재해로부터 데이터를 지킬 수 있음
• 장애는 언제든지 일어날 수 있다는 것을 전제로 대책을 세워야 함
• 백업과 복구에 걸리는 시간과 부하를 측정하여 차질 없이 운영 가능해야 함
• 24시간 가동이 필요하다면 핫 백업 필요
• 일정 시간만 운영해도 된다면 콜드 백업을 1일 1회 실행
• VLDB(Very Large Data Base) 운용 시 논리 백업에는 너무 많은 시간이 소요되므로 물리 백업을 사용