9장 백업과 복구

[seokhwan-an]

9장 백업과 복구

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

DBMS의 3가지 구조

• DBMS에서 지속성을 유지하는 것은 서비스가 정상인 상태와 비정상적인 상태 모두에서 적용이되어야한다.
• 단순하게 지속성을 유지하기 위해서는 동기화 쓰기를 하면 좋겠지만 이는 성능적으로 좋지 않다.

💡동기화 쓰기 데이터베이스에서 트랜잭션이나 데이터 변경 작업이 완료되기 전에 디스크에 데이터를 동기적으로 즉시 쓰는 방식이다. 이는 데이터 변경 작업이 커밋되기 전에 해당 변경 사항이 영구적으로 디스크에 기록되어 데이터의 안정성과 일관성을 보장하는 것을 의미한다.

동기화 쓰기의 작동 방식은 다음과 같다.

1. 트랜잭션 실행 : 데이터 변경 작업이 시작되면 해당 트랜잭션은 로그 레코드로 작성되고, 변경 사항이 버퍼에 저장된다.
2. 로그 기록: 트랜잭션에서 수행한 모든 변경 사항은 로그 레코드로 기록된다. 이로 인해 변경 사항은 로그 파일에 먼저 기록되고, 로그 파일은 디스크에 동기적으로 쓰인다.
3. 디스크 쓰기 : 로그 파일에 데이터가 기록된 후에는 해당 변경 사항이 실제 데이터 파일에도 동기적으로 쓰인다. 이로 인해 데이터 변경 사항이 디스크에 반영되어 안정성을 보장된다.

장점

• 변경 사항이 디스크에 안정적으로 기록되어 데이터의 손실이 최소화되며 데이터베이스 시스템의 무결성을 보장한다. 단점
• 디스크 I/O 작업이 더 빈번하게 방생하여 일부 성능 저하를 가져올 수 있다. → 대부분의 데이터베이스 시스템은 변경 사항을 버퍼에 먼저 저장하고 일정 시점에 일괄적으로 디스크에 쓰는 기법을 사용하여 성능과 안정성을 균형있게 조절한다.

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

• 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고 우선 로그로 변경 내용을 기술한 로그 레코드를 이용해 동기화하는 방식 (MySQL에서는 이를 InnoDB 로그라 부른다.

동작 방식

1. 트랜잭션 시작: 트랜잭션이 시작되면, 해당 트랜잭션이 수행하는 모든 데이터 변경 작업은 로그에 기록된다.
2. 로그 기록: 트랜잭션에서 수행한 모든 변경 사항(INSERT, UPDATE, DELETE 등)은 로그 레코드로 작성되어 로그 버퍼에 저장된다.
3. 데이터 파일 변경 대기: 로그에 기록된 변경 사항은 일시적으로 데이터 파일에 적용되기 전까지 대기한다.
4. 커밋: 트랜잭션이 완료되어 커밋되면, 해당 트랜잭션의 로그 레코드가 디스크에 영구적으로 쓰인다.
5. 데이터 파일 변경: 커밋된 로그 레크드를 바탕으로 해당 트랜잭션의 변경 사항이 실제 데이터 파일에 적용된다.

장점

1. 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.
2. 디스크에 쓰는 용량과 회수를 줄일 수 있다.
3. 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행한다.
4. WAL은 데이터 변경이 완전히 로그에 기록된 후에만 해당 변경 사항을 데이터 파일에 적용한다. 이로 인해 데이터 손실이 발생하더라도 로그를 사용하여 데이터를 복구할 수 있다.
5. WAL을 통해 트랜잭션 간 격리 수준이 보장된다. 로그에 기록된 트랜잭션의 변경 사항은 커밋되기 전까지 다른 트랜잭션에 의해 보이지 않는다.

데이터베이스버퍼

• DBMS에서 중요한 역할을 수행하는 메모리 영역으로 주로 디스크와 같은 비휘발성 저장 장치와 메모리 사이에서 데이터의 효율적인 이동과 접근을 관리하는데 이용된다.

MySQL의 갱신 흐름

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

크래시 복구

크래시(DBMS 서버의 비정상적인 종료) 발생시 3가지 파일의 상태

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

크래시 이후에 서버를 재시동하면 WAL의 정보와 데이터베이스 파일의 정보를 이용해 크래시 때까지 커밋된 최신 상태로 데이터베이스 파일을 수정한다. 이를 롤 포워드라 한다.

백업과 복구

앞선 크래시 복구가 설계된 것은 놀랍지만 논리적인 파괴와 물리적인 파괴를 모두 대응할 수 있는 것이 아니기 때문에 지속적인 백업이 필요하다.

PITR

일반적인 DBMS에서는 데이터 갱신을 기록한 로그를 보존해서 이를 복원한 데이터베이스에 순차적으로 반영하여 임의의 시점의 데이터 상태 유지를 할 수 있는데 이를 PITR(Point-In-Time-Recovery)라고 한다.

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

부분 백업의 2가지 방식

• 차등 백업 : 풀 백업한 이후에 갱신된 데이터를 백업하는 방식
• 증분 백업: 최근 백업이 이루어진 이후에 갱신된 데이터만을 백업하는 방식 → 차등 백업에 비해 갱신되는 데이터의 양이 적지만 순서 고료를 해야하므로 절차가 복잡하다

[somefood]

백업

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

• 트랜잭션의 D는 지속성(Durability)로 일련의 데이터 종작을 완료하고 완료 통지를 사용자가 받은 시점에서 그 동작이 영속화 되어 결과를 잃어버리지 않아야 한다. 이는 시스템이 정상일 때뿐만 아니라 DB 서버나 OS의 비정상적 종료 등의 시스템 장애에도 견딜 수 있음을 의미한다.
• DBMS에서 데이터를 보존하는 기억장치는 대부분 하드디스크. 하드디스크에서 지속성을 실현하려면 쓰기를 동기화 쓰기로 하면 조히만, 성능 면에서 좋지 않기에 지속성과 성능이 양립하도록 몇 가지 구조 사용
  • 로그 선행 쓰기(WAL, Write Ahead Log): 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 우선 로그로 변경한 내용을 기술한 로그 레코드를 써서 동기화하는 구조. (MySQL, InnoDB 로그)
    • 디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다
    • 디스크에 쓰는 용량과 횟수를 줄일 수 있다
    • 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행
  • 데이터베이스 버퍼: 커밋 시 WAL 변경 내용을 쓰기 때문에 데이터 파일의 변경 내용은 트랜잭션이 커밋되면서 동시에 동기화할 필요 없지만, 트랜잭션 버퍼를 취해 비동기적인 쓰기를 하면 로그와 데이터 파일 간 일관성을 유지하기 어려움. DBMS에선 데이터베이스 버퍼를 준비해 데이터 파일로의 입력을 데이터 베이스 버퍼 경유로 일원화해서 단순화 함
    1. 갱신 대상의 데이터를 포함한 페이지가 버퍼 풀에 있는지를 확인하고 없다면 데이터 파일로부터 읽어 들인다.
    2. 버퍼 풀의 해당 페이지에서 갱신을 수행한다.
    3. 2의 갱신 내용이 커밋과 함께 로그에 기록된다. 버퍼 풀에 갱신되었지만, 아직 데이터 파일에 써지지 않은 페이지는 버퍼 풀 내에서 더티 페이지로 다룬다.
    4. 데이터 페이지는 나중에 적당한 타이밍에 정리되어 데이터 파일로 써진다. (체크포인트)
    5. 4의 체크포인트 이전 로그 파일은 불필요해지고, 갱신과 더불어 1부터 순서가 반복됨
  • 크래시 복구: 크래시가 발생하면 다음과 같은 상태가 된다. 크래시 이후 MySQL ㅅ버를 재시작하면 3과 1의 체크포인트 이후 갱신 정보를 사용해 데이터베이스 파일을 크래시 때까지 커밋된 최신상태로 수정 (롤 포워드, Roll-Forward)
    • WAL: 마지막으로 커밋된 트랜잭션의 갱신 정보를 가짐
    • 데이터베이스 버퍼: 크래시로 내용이 전부 소실됨
    • 데이터베이스 파일: 최후 체크포인트까지의 갱신 정보를 가짐

논리적인 파괴(DDL 문에 따른 테이블의 파기)나 물리적인 파손(디스크 장치의 고장 등)에는 대응할 수 없기에 DB가 정상적으로 동작하고 있을 때 주기적으로 백업하고 이를 이용해 복원이나 복구하는 것이 좋다.

백업과 복구

PITR(Pointin-time Recovery)

• DB에서 데이터를 다양한 장애에서 지키려면 데이터베이스가 정상적으로 동작할 때 백업하고, 장애가 발생하면 백업으로 복원하여 백업 시점으로 되돌릴 수 있음

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

백업의 3가지 관점

• 장애가 발생하면 데이터를 이용할 수 없기에 정상적인 상태일 때 어딘가에 백업 해두고 신속하게 복원(Restore) 해두어야 함
• 백업을 수행하는 3가지 관점
  1. 핫 백업과 콜드 백업
     • 핫 백업: 온라인 백업이라도 하며, 백업 대상 DB를 정지하지 않고 가동한채로 백업 데이터를 얻음
     • 콜드 백업: 오프라인 백업이라 불리며 정지 후 백업 데이터 얻음
  2. 논리 백업과 물리 백업
     • 논리 백업: SQL 기반의 텍스트 형식으로 백업 데이터가 기록/편집 가능
     • 물리 백업: 데이터 영역을 그대로 덤프하는 이미지로 바이너리 형식으로 기록
  3. 풀 백업과 부분(증분/차등) 백업
     • 풀 백업: 전체 백업, 데이터베이스 전체 데이터를 매일 백업하는 방식
     • 부분 백업: 풀 백업을 한 후에 이후 갱신된 데이터를 백업

[rawfishthelgh]

백업과 복구

• dbms는 acid 중 하나인 지속성을 만족시키기 위해 세 가지의 구조를 사용한다

1. 로그 선행 쓰기(WAL, 바이너리 로그) : 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 로그로 변경 내용을 남긴 후 동기화한다. mysql에서는 이 로그를 inno db 로그라 부른다

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

2. 데이터베이스 버퍼 : 일반적인 dbms는 데이터베이스 버퍼를 준비해 데이터 파일로의 입력을 데이터베이스 버퍼 경유로 일원화해서 단순화한다. 아래와 같은 흐름으로 이루어진다

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

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

3. 크래시 복구 : 충돌이 발생하면 아래와 같은 상태가 됨

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

   충돌 이후 mysql 서버를 재시작하면, a와 c의 체크포인트 이후 갱신 정보를 사용해 데이터베이스 파일을 충돌 전까지 커밋된 최신 상태로 수정함. 이를 “롤 포워드”라 한다

백업과 복구

일반적인 dbms에서는 데이터베이스에 실행된 갱신을 기록한 로그를 보존해서 이를 복원한 데이터베이스에 순차 반영함으로써 백업 이후의 임의의 시점으로 복원할 수 있음. 이처럼 임의의 시점에서의 데이터 변경을 포함한 복원을 PITR(Point In Time Recovery)라 한다

아카이브 지정

wal을 크래시 복구에만 이용한다면 체크포인트 이전의 로그는 불필요하고 이를 삭제하거나 재이용할 수 있음. 그러나 이 경우 pitr을 수행하고 싶을 때 로그가 없는 경우 발생. 따라서 pitr용으로 불필요 로그를 보존하는 것을 “아카이브 지정”이라 함

백업의 3가지 관점

장애 시 대응을 위해 데이터베이스가 정상적일 때 복제해서 어딘가 다른 장소에 옮겨 두는데, 이를 백업 데이터라 함. 백업은 3가지 관점이 있음

1. 핫 백업과 콜드 백업
2. 논리 백업과 물리 백업
3. 풀 백업과 부분 백업

핫 백업과 콜드 백업

백업 시 데이터베이스의 상태에 따라 구분한 것이다. 핫 백업은 “온라인 백업”이라고도 하며 백업 대상의 데이터베이스를 정지하지 않고 가동한채로 백업 데이터를 얻는다. 콜드 백업은 “오프라인 백업”이라고도 불리며 백업 대상의 데이터베이스를 정지한 후 백업 데이터를 얻는다

• 핫 백업 : 데이터베이스를 가동한 채로 백업 데이터를 얻음. mysql에서는 트랜잭션의 구조나, 특수한 로그나, os 또는 하드웨어의 스냅샷을 이용해 해당 시점의 스냅샷을 백업 데이터를 취득함. mysql은 핫 백업시 mysqldump라는 커맨드라인 클라이언트 유틸리티를 이용함
• 콜드 백업 : 데이터베이스 정지 상태에서 데이터 얻음. 서버가 꺼지므로 dbms가 아닌 os의 기능으로 백업해야 함. mysql에서는 서버를 셧다운 해서 데이터 디렉터리에 있는 디렉터리와 파일을 전부 os 명령으로 복사함.
• 콜드백업은 os의 기능을 사용하고, 핫백업은 dbms의 기능을 사용하는 차이

논리 백업과 물리 백업

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

논리 백업은 sql 기반의 텍스트 형식으로 기록되고, 물리 백업은 데이터 영역을 그대로 덤프하는 이미지로 바이너리 형식으로 기록됨. 장단점은 다음과 같음

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

풀 백업과 부분 백업

백업 대상과 이에 따른 데이터의 양을 중심으로 구분한 것.

풀 백업은 데이터베이스 전체를 매일 백업하는 것이고, 부분 백업은 풀 백업 이후 갱신된 데이터를 백업하는 것. 장단점은 아래와 같음

• 풀 백업
  • 장점 :
    • 백업 데이터가 한 곳에 모여 있어서 복원 처리가 단순함
  • 단점 :
    • 데이터베이스 전체를 백업하므로 백업에 걸리는 시간이 김
    • 갱신량이 적더라도 전체를 백업해야 하므로 백업 데이터를 저장하는 데 충분한 용량이 필요
• 부분 백업
  • 장점 :
    • 갱신한 데이터만 대상이므로 시간이 짧고 백업 데이터의 용량이 작아도 문제 x
  • 단점 :
    • 복원 시 풀 백업과 부분 백업이 필요해서 복원 절차가 복잡(무슨말?)

부분 백업의 2가지 방법

풀 백업 이후 갱신된 데이터를 백업하는 차등 백업과, 백업의 종류 상관없이 이후 갱신 데이터를 백업하는 증분 백업이 있다. 증분 백업은 데이터의 양이 차등 백업보다 적지만, 복원시 모든 증분 백업을 차례로 적용해야 해서 절차가 복잡함.

차등 백업은 풀 백업 이후 갱신된 데이터 모두를 백업하고, 증분 백업은 처음에 풀 백업을 한 후 그 이후는 전일로부터 증분된 데이터만 백업 함.

롤 포워드 리커버리

mysql은 wal을 출력할 수 있으므로 바이너리 로그를 증분 백업으로 보존하고, 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것이 가능함. 이를 “롤 포워드 리커버리”라 한다.

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

위와 같은 형태로 현재 데이터베이스를 표현할 수 있고, 이 의미는 풀 백업과 증분 백업으로 현재 데이터베이스를 복구할 수 있는 것을 의미함

데이터베이스 관리 주의점

백업 파일은 떨어진 곳에 각각 보관해야 함. 전체를 하나로 관리하면 파손 시 백업 데이터와 사용 중인 데이터베이스를 동시에 잃어버림

장애 대비 방법을 선택할 때, 24시간 가동해야 하는 조건이 있으면 핫 백업을, VLDB(매우 큰 db)를 운용한다면 논리 백업은 시간이 많이 걸리니 물리 백업을, 갱신 범위가 매우 한정되어 있다면 차등 백업을, 데이터베이스를 운용하지 않는 시간이 존재한다면 db를 정지하고 콜드 백업을 사용할 수도 있다.

[seokhwan-an]

https://hudi.blog/mysql-pit-recover/
[MySQL] 백업