19.05.04 백업과 복구

-DBMS의 3가지 구조-

 

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

하드디스크에서 지속성을 실현하려면 쓰기를 전부 '동기화쓰기' 로 하면 좋겠지만, 데이터베이스의 쓰기는

기억장치의 임의 장소에 무작위로 액세스해서 쓰기를 수행하기 때문에 동기화 쓰기는 느려서 성능 면에서

실용적이지 않습니다.

그래서 지속성과 성능이 양립하도록 일반적으로 DBMS에서는 3가지 구조를 사용합니다.

 

 

 

-로그 선행 쓰기(WAL)-

 

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

동기화하는 구조입니다.

MySQL 에서는 이 로그를 'InnoDB 로그' 로 부릅니다.

WAL에는 다음과 같은 이점이 있습니다.

 

1. 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.     2. 디스크에 쓰는 용량과 횟수를 줄일 수 있다.     3. 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다.

 

 

 

-데이터베이스 버퍼-

 

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

필요가 없습니다.

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

그래서 일반적인 DBMS에서는 '데이터베이스 버퍼' 를 준비해 데이터 파일로의 입력을 데이터베이스 버퍼 경유로

일원화해서 단순화하고 있습니다.

이 때문에 효율적으로 데이터의 일관성을 유지할 수 있게 됩니다.

MySQL의 경우 갱신의 흐름은 다음과 같습니다.

 

1. 갱신 대상의 데이터를 포함한 페이지가 버퍼풀(버퍼)에 있는지를 확인하고 없다면 데이터 파일로부터 읽어 들인다.     2. 버퍼 풀의 해당 페이지에서 갱신을 수행한다.     3. 2의 갱신 내용이 커밋과 함께 로그에 기록된다. 버퍼풀에 갱신되었지만, 아직 데이터 파일에 써지지 않은 페이지는      버퍼 풀 내에서 더티 페이지(메모리로 읽어서 갱신된 페이지)로 다룬다.     4. 데이터 페이지는 나중에 적당한 타이밍에 정리되어 데이터 파일로 써진다 (이것을 '체크포인트' 라고 부른다.)     5. 4의 체크포인트 이전 로그 파일은 불필요해진다. 또한, 갱신과 더불어 1부터 순서가 반복된다.

 

 

 

-크래시 복구-

 

WAL과 데이터베이스 버퍼, 데이터베이스 파일 3가지가 연계 플레이로 지속성을 담보하면서 현실적인 성능으로 DBMS가 동작하고 있습니다.

크래시 (예를 들면, MySQL 서버의 비정상적 종료)가 발생한 경우의 복구.

 

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

 

1. WAL : 마지막으로 커밋된 트랜잭션의 갱신 정보를 가진다.     2. 데이터베이스 버퍼 : 크래시로 내용이 전부 소실된다.     3. 데이터베이스 파일 : 최후 체크포인트까지의 갱신 정보를 가진다.

 

 

 

-PITR이란?-

 

일반적인 DBMS에서는 데이터베이스에 실행된 갱신을 기록한 로그를 보존해서 그것을 복원한 데이터베이스에 순차 반영해 백업 이후의

임의의 시점으로 복원할 수 있습니다.

이처럼 임의의 시점에서의 데이터 변경을 포함한 복원을 'PITR (Point - in - time Recovery)' 라고 부릅니다.

PITR에 이용되는 로그의 이름과 특성은 DBMS마다 다르다.

 

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 로그는 InnoDB 전용 크래시 복구에만 이용되고, PITR에는 MySQL 전체 (InnoDB에 한정하지 않고) 에서 이용하는

바이너리 로그를 채용합니다.

 

 

 

-백업-

 

장애가 발생하면 데이터베이스의 데이터는 이용할 수 없게 됩니다.

이런 사태에 신속히 대응하기 위해 데이터베이스가 정상적인 상태일 때 현재 이용하는 데이터를 복제해서 어딘가 다른 장소에 옮겨

두어야 합니다. 이 옮겨진 데이터를 '백업 데이터' 라고 하며 이 데이터를 얻어내는 과정을 '백업' 이라고 부릅니다.

장애가 발생하면 신속하게 백업한 데이터에서 데이터베이스의 데이터를 이용할 수 있는 상황까지 복구합니다.

이것이 '복원 (Restore)' 입니다.

 

백업을 수행하는 데는 다음 3가지 관점이 있습니다.

 

1. 핫 백업과 콜드 백업     2. 논리 백업과 물리 백업     3. 풀 백업과 부분 (증분 / 차등) 백업

 

 

핫 백업	콜드 백업
'온라인 백업' 이라고도 하며 백업 대상의 데이터베이스를 정지하지 않고 가동한채로 백업 데이터를 얻습니다. 핫 백업에서는 데이터베이스를 가동한 채로 백업 데이터를 얻는데, 어떤 도구를 사용하는지, 획득 수단은 무엇인지에 따라 차이가 있습니다.	'오프라인 백업' 으로 불리며 백업 대상의 데이터베이스를 정지한 후 백업 데이터를 얻습니다. MySQL에서는 MySQL 서버를 셧다운해서 데이터 디렉터리에 있는 디렉터리와 파일을 전부 OS 명령으로 복사합니다.

 

 

 

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

 

 

 

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

 

 

단원 정리     - 데이터베이스에는 ACID 특성 중 'Durability(지속성)' 에 의해 커밋된 내용이 영속화 되기 때문에 데이터를 잃어버리는 경우는 없다.     - 데이터파일이 있는 파일 시스템의 파손이나 서버, 디스크의 물리 장애에 대비하기 위해 '백업' 프로세스가 필요하다.     - 백업 관점에는 DBMS 정지 여부 (콜드와 핫), 형식 (논리와 물리), 범위 (풀과 차등 / 증분) 가 있다.     - 기본 백업 방식은 풀 백업이지만, 필요에 따라 차등 / 증분 백업을 검토한다.     - 백업에 걸리는 시간과 부하, 복원과 복구에 걸리는 시간을 고려한다.