백업과 복구

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

DBMS의 세가지 구조

트랜잭션의 특징인 ACID 중 

Durability : 

트랜잭션 동작을 완료(COMMIT)하고 사용자가 완료 통지를 받은 시점에서 그 동작이 영속화되어 그 결과를 잃어버리지 않는 속성. DB서버나 OS의 비정상적인 종류 등의 시스템 장애에 견딜 수 있는 영속성

DBMS에서 데이터를 보존하는 기억장치는 대부분 하드디스크. 

하드디스크에서 지속성을 실현하려면 쓰기를 전부 '동기화 쓰기'로 하면 좋겠지만 데이터베이스의 쓰기는 기억장치의 임의의 장소에 무작위로 액세스하여 쓰기를 수행하기 때문에 동기화쓰기는 성능(속도)면에서 실용적이지 않다.

지속성과 성능이 양립하도록 사용하는 DBMS의 세 가지 구조 

  - 로그 선행쓰기 

  - 데이터베이스 버퍼 

  - 크래시 복구

-로그 선행쓰기(WAL, Wrute Ahead Log)

데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 우선 로그로 변경한 내용을 기술한 로그 레코드를 써서 동기화하는 구조

MySQL에선 이 로그를 'InnoDB(MySQL의 버퍼풀) 로그'로 부름.

WAL의 장점

1. 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.

2. 디스크에 쓰는 용량과 횟수를 줄일 수 있다.

3. 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다.

-데이터베이스 버퍼

커밋 시에는 WAL에 변경 내용을 쓰기 때문에 데이터 파일의 변경 내용은 트랜잭션이 커밋되면서 동시에 동기화할 필요가 없다. <<?

그렇다고 트랜잭션마다 버퍼를 취해 비동기적인 쓰기를 하면 로그와 데이터 파일 간 일관성을 유지하기 어렵다.

일반적인 DBMS는 데이터베이스 버퍼를 준비해 데이터파일로의 입력을 DB버퍼 경유로 일원화하여 효율적으로 데이터의 일관성 유지

MySQL의 데이터 갱신 흐름

1. 갱신 대상의 데이터를 포함한 페이지가 버퍼 풀에 있는지 확인하고 , 없다면 데이터 파일로부터 읽어들인다.

2. 버퍼 풀의 해당 페이지에서 갱신을 수행한다.

3. 갱신 내용이 커밋과 함께 로그에 기록된다. 

   버퍼 풀에 갱신되었지만 아직 데이터파일에 써자지 않은 페이지는 버퍼 풀 내에서 더티페이지로 다룬다.

4. 데이터 페이지는 나중에 적당한 타이밍에 정리되어 데이터 파일로 써진다.(이것을 '체크포인트'라고 부른다.)

5. 체크포인트 이전 로그 파일은 불필요해진다. 또한 갱신과 더불어 1번부터 순서가 반복된다.

정리                                  

: 버퍼풀에서 데이터파일을 읽어들임 ▶ 버퍼풀에서 갱신 수행 ▶ 커밋과 함께 로그에 기록 ▶ 데이터파일에 반영(체크 포인트)

   (기록 전 갱신 페이지 : 더티페이지)

-크래시 복구

Crash : 비정상적인 종료

WAL과 데이터베이스 버퍼, 데이터베이스 파일 3가지가 연계 플레이로 지속성을 담보하면서 동작하는 중 크래시가 발생한 경우 복구 방법

크래시가 발생하면 다음과 같은 상태가 된다.

1. WAL : 마지막으로 커밋된 트랜잭션의 갱신 정보를 가진다.

2. 데이터베이스 버퍼 : 크래시로 내용이 전부 소실됨.

3. 데이터베이스 파일 : 최후 체크포인트까지의 갱신정보를 가진다.

롤 포워드 : WAL의 체크포인트 이후의 갱신정보를 사용해 크래시때까지 커밋된 최신 상태로 수정하는 동작

이와같은 구조도 논리적인 파기(DDL 문에 따른 테이블의 파기 등)나 물리적인 파손에는 대응할 수 없으므로 주기적인 백업이 필요

백업과 복구

PITR :

백업으로 복원해도 백업 이후에 수행한 갱신은 반영되지 않는다. 일반적인 DBMS는 DB에 실행된 갱신을 기록한 로그를 보존(Archive)해서 복원한 데이터베이스에 순차 반영해 백업 이후의 임의의 시점으로 복원가능 한데, 이처럼 임의의 시점에서의 데이터변경을 포함한 복원을 PITR( Point-in-time Recovery ) 라 한다.

DBMS별 PITR

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

아카이브 지정 : 

PITR에 이용되는 로그는 대부분 WAL 이용. 이 때문에 WAL을 크래시 복구에만 이용한다면 체크포인트 이전의 로그는 불필요하게 되어 해당 디스크 영역을 삭제하거나 재이용할 수 있다. 하지만 이렇게 되면 PITR를 수행하고 싶을 때 필요한 로그가 없는 사태가 발생한다.

따라서 크래시 복구용으로는 불필요한 로그도 PITR용으로 보존이 필요할 수 있으며 이를 위한 모드가 '아카이브 지정'

바이너리 로그 :

MySQL애서 PITR에는 바이너리 로그를 이용. 

InnoDB(버퍼풀) 로그는 InnoDB 전용 크래시 복구에만 이용되고, 

PITR에는 MySQL 전체(InnobDB에 한정하지 않고) 에서 이용하는 바이너리 로그를 채용.

Oracle의 REDO 로그, DB2와 SQL Server의 트랜잭션 로그는 PITR와 크래시 복구 둘 다에서 이용한다.

백업의 3가지 관점

• 핫백업 /  콜드 백업

DB의 상태에 따라 구분

-핫백업 : 온라인 백업, 백업대상의 데이터베이스를 정지하지 않고 가동한채로 데이터베이스를 얻음. ( 백업 중에도 DB 가동)

-콜드백업 : 오프라인 백업, 백업 대상의 데이터베이스를 정지한 후 백업 데이터 얻음 ( 백업 중에는 DB에 접근 불가)

 (자세한 내용은 이해못함)

• 논리 백업 / 물리 백억

백업 데이터 형식에 따라 구분

-논리 백업 : SQL 기반의 텍스트 형식으로 백업 데이터 기록 ( 텍스트 형식 )

-물리 백업 : 데이터 영역을 그대로 덤프(데이터 파일이나 화면에 출력)하는 이미지로 기록 ( 바이너리 형식 )

논리백업과 물리백업의 장단점

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

• 풀 백업 / 부분 백업

백업 시 대상과 데이터 양을 중심으로 구분

- 풀 백업 : 전체 데이터를 매일 백업

- 부분 백업 : 우선 풀 백업을 한 후에 이후 갱신된 데이터를 백업

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

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

부분 백업의 두가지 방법

-차등(Differential) 백업 : 풀백업 이후 갱신된 데이터를 백업

-증분(Incremental) 백업 : 최근 백업(풀백업에 한정되지 않음)한 이후에 갱신된 데이터를 백업

롤 포워드 리커버리(Roll-Forward Recovery)

롤 포워드 : WAL의 체크포인트 이후의 갱신정보를 사용해 크래시때까지 커밋된 최신 상태로 수정하는 동작

바이너리 로그(MySQL의 WAL)를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 거이 가능

앞서 나온 롤 포워드와 같은 퍼리로, 바이너리 로그를 사용한다는 부분만 다르다.

현재의 데이터베이스 = 풀 백업한 데이터 + 풀 백업 후 얻은 모든 증분 백업

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

백업 파일들은 DB와 물리적으로 떨어진 곳에 각각 보관해야 안전

위 내용을 활용하여 장애 대비 방법을 선택

24시간 가동해야하는 경우에는 핫백업이 필요하며, 

VLDB(Very Large) 운용한다면 논리백업 대신(시간이 너무 오래걸린다) 물리 백업을 해야한다.

갱신 범위가 매우 한정되어 있다면 차등 백업이 유효할 수 있으며

데이터베이스를 정지해도 되는 상황이라면 콜드백업을 1일 1회 실행한다.

*CSV : 쉼표를 기준으로 항목을 구분하여 저장한 데이터

*바이너리 : 본래는 2진수로 표시되는 데이터의 의미지만, 일반적으로 바이너리라고 한다. 텍스트 동의 문자로서의 의미를 가진 데이터에 대하여 프로그램의 동작을 결정하는 것, 또는 일정한 포맷에 따라 기록되는 데이터를 말한다