DB 백업·시점 복구·복제와 고가용성

01오류·질의·변경 로그가 남기는 사실의 차이

• 오류·일반 질의 로그오류 로그는 시작·종료·복구·엔진 장애 등을 설명하고, general query log는 연결과 수신한 질의 등을 기록한다.
• 질의 수신과 커밋수신했다는 기록이 그 SQL이 성공하여 commit되었다는 뜻은 아니다.
• slow query logslow query log는 실행 시간 등 설정 조건에 맞는 질의를 남기므로 일반 질의 전체나 사용자 감사 기록과 목적이 다르다.
• binary log·복제binary log는 복제와 시점 복구에 사용할 변경 스트림이다.
• 설정과 실행 변수서버의 설정 파일과 실제 적용된 변수는 다를 수 있다.

  • 배포판의 기본 파일, include 순서, 시작 인자와 버전에 따라 최종 값이 정해지므로 SHOW VARIABLES로 동작 값을 볼 수 있다.
• general loggeneral log에는 입력값이나 민감한 SQL이 담길 수 있어 공개 자료에는 익명화한 구조만 사용한다.
• 로깅의 비용·노출로그를 켠다는 것은 관찰 정보를 늘리는 동시에 저장 공간·I/O·정보 노출을 늘리는 선택이다.

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'general_log';
SHOW VARIABLES LIKE 'slow_query_log';
-- 변수 이름과 지원 여부는 MySQL/MariaDB 버전에 따라 확인한다.

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

수업 원본 자료

연결 번호와 질의가 이어지는 General Query Log

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. Connect → Query → Quit가 같은 연결 번호 8에 연결된다.
2. show database와 show databases 모두 Query로 기록된다. 잘못된 SQL도 수신 기록에 나타날 수 있어 이 로그만으로 성공 여부를 단정하지 않는다.
3. 오래된 날짜 형식과 제품 환경은 예시일 뿐 현재 서버의 권장 버전·설정이 아니다.

02논리 백업과 물리 백업은 복원 경로가 다르다

• 논리 백업논리 백업은 테이블 정의와 행 데이터를 SQL 또는 논리 형식으로 내보낸다.
• 논리 백업의 이식성사람이 구조를 살펴보거나 다른 환경으로 옮기기 쉽지만 대용량에서는 내보내기와 다시 INSERT하는 시간이 길 수 있다.
• 물리 백업의 호환 조건물리 백업은 DB 파일·페이지를 엔진의 복구 규칙에 맞게 보관하므로 빠를 수 있지만 엔진·버전·포맷 호환성과 일관성 조건이 더 직접적으로 연결된다.
• 실행 중 파일 복사실행 중인 데이터 디렉터리를 파일 복사 도구로 단순 복사하면 각 파일을 읽은 시점이 달라질 수 있다.
• 트랜잭션·로그버퍼에만 있던 변경, 트랜잭션 로그와 데이터 페이지의 순서도 맞아야 한다.
• 일관된 백업 절차제품의 일관된 물리 백업 절차나 DB와 협력하는 스냅샷을 사용하는 이유다.
• 백업스냅샷 자체가 애플리케이션 일관성을 자동 보증하거나 별도 장치 백업이 되는 것은 아니다.

03single-transaction 덤프와 출력 파일의 의미

• 논리 백업MariaDB의 mariadb-dump와 MySQL의 mysqldump는 논리 백업 도구다.
• single-transaction--single-transaction은 주로 InnoDB 같은 트랜잭션 테이블을 일관된 스냅샷으로 읽는 데 쓰인다.
• 트랜잭션·백업비트랜잭션 테이블이나 백업 도중 DDL은 같은 보장을 받지 않을 수 있으므로 자료와 스키마 변경 범위를 통제한다.
• 백업할 객체 범위routines·events·triggers 같은 객체 포함 범위도 데이터 행과 별도로 선택한다.
• 백업명령이 SQL을 표준 출력에 내보내도 파일로 저장하지 않으면 영속 백업 파일이 완성되지 않는다. 아래 예시는 보호된 실습 백업 디렉터리가 이미 있고 전용 계정에 필요한 권한이 있다는 가정이다.
• 암호 전달 방식--password 뒤에 실제 암호를 적지 않으면 대화형 입력을 사용한다.
• 복원·백업파일 권한, 성공 종료 상태, 저장 장치 보존과 복원 가능성까지 이어져야 백업 작업이 된다.

umask 077
mariadb-dump --host=db.example --user=backup --password \
  --single-transaction --routines --events --triggers \
  --databases study > /secure-backup/study.sql
# 교육용 경로이며 덤프 중 DDL·비트랜잭션 테이블 조건은 별도 통제한다.

교육용 예시. 실제 요청·발송·설정 변경을 실행한 결과가 아니다.

04기본 백업과 로그를 연결하는 시점 복구

• 기본 백업기본 백업만 있으면 그 백업 시점으로 돌아갈 수 있다.
• 로그·백업이후 변경 로그를 연속 보관하고 백업과 로그 시작 위치의 관계를 기록하면 지정 시점까지 변경을 다시 적용하는 PITR을 구성할 수 있다.

  • 예를 들어 오전 기본 백업 뒤 오후에 잘못된 삭제가 발생했다면 삭제 직전까지의 로그를 적용하는 목표를 세운다.
• 로그필요한 로그 구간이 하나라도 없으면 원하는 시점까지 이어갈 수 없다.
• RPORPO는 허용 가능한 데이터 손실 범위를 시간 등으로 표현하고 RTO는 복구 완료까지 허용하는 시간을 뜻한다.
• 백업 주기와 손실 범위하루 한 번 덤프라는 일정만으로 두 목표를 모두 만족한다고 말할 수 없다.
• 복원복원된 구조·행 수·업무 합계·문자셋·시간대·계정 권한과 앱 요청이 정상인지, 실제 복원이 얼마나 걸리는지를 격리 환경에서 검증해야 한다.

08복제·승격·quorum과 백업의 관계

• primary·replicaprimary-replica 구조는 primary의 변경을 replica가 받아 적용한다.
• 복제·primary비동기 복제에서는 primary가 성공 응답한 변경을 replica가 아직 받거나 적용하지 못했을 수 있다.
• replica읽기를 replica로 분산하면 막 저장한 자료가 즉시 보이지 않는 상황도 가능하다.
• 동기·반동기 방식동기·반동기 방식은 어느 시점의 응답을 기다리는지에 따라 손실 가능성·지연·가용성의 균형이 달라진다.
• replica·승격장애 때 replica를 승격하면 이전 primary가 동시에 쓰기를 받지 않도록 fencing과 진입점 전환이 필요하다.
• primary네트워크 분할에서 두 집단이 각각 primary라고 생각하면 split-brain이 된다.
• quorumquorum 기반 시스템은 투표와 멤버십으로 이를 제한하지만 제품마다 commit과 복구 규칙이 다르다.
• 복제본복제본에는 삭제와 논리 손상도 전달되므로 고가용성 복제와 과거 정상 상태를 보관한 독립 백업이 서로 보완한다.

09기본 백업 이후의 변경을 재생하기

• 기본 백업·연속 로그어떤 시점의 기본 백업을 확보하고 이후 복구에 필요한 변경 로그를 연속해서 보관한 구성을 생각한다.
• 복원·기본 백업나중에 잘못된 삭제가 발생하면 운영 DB를 그대로 덮어쓰기보다 분리된 복원 환경에서 기본 백업을 준비한다.
• 목표 시점까지 재생필요한 시작 지점부터 로그를 순서대로 적용해 목표 시점 직전 또는 설정한 복구 목표에 도달하게 한다.
• WAL·시점 복구PostgreSQL의 WAL 기반 시점 복구는 이러한 원리를 가진 사례이며 다른 DBMS에서는 로그 명칭과 준비 조건이 다르다.
• 목표 시점목표 시점은 정상 상태로 되돌리고 싶은 업무 기준이다.
• 복구 기준 시각시스템 시계, 시간대와 사건 시각을 잘못 연결하면 삭제 이후까지 재생하거나 필요한 정상 변경을 더 잃을 수 있다.
• 중간 로그 누락복구에 필요한 중간 로그가 하나라도 빠지면 그 이후 목표까지 연속적으로 도달할 수 없을 수 있다.
• 복구 시작 조건또한 기본 백업을 일관되게 복구하는 데 필요한 로그 범위부터 갖춰야 하므로 임의의 데이터 파일 묶음과 최근 로그 몇 개만으로 복구할 수 있다고 가정하지 않는다.

1. 재료 확인기본 백업과 그 복구에 필요한 로그를 대조한다.
2. 목표 결정사건 시각과 시간대를 확인하고 되돌릴 지점을 정한다.
3. 기본 상태 복원분리된 환경에 백업을 준비한다.
4. 목표까지 재생DBMS의 복구 설정에 따라 순서대로 로그를 적용한다.
5. 정합성 확인데이터와 업무 기능을 확인하고 실제 복구 시간·시점을 기록한다.

10복제본이 있어도 복구가 실패하는 이유

• 승격·복제본승격 직전에는 복제본의 로그 적용 위치와 아직 전달되지 않은 변경을 비교해 손실 가능성을 판단한다.
• 복제본·백업최신 복제본과 정상적인 과거 시점의 백업은 서로 다른 복구 수단이다.
• primary이전 primary가 살아났을 때의 쓰기 차단과 진입점 전환은 앞의 승격 절차에 따라 유지한다.
• 행 개수 검증의 한계복원 검증은 행 개수 일치만으로 끝내지 않는다.
• 업무 정합성 검증대표 조회, 참조 관계, 중요한 합계와 업무 처리를 확인하고 계정 권한·암호화 키·확장 기능·설정 파일도 점검한다.
• 복구 환경의 연결 격리복구 환경에서 의도치 않은 외부 메일이나 연동 작업이 실행되지 않도록 서비스 연결을 분리한다.
• 백업·로그백업을 읽고 로그를 재생한 시간에 검증과 전환 시간을 더해야 실제 RTO를 평가할 수 있다.
• 재현 가능한 복원 기록성공한 복원 절차와 실패 원인 기록이 다음 복구의 신뢰도를 높인다.
• 백업마지막으로 복구한 시점과 소요 시간을 기록하고 백업 저장소 접근 권한·키 확보 절차까지 다른 담당자가 재현할 수 있어야 한다.