[MySQL] 백업과 복구

백업과 복구

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

DBMS의 3가지 구조

• 트랜잭션에는 지속성이라는 성질이 있음
• 시스템 장애에도 지속성을 유지할 수 있어야함
• DBMS 에서는 지속성과 성능이 양립할 수 있도록 하고 있음

로그선행 쓰기(WAL)

• 데이터 파일 변경을 직접 수행하지 않고 로그를 먼저 변경하고 변경사항을 기록한 로드 레코드를 써서 동기화 하는 구조
• MySQL에서는 이 로그를 InnoDB 로그로 부름
• WAL 의 장점
  1. 디스크에서 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋다.
     • 트랜잭션이 발생하게 되면 이를 모두 Sequential 한 Log 형태로 보관
  2. 디스크에 쓰는용량과 횟수를 줄일 수 있다.
     • Sequential 형태로 데이터를 나열하게 되면 특별한 연산이 필요가 없고 디스크 헤더 움직이도 적기 때문에 빠르게 디스크에 데이터 블럭을 만들 수 있다.
  3. 데이터베이스 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행하다.

데이터베이스 버퍼

• WAL에 변경 내용은 트랜잭션이 커밋되면서 동시에 동기화 할 필요는 없음
• 그러나 계속해서 이러한 비동기적인 쓰기를 한다면 일관성 유지가 어려움
• 그래서 일반적으로 '데이터베이스 버퍼' 를 준비해서 데이터 파일로의 입력을 버퍼 경유로 일원화 한다.
• 흐름은 아래와 같다.
  1. 갱신 대상의 데이터를 디스크로부터 페이지 단위로 버퍼 풀로 가지고 온다.
  2. 버퍼 풀의 해당 페이지에서 갱신을 수행한다.
  3. 갱신 내용은 커밋과 함께 로그(WAL)에 기록이 된다.
  4. 버퍼 풀에서 갱신 되었지만, 아직 디스크에 써지지 않은 페이지는 버퍼 풀 내에서 더티 페이지로 다룬다.
  5. 해당 더티 페이지는 적당한 타이밍에 정리되면서 데이터 파일로 써진다. 해당 작업을 체크 포인트라고 부른다.
  6. 5의 체크 포인트 이전 로그 파일은 불필요 해진다.
• WAL과 버퍼 풀에 갱신을 반영해 가며 디스크보다 앞질러 가는 형태가 됨
• 체크포인트를 기준으로 디스크가 수정사항을 따라가고 WAL과 버퍼풀이 선행해서 갱신 작업을 진행한다.

크래시 복구

• 크래시(MySQL 서버 비정상 종료 등) 가 발생한 경우에는 다음과 같은 상태가 됨
  • WAL : 마지막으로 커밋된 트랜잭션의 갱신 정보를 가진다.
  • 데이터베이스 버퍼 : 크래시로 내용이 전부 소실
  • 데이터베이스 파일 : 최후 체크포인트까지 갱싱 정보를 가진다.
• 크래시 이후 MySQL 서버를 재시작하면 WAL 과 데이터베이스 파일 의 체크포인트 이후 갱신 정보를 사용해 데이터베이스 파일을 크래시 때까지 커밋된 최신 상태로 수정합니다.
• 이런 동작을 '롤 포워드(Roll-Forwar)' 라고 함

데이터베이스(한빛미디어, 미크, 기무라 메이저 공저) 첫걸음 그림 9-2

• 다만 물리적인 파손에는 해결이 불가능 하다.
• 그렇기 떄문에 주기적인 백업 방안을 구축해야 한다.

백업과 복구

RITR 이란

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

백업의 3가지 관점

• 데이터 베이스가 정상적인 상태일 때 현재 이용하는 데이터를 복제를 해두어야 한다.
• 이러한 복제된 데이터를 '백업 데이터' 라고 하며 데이터를 얻어내는 과정을 '백업' 이라고 한다.
• 장애가 발생하면 백업한 데이터에서 데이터베이스의 데이터를 이용할 수 있는 상황까지 복구하는 과정을 '복원' 이라고 합니다.
• 백업을 수행하는 데는 3가지 관점이 있음
  1. 핫 백업과 콜드 백업
  2. 논리 백업과 물리 백업
  3. 풀 백업과 부분(증분/차등) 백업

핫 백업과 콜드 백업

핫 백업

• '온라인 백업' 이라고도 함
• 백업 대상의 데이터베이스를 정지하지 않고 가동한 채로 백업 데이터를 얻는다.

콜드 백업

• '오프라인 백업' 이라고도 함
• 데이터베이스를 정지한 상태에서 백업 데이터를 얻는다.
• 정지 중에는 일반적으로 데이터 저장 파일을 OS로 다루는 상태가 되므로 이를 백업해 백업 데이터를 얻는다.

차이

• 콜드 백업은 'OS의 기능' 으로 백업하지만, 핫 백업은 주로 '데이터베이스의 기능' 으로 백업 데이터를 얻습니다.

논리 백업과 물리 백업

• 백업 데이터를 '형식' 에 따라 구분하면 '논리 백업' 과 '물리 백업' 2가지로 나눌 수 있습니다.

논리 백업

• 논리 백업은 SQL 기반의 텍스트 형식으로 백업 데이터가 기록

물리 백업

• 물리 백업은 데이터 영역을 그대로 덤프한 이미지로, 바이너리 형식으로 기록

논리/물리 백업 장/단점

데이터베이스(한빛미디어, 미크, 기무라 메이저 공저) 첫걸음 표 9-2

풀 백업과 부분 백업

• 백업 시 대상과 이에 따른 '데이터의 양' 을 중십으로 본다면 '풀 백업'과 '부분(증분/차등) 백업' 으로 구분

풀 백업

• '전체 백업' 이라고도 하며 데이터베이스 전체 데이터를 매일 백업하는 방식

부분 백업

• 우선 풀 백업을 한 후에, 이후 갱신된 데이터를 백업합니다.

풀/부분 백업 장/단점

데이터베이스(한빛미디어, 미크, 기무라 메이저 공저) 첫걸음 표 9-3

부분 백업의 종류

• 차등 백업과 증분 백업이 있음
• 증분 백업은 데이터의 양이 차등 백업보다 적지만, 복원 시 모든 증분 백업을 차례로 적용해야 해서 절차가 복잡합

데이터베이스(한빛미디어, 미크, 기무라 메이저 공저) 첫걸음 그림 9-5

데이터베이스(한빛미디어, 미크, 기무라 메이저 공저) 첫걸음 그림 9-6

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

• 백업 파일들은 떨어진 곳에 각각 보관하는 것이 중요 (물리적인 문제에 대비)
• 장애 대비 방법을 정할때는 상황에 맞는 백업 방법이 필요 (24시간 가동 필요, 백업 시간, 즉각적 복원 등등)

출처: https://demoversion.tistory.com/91 [Demoversion:티스토리]

백업과 복구