백업과 복구(WAL, DB Buffer & Cache, PITR, 백업 종류, 롤 포워드)

WOOK JONG KIM·2023년 2월 1일

목록 보기

9/10

ACID 에서 지속성이란 일련의 트랜잭션 동작을 커밋하고 완료 통지를 사용자가 받은 시점에서 그 동작이 영속화 되어 결과를 잃어버리지 않는 것
-> 이는 시스템 장애에 견딜 수 있다는 걸 의미

DBMS에서 데이터를 보존하는 기억장치는 대부분 하드디스크
-> 하드디스크에서 지속성을 실행하려면 쓰기를 전부 동기화 쓰기로 하면 좋겠지만, DB에서 쓰기는 기억장치의 임의 장소에 무작위로 엑세스해서 쓰기를 수행하기 때문에 동기화 쓰기는 느려 성능적으로 실용적이지 않음
-> 지속성과 성능이 양립하도록 일반적으로 DBMS에서는 로그 선행 쓰기 구조를 사용

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

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

DBMS에서 데이터의 정합성과 일관성을 보장하기 위한 프로토콜
-> 시스템이 다운되거나 전원이 중단될 경우, WAL을 이용하여 데이터베이스를 일관된 상태로 복구할 수 있음. 이는 데이터베이스에 변경 사항이 적용되지 않아도, 시스템이 다운되었거나 전원이 중단되어도 데이터베이스가 일관된 상태를 유지할 수 있는 것을 보장

장점

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

데이터베이스 버퍼

WAL 기술을 사용하여 데이터베이스의 변경 내용을 로그에 기록하면, 트랜잭션이 커밋될 때 데이터 파일에 변경 내용을 바로 동기화할 필요가 없음
-> 트랜잭션이 커밋될 때 데이터 파일에 변경 내용을 동기화하는 과정이 필요없어지며, 이는 데이터베이스 처리 속도를 향상
-> 그렇다고 트랜잭션 마다 버퍼를 취해 비동기적인 쓰기를 하면 로그와 데이터 파일 간 일관성을 유지하기 어려움
-> 일반적으로 DBMS에서는 데이터베이스 버퍼를 준비해 데이터 파일로의 입력을 DB 버퍼 경유로 일원화해서 단순화하고 있음

버퍼와 캐시

버퍼란 두 장치간에 입출력 속도 차이로 인한 처리 지연을 방지하기 위하여 도입된 개념
-> 데이터베이스에서 임시로 데이터를 저장하는 공간
-> 디스크에서 메모리로 데이터를 읽어오는 것처럼 디스크와 메모리 간의 속도 차이를 보상하기 위해 사용
-> ex) 컴퓨터나 서버엔 저장장치인 Disk와 연산장치인 CPU가 있음

이때 디스크는 CPU와 비교하면 비교가 안될정도로 느림

예를 들어 하드에서 1개의 연산 데이터를 읽어들여 CPU에 보낼 때, CPU는 분당 100개의 데이터를 처리할 수 있어도 1개의 데이터를 처리할수 밖에 없음
-> 99개의 데이터 영역 처리 공간 및 시간이 지속 대기 및 지연됨(연산 속도 down)
-> 이를 해결 하기 위해 중간에 버퍼가 도입됨

위와 같이 메모리 영역이 중간에 있으면 디스크가 느리더라도 메모리에 1개씩 지속적으로 데이터를 전송하면서 메모리가 보관할 수 있음
-> CPU는 메모리가 디스크로부터 데이터를 지속적으로 받아 적재를 하기 때문에 그 동안 이 작업에 쓸 수 있는 연산 공간을 다른 작업에 사용
-> 메모리가 보관했다가 전송하는 디스크의 일부 데이터를 디스크가 데이터를 모두 전송할때 까지 대기할 필요없이 부분적으로 지속 처리를 하기 때문에 각 요소들이 대기시간으로 인한 성능 지연없이 CPu 연산을 100%까지 사용 가능

캐시란 입출력 처리 속도 지연을 방지하는 것은 버퍼와 유사하나, 여기에 추가적으로 연산 처리를 극대화 하기 위해 도입된 개념
-> ex) DB에서 작업이 필요한 데이터들을 디스크에서 선별하여 메모리에 보관한 후, 이 메모리를 디스크 대신 작업 데이터 보관 공간으로 사용하는 것
-> DB가 디스크로부터 데이터를 지속적으로 조회할 때 이에 따른 성능 저하를 막기위해 캐시를 사용

버퍼,캐시는 두 장치간의 속도 간극을 줄이는데에 목적을 두는건 동일하지만, 버퍼는 속도가 느린 장치에 관점을 두어 속도 간극을 줄이고 캐시는 속도가 빠른 장치에 관점을 두어 속도간극을 줄이는 것에 차이가 있다.

버퍼풀은 버퍼를 관리하는 공간

MySQL 갱신의 흐름

갱신 대상의 데이터를 포함한 페이지(버퍼나 캐시를 다루는 단위)가 버퍼풀에 있는지를 확인하고 없다면 데이터 파일(디스크)로부터 읽어 들임
버퍼풀의 해당 페이지에서 갱신을 수행
2의 갱신 내용이 커밋과 함께 로그에 기록됨. 버퍼 풀에는 갱신되었지만, 아직 데이터 파일에 써지지 않은 페이지는 버퍼 풀 내에서 더티 페이지로 다룸
데이터 페이지는 나중에 적당한 타이밍이 정리되어 데이터 파일로 쓰여짐(체크포인트라 부름)
4의 체크포인트 이전 로그 파일을 불필요 해지며, 갱신과 더불어 1부터 이과정 반복

WAL과 버퍼 풀에 갱신을 반영해가며 데이터 파일보다 앞질러가는 형태가 되고, 체크포인트에서 데이터 파일이 수정사항을 따라잡고 WAL과 버퍼풀이 선행해서 수정하기를 반복

크래시 복구

WAL, DB 버퍼, 데이터 파일 3가지의 연계로 지속성을 담보하면서 DBMS가 동작함

크래시(ex: Mysql 서버의 비정상적 종료)발생 시 어떻게 복구되는지 살펴보자!

크래시 발생시 다음과 같은 상태가 됨

WAL -> 마지막으로 커밋한 트랜잭션의 갱신 정보를 가짐
데이터베이스 버퍼 -> 크래시로 내용이 전부 소실 됨
데이터베이스 파일 -> 최후 체크포인트까지의 갱신 정보를 가짐

크래시 발생 시 데이터베이스 파일과 WAL의 체크 포인트 이후 갱신 정보를 사용해 DB 파일을 크래시 떄까지 커밋된 최신 상태로 수정

PITR이란

PITR(Point-In-Time Recovery)는 데이터베이스 시스템에서 데이터를 복구하는 기술로 특정 시점의 데이터베이스 상태를 복원하는 것을 목적

데이터베이스를 백업하고, 장애가 발생하면 백업으로 복원
-> 하지만 단순이 백업 시점으로만 되돌릴 뿐 백업 후에 데이터베이스에서 수행한 갱신은 반영되지 않음

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

PITR에 사용하는 로그는 대부분 WAL을 이용하는데, WAL을 크래시 복구에만 사용한다면 체크포인트 이전의 로그는 불필요하게 되어 해당 디스크 영역은 삭제하거나 재이용(덮어쓰기) 할 수 있음
-> 하지만 이렇게 된다면 PITR을 수행할 때 필요한 로그가 없는 사태가 발생, 따라서 크래시 복구용으론 불필요한 로그도 PITR용으로 보존하기 위한 모드가 아카이브 지정

오라클에서는 REDO 로그, DB2 & SQL server에서는 트랜잭션 로그를 PITR이나 크래시 복구 둘다에서 이용하지만, MYSQL에서는 PITR에 바이너리 로그, 크래시 복구에 InnoDB 로그 사용

백업의 3가지 관점

장애 발생시 신속하게 대응하기 위해 DB 상태가 정상적일때 현재 이용하는 데이터를 복제해 어딘가 다른 장소로 옮겨 두어야 함(백업)
-> 실제로 장애 발생 시 백업한 데이터에서 데이터베이스의 데이터를 이용할 수 있는 상황까지 복구(복원)

핫 백업(온라인 백업)과 콜드 백업(오프라인 백업)

핫 백업은 백업 대상의 데이터베이스를 정지하지 않고, 가동한채로 백업 데이터를 얻음
-> 주로 데이터베이스의 기능으로 백업

반면 콜드 백업은 백업 대사이 데이터베이스를 정지한 상태로 백업 데이터를 얻음
-> OS의 기능으로 백업

논리 백업과 물리 백업

논리 백업은 SQL 기반의 텍스트 형식으로 데이터베이스의 구조와 데이터를 백업하는 것을 의미
-> 즉, 데이터베이스 구조와 데이터를 텍스트 형식의 SQL 쿼리로 기록

물리 백업은 데이터베이스의 구조와 데이터를 이진 형식으로 복사하여 백업하는 것을 의미
-> 데이터베이스의 물리적인 데이터 파일을 복사하여 백업하는 것이며, 데이터베이스의 데이터를 빠르게 복원할 수 있다는 장점

논리 백업 장단점

텍스트를 변경해 일부 내용 수정 가능
이식성이 우수(동일한 DBMS의 다른 버전이나 다른 DBM에 복원 가능)
물리 백업보다 크기가 큼
바이너리와 텍스트 상호교환에 들어가기 위한 백업과 복원의 동작 속도가 느리다

물리 백업 장단점

최소 크기로 데이터를 얻을 수 있음
데이터 교환이 없거나 적어서 백업과 복원 속도가 빠르다
복원 단위가 도구에 따라 다르며, 일부 데이터의 교환이나 적용 등이 불가능
플랫폼 의존 바이너리는 동일한 DBMS라도 호환하지 않음

풀 백업과 부분 백업

풀 백업은 데이터베이스 전체 데이터를 매일 백업하는 방식
부분 백업은 우선 풀 백업을 한 후에 이후 갱신된 데이터를 백업하는 방식

풀백업은 백업 데이터가 한 군데에 모여 있어서 복원 처리가 단순하나, 데이터베이스 전체를 백업하므로 백업에 시간이 오래 걸리고, 백업 데이터를 저장할 충분한 용량이 필요

부분 백업은 갱신한 데이터만을 대상으로 하므로 백업 시간이 짧고, 백업 데이터의 용량이 작아도 문제가 없으나 복원에는 풀 백업과 부분 백업이 필요해서 복원 절차가 복잡

부분 백업의 2가지 방법

차등 백업 : 풀 백업 이후의 갱신된 데이터를 백업하는 방식

증분 백업 : 최근 백업(풀 백업에 한정되지 않음)한 이후에 갱신된 데이터를 백업하는 방식
-> 차등 백업보다 데이터 양이 적지만 복원 시 모든 증분 백업을 차례로 적용해야 해서 절차가 복잡

롤 포워드 리커버리

롤 포워드란 데이터베이스의 최신 상태로 복구하기 위해, 크래시가 발생한 이후의 변경 정보를 사용하는 과정을 의미하는데 이때 최신 정보를 가진 체크포인트 이후의 트랜잭션 로그(WAL)을 이용해 크래시가 발생한 시점에서 커밋된 최신 상태로 데이터베이스를 복구하는 것
-> WAL은 트랜잭션의 변경 사항을 미리 로그 파일에 기록하여, 오류가 발생할 때 데이터베이스를 복구할 수 있도록 하는 기술
-> 체크포인트는 WAL 로그 파일에 기록된 정보를 기반으로 데이터베이스의 복구점을 정하는 기술

롤 포워드 리커버리란 아카이브를 증분 백업으로 보존하고, 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것을 의미