12장 : 복구와 로깅
복구 실무
이론적인 복구 원리를 이해했다면, 실무에서 사용하는 Oracle의 복구 도구와 백업 전략을 다룹니다. 복구 실무는 DBA의 핵심 역량이며, 장애 발생 시 데이터 손실을 최소화하면서 서비스를 빠르게 정상화하는 것이 목표입니다.
복구의 분류
데이터베이스 복구는 장애 유형과 범위에 따라 분류됩니다.
Database Recovery
│
├─ 인스턴스 복구 (Instance Recovery)
│ └─ 비정상 종료 후 자동 복구
│ └─ Redo 적용(롤포워드) → DB 오픈 → Undo 적용(롤백)
│
├─ 미디어 복구 (Media Recovery)
│ ├─ 완전 복구 (Complete Recovery)
│ │ └─ 장애 시점까지 모든 데이터 복원
│ └─ 불완전 복구 (Incomplete Recovery)
│ ├─ 시점 복구 (Point-in-Time Recovery)
│ ├─ SCN 기반 복구
│ └─ 로그 시퀀스 기반 복구
│
└─ 논리적 복구
├─ Flashback 기술
└─ Data Pump Import| 복구 유형 | 원인 | 자동/수동 | 도구 |
|---|---|---|---|
| 인스턴스 복구 | 정전, 프로세스 크래시 | 자동 | Oracle 자동 수행 |
| 완전 미디어 복구 | 디스크 손상, 파일 유실 | 수동 | RMAN |
| 불완전 미디어 복구 | 사용자 실수, 논리적 오류 | 수동 | RMAN + RESETLOGS |
| Flashback | 잘못된 DML, DROP 실수 | 수동 | SQL / RMAN |
Oracle 인스턴스 복구
Oracle 인스턴스(서버 프로세스)가 비정상 종료된 후 재시작하면 자동으로 인스턴스 복구가 수행됩니다. DBA가 별도로 명령을 실행할 필요 없이 STARTUP 시 자동으로 진행됩니다.
인스턴스 시작 (STARTUP)
│
▼
┌─────────────────────┐
│ 1. Redo 로그 읽기 │ 체크포인트 이후 ~ 장애 시점
│ (Online Redo Log)│ 마지막 체크포인트 SCN 확인
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ 2. 롤포워드 (Redo) │ 커밋된 + 미커밋 모든 변경 재적용
│ 캐시 복구 │ → 장애 직전 상태 복원
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ 3. 데이터베이스 열기│ 사용자 접속 가능
│ (OPEN) │ 서비스 재개
└─────────┬───────────┘
│
▼
┌─────────────────────┐
│ 4. 롤백 (Undo) │ 미완료 트랜잭션 되돌림
│ 백그라운드 수행 │ SMON 프로세스가 처리
│ (Transaction │ 블록 단위로 점진적 수행
│ Recovery) │
└─────────────────────┘롤백은 데이터베이스를 연 후 백그라운드로 진행되므로, 사용자는 빠르게 접속할 수 있습니다. 이를 Fast-Start Instance Recovery라고 합니다.
FAST_START_MTTR_TARGET = 300
→ 인스턴스 복구 목표 시간을 300초(5분)로 설정
→ Oracle이 체크포인트 빈도를 자동 조절
→ 값이 작으면: 체크포인트 빈번 → 복구 빠름 → 정상시 I/O 증가
→ 값이 크면: 체크포인트 드문 → 복구 느림 → 정상시 I/O 감소
V$INSTANCE_RECOVERY 뷰로 예상 복구 시간 확인:
SELECT TARGET_MTTR, ESTIMATED_MTTR,
CKPT_BLOCK_WRITES
FROM V$INSTANCE_RECOVERY;RMAN (Recovery Manager)
RMAN은 Oracle의 표준 백업·복구 도구입니다. OS 명령어(cp, tar)로 파일을 복사하는 것보다 안전하고 효율적입니다.
1. 블록 수준 백업
→ 사용 중인 블록만 백업 (빈 블록 스킵)
→ 백업 크기 절약
2. 증분 백업 (Incremental)
→ 변경된 블록만 백업
→ Block Change Tracking으로 변경 블록 빠르게 식별
3. 손상 감지
→ 백업 중 블록 손상(corruption) 자동 감지
→ V$DATABASE_BLOCK_CORRUPTION에 기록
4. 압축 백업
→ COMPRESSED BACKUPSET으로 압축
→ 저장 공간 50~75% 절약
5. 카탈로그 관리
→ 제어 파일 또는 Recovery Catalog에 백업 메타데이터 관리
→ 어떤 백업이 있고 어디까지 복구 가능한지 자동 추적──── RMAN 접속 ────
$ rman target / -- 로컬 접속
$ rman target sys/pwd@orcl catalog rman/pwd@catdb -- 카탈로그 사용
──── 백업 ────
-- 전체 백업 (데이터파일 + 제어 파일 + 아카이브 로그)
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
-- 증분 백업 (레벨 0 = 전체, 레벨 1 = 변경분)
RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
-- 테이블스페이스 백업
RMAN> BACKUP TABLESPACE users_ts;
-- 압축 백업
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE;
-- 특정 데이터파일 백업
RMAN> BACKUP DATAFILE '/oradata/users01.dbf';
──── 복구 ────
-- 전체 복구
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
-- 테이블스페이스 복구 (온라인 상태에서)
RMAN> SQL 'ALTER TABLESPACE users_ts OFFLINE IMMEDIATE';
RMAN> RESTORE TABLESPACE users_ts;
RMAN> RECOVER TABLESPACE users_ts;
RMAN> SQL 'ALTER TABLESPACE users_ts ONLINE';
-- 데이터파일 복구
RMAN> SQL 'ALTER DATABASE DATAFILE 5 OFFLINE';
RMAN> RESTORE DATAFILE 5;
RMAN> RECOVER DATAFILE 5;
RMAN> SQL 'ALTER DATABASE DATAFILE 5 ONLINE';RMAN 증분 백업 상세
증분 백업은 전체 백업 대비 시간과 공간을 크게 절약합니다.
레벨 0: 기준 백업 (모든 블록 백업)
레벨 1: 레벨 0 이후 변경된 블록만 백업
┌─────────────────────────────────────────────────────┐
│ 증분 백업 전략 비교 │
├──────────────────────┬──────────────────────────────┤
│ 차등 (Differential) │ 누적 (Cumulative) │
│ LEVEL 1 │ LEVEL 1 CUMULATIVE │
├──────────────────────┼──────────────────────────────┤
│ 일 Level 0 ████████ │ 일 Level 0 ████████ │
│ 월 Level 1 █ │ 월 Level 1 █ │
│ 화 Level 1 █ │ 화 Level 1 ██ │
│ 수 Level 1 █ │ 수 Level 1 ███ │
│ 목 Level 1 █ │ 목 Level 1 ████ │
│ 금 Level 1 █ │ 금 Level 1 █████ │
│ 토 Level 1 █ │ 토 Level 1 ██████ │
├──────────────────────┼──────────────────────────────┤
│ 백업 시간: 짧음 │ 백업 시간: 점점 늘어남 │
│ 복구 시: L0+모든L1 │ 복구 시: L0+마지막L1 │
│ 복구 시간: 길 수 있음│ 복구 시간: 빠름 │
└──────────────────────┴──────────────────────────────┘-- 변경 블록 추적 활성화 (증분 백업 성능 향상)
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/oradata/bct/change_tracking.f';
효과:
* 증분 백업 시 전체 데이터파일 스캔 불필요
* 변경 추적 파일에서 변경 블록 위치 즉시 파악
* 대용량 DB에서 증분 백업 시간 90%+ 단축
상태 확인:
SELECT filename, status, bytes
FROM V$BLOCK_CHANGE_TRACKING;백업 전략
| 전략 | 설명 | 복구 시간 | 저장 공간 |
|---|---|---|---|
| 전체 백업 (Full) | 모든 데이터를 백업 | 빠름 | 많음 |
| 증분 백업 (Incremental) | 변경된 블록만 백업 | 보통 | 적음 |
| 차등 백업 (Differential) | 마지막 전체 백업 이후 변경분 | 보통 | 중간 |
| 누적 증분 (Cumulative) | 마지막 Level 0 이후 누적 변경 | 빠름 | 점점 증가 |
──── 소규모 DB (수십 GB) ────
일 월 화 수 목 금 토
Full Inc1 Inc1 Inc1 Inc1 Inc1 Inc1
복구 시: Full + Inc1~IncN 순서대로 적용
──── 중규모 DB (수백 GB ~ 수 TB) ────
주간: Full (일요일)
일간: Cumulative Level 1 (월~토)
아카이브 로그: 30분마다 백업
복구 시: Full + 마지막 Cumulative + 아카이브 로그
──── 대규모 DB (수 TB 이상) ────
월간: Full Level 0
주간: Cumulative Level 1
일간: Differential Level 1
아카이브 로그: 15분마다 백업
※ Data Guard(스탠바이 DB)에서 백업 수행 → 운영 DB 부하 제거아카이브 로그 모드
미디어 복구(PITR 포함)를 위해서는 아카이브 로그 모드가 필수입니다.
┌──────────────────┬───────────────────┬───────────────────┐
│ │ NOARCHIVELOG │ ARCHIVELOG │
├──────────────────┼───────────────────┼───────────────────┤
│ Redo 로그 재사용 │ 덮어쓰기 │ 아카이브 후 재사용│
│ 미디어 복구 │ 불가능 │ 가능 │
│ PITR │ 불가능 │ 가능 │
│ 핫 백업 │ 불가능 │ 가능 │
│ 디스크 사용 │ 적음 │ 아카이브 로그 공간│
│ 운영 환경 │ 사용 금지 │ 반드시 사용 │
│ 개발 환경 │ 사용 가능 │ 선택 │
└──────────────────┴───────────────────┴───────────────────┘
-- 아카이브 로그 모드 전환
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
-- 아카이브 로그 확인
ARCHIVE LOG LIST;
-- 아카이브 로그 위치 설정
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 =
'LOCATION=/archivelog/' SCOPE=BOTH;물리적 백업 vs 논리적 백업
| 구분 | 물리적 백업 | 논리적 백업 |
|---|---|---|
| 대상 | 데이터 파일 자체 (바이너리) | 데이터 내용 (SQL/덤프) |
| 도구 | RMAN, OS 명령어 | Data Pump (expdp/impdp) |
| 속도 | 빠름 | 느림 |
| 이식성 | 같은 DBMS/플랫폼 | 다른 DBMS 가능 |
| PITR | 가능 | 불가 |
| 사용 목적 | 재해 복구, 운영 백업 | 마이그레이션, 데이터 이동 |
| 일관성 | 블록 수준 | 논리적 수준 |
──── 디렉토리 오브젝트 생성 ────
CREATE DIRECTORY dump_dir AS '/backup/dumps';
GRANT READ, WRITE ON DIRECTORY dump_dir TO hr;
──── 스키마 단위 백업 (Export) ────
$ expdp hr/password \
schemas=HR \
directory=DUMP_DIR \
dumpfile=hr_%U.dmp \
filesize=2G \
parallel=4 \
logfile=hr_exp.log
──── 테이블 단위 백업 ────
$ expdp hr/password \
tables=EMPLOYEES,DEPARTMENTS \
directory=DUMP_DIR \
dumpfile=tables.dmp
──── 복원 (Import) ────
$ impdp system/password \
schemas=HR \
directory=DUMP_DIR \
dumpfile=hr_%U.dmp \
parallel=4 \
remap_schema=HR:HR_NEW \
logfile=hr_imp.log
──── 주요 옵션 ────
CONTENT=DATA_ONLY -- 데이터만 (DDL 제외)
CONTENT=METADATA_ONLY -- DDL만 (데이터 제외)
EXCLUDE=TABLE:"='TEMP_LOG'" -- 특정 테이블 제외
QUERY=EMPLOYEES:"WHERE hire_date > DATE '2023-01-01'"
-- 조건부 백업MySQL/PostgreSQL 백업 도구
Oracle 외 DBMS의 백업 도구도 이해해야 합니다.
──── mysqldump (논리적 백업) ────
$ mysqldump -u root -p \
--single-transaction \
--routines --triggers --events \
mydb > mydb_backup.sql
$ mysqldump --all-databases > full_backup.sql
복원:
$ mysql -u root -p mydb < mydb_backup.sql
──── mysqlpump (병렬 논리적 백업) ────
$ mysqlpump -u root -p \
--default-parallelism=4 \
mydb > mydb_pump.sql
──── Percona XtraBackup (물리적 백업, 핫 백업) ────
$ xtrabackup --backup --target-dir=/backup/full
$ xtrabackup --prepare --target-dir=/backup/full
$ xtrabackup --copy-back --target-dir=/backup/full
특징
* InnoDB 핫 백업 (서비스 중단 없음)
* 증분 백업 지원
* 압축/암호화 지원──── pg_dump (논리적 백업) ────
$ pg_dump -U postgres -F c mydb > mydb.dump
$ pg_dump -U postgres -F p mydb > mydb.sql -- 평문 SQL
복원
$ pg_restore -U postgres -d mydb mydb.dump
$ psql -U postgres -d mydb -f mydb.sql
──── pg_basebackup (물리적 백업) ────
$ pg_basebackup -U replicator \
-D /backup/base \
-Ft -z -P \
--wal-method=stream
특징
* WAL 스트리밍으로 일관성 보장
* 복제 설정의 기반으로도 사용
* PITR의 베이스 백업으로 활용
──── WAL 아카이빙 (연속 아카이빙) ────
postgresql.conf:
archive_mode = on
archive_command = 'cp %p /archive/%f'
→ WAL 세그먼트를 연속 보관
→ pg_basebackup + WAL 아카이브로 PITR 가능PITR (Point-in-Time Recovery)
특정 시점까지 데이터베이스를 복원하는 기법입니다. 사용자가 실수로 대량 데이터를 삭제했을 때 핵심적인 복구 방법입니다.
사고 발생 시나리오
09:00 전체 백업 완료
10:00 정상 운영
11:00 정상 운영
12:00 실수로 DELETE FROM orders; COMMIT;
12:05 사고 인지 → PITR 결정
복구 목표: 11:59 시점으로 복원
┌──────────────────────────────────────────────┐
│ PITR 수행 절차 │
├──────────────────────────────────────────────┤
│ 1. DB 종료 │
│ SHUTDOWN ABORT; │
│ │
│ 2. 09:00 백업으로 RESTORE │
│ RMAN> RESTORE DATABASE; │
│ │
│ 3. 11:59까지 아카이브 로그 적용 │
│ RMAN> RECOVER DATABASE UNTIL TIME │
│ "TO_DATE('2024-01-15 11:59:00', │
│ 'YYYY-MM-DD HH24:MI:SS')"; │
│ │
│ 4. RESETLOGS로 DB OPEN │
│ RMAN> ALTER DATABASE OPEN RESETLOGS; │
│ │
│ 결과: 12:00 이후 변경은 모두 소실 │
│ 11:59 시점의 데이터로 복원 │
└──────────────────────────────────────────────┘방법 1: 시간 기반 (UNTIL TIME)
RECOVER DATABASE UNTIL TIME
"TO_DATE('2024-01-15 11:59:00', ...)";
→ 지정 시점까지 복구
방법 2: SCN 기반 (UNTIL SCN)
RECOVER DATABASE UNTIL SCN 12345678;
→ 특정 SCN까지 복구 (더 정밀)
방법 3: 로그 시퀀스 기반 (UNTIL SEQUENCE)
RECOVER DATABASE UNTIL SEQUENCE 150
THREAD 1;
→ 특정 아카이브 로그 시퀀스까지 복구
※ RESETLOGS 의미
→ Redo 로그 시퀀스를 리셋
→ 새로운 Incarnation 시작
→ 이전 아카이브 로그와의 연속성 끊김
→ 복구 후 즉시 전체 백업 필수!Oracle Flashback
Flashback은 Oracle 고유의 기능으로, 과거 시점의 데이터를 쉽게 조회하거나 복원할 수 있습니다. RMAN 복구보다 빠르고 간단하며, 논리적 오류 복구에 적합합니다.
| Flashback 유형 | 용도 | 의존 기술 |
|---|---|---|
| Flashback Query | 특정 시점의 데이터 조회 | Undo 세그먼트 |
| Flashback Version Query | 데이터 변경 이력 추적 | Undo 세그먼트 |
| Flashback Transaction Query | 트랜잭션 단위 변경 조회 | Undo + Supplemental Log |
| Flashback Table | 테이블을 과거 시점으로 되돌림 | Undo 세그먼트 |
| Flashback Drop | DROP된 테이블 복원 (휴지통) | Recyclebin |
| Flashback Database | 전체 DB를 과거 시점으로 복원 | Flashback Log |
-- 1시간 전 데이터 조회
SELECT * FROM users
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' HOUR)
WHERE id = 101;
-- SCN 기반 과거 데이터 조회
SELECT * FROM orders
AS OF SCN 12345678
WHERE order_id = 999;
-- 현재 vs 과거 비교 (실수 확인)
SELECT curr.*, past.salary AS old_salary
FROM employees curr,
employees AS OF TIMESTAMP
(SYSTIMESTAMP - INTERVAL '2' HOUR) past
WHERE curr.employee_id = past.employee_id
AND curr.salary <> past.salary;-- 특정 행의 모든 변경 이력 조회
SELECT versions_starttime, versions_endtime,
versions_operation, -- I(Insert), U(Update), D(Delete)
employee_id, salary
FROM employees
VERSIONS BETWEEN TIMESTAMP
SYSTIMESTAMP - INTERVAL '1' DAY AND SYSTIMESTAMP
WHERE employee_id = 101;
-- versions_operation으로 언제 누가 변경했는지 추적 가능-- 실수로 삭제한 테이블 복원 (휴지통에서)
FLASHBACK TABLE users TO BEFORE DROP;
FLASHBACK TABLE users TO BEFORE DROP RENAME TO users_restored;
-- 테이블을 특정 시점으로 되돌림
ALTER TABLE orders ENABLE ROW MOVEMENT; -- 사전 설정 필수
FLASHBACK TABLE orders TO TIMESTAMP
TO_TIMESTAMP('2024-01-15 14:30:00', 'YYYY-MM-DD HH24:MI:SS');필수 설정
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 1440;
-- 24시간(분 단위) 동안 Flashback 가능
ALTER DATABASE FLASHBACK ON;
수행
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
FLASHBACK DATABASE TO TIMESTAMP
TO_TIMESTAMP('2024-01-15 11:59:00', 'YYYY-MM-DD HH24:MI:SS');
ALTER DATABASE OPEN RESETLOGS;
Flashback Database vs PITR 비교:
┌──────────────┬──────────────────┬──────────────────┐
│ │ Flashback DB │ PITR (RMAN) │
├──────────────┼──────────────────┼──────────────────┤
│ 속도 │ 매우 빠름 │ 느림 (RESTORE) │
│ 공간 │ Flashback Log │ 백업 + 아카이브 │
│ 보존 기간 │ 제한적 (설정값) │백업이 있으면 가능│
│ 적용 범위 │ 전체 DB │ 전체/TS/파일 │
│ RESETLOGS │ 필요 │ 필요 │
└──────────────┴──────────────────┴──────────────────┘복구 시나리오별 대응 절차
실무에서 발생할 수 있는 다양한 장애 시나리오와 대응 방법입니다.
상황: /oradata/users01.dbf 파일 손실 (디스크 장애)
즉시 대응:
1. 해당 테이블스페이스 오프라인
SQL> ALTER TABLESPACE users_ts OFFLINE IMMEDIATE;
2. RMAN으로 데이터파일 복원
RMAN> RESTORE DATAFILE '/oradata/users01.dbf';
3. 아카이브 로그 적용 (완전 복구)
RMAN> RECOVER DATAFILE '/oradata/users01.dbf';
4. 테이블스페이스 온라인
SQL> ALTER TABLESPACE users_ts ONLINE;
※ DB를 종료하지 않고 복구 가능 (온라인 복구)상황: DELETE FROM orders WHERE year = 2024; COMMIT;
→ 2024년 주문 데이터 100만 건 삭제
대응 옵션 (우선순위)
옵션 A: Flashback Table (가장 빠름)
ALTER TABLE orders ENABLE ROW MOVEMENT;
FLASHBACK TABLE orders TO TIMESTAMP
(SYSTIMESTAMP - INTERVAL '10' MINUTE);
옵션 B: Flashback Query + INSERT (부분 복구)
INSERT INTO orders
SELECT * FROM orders
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '10' MINUTE)
WHERE year = 2024;
→ 삭제된 데이터만 선별 복구
옵션 C: PITR (최후 수단)
→ DB 전체를 과거 시점으로 복원
→ 다른 사용자의 작업도 함께 소실됨
→ 최후 수단으로만 사용상황: 서버 전체 재해 (화재, 장비 폐사)
복구 절차
1. 새 서버에 Oracle 설치 (동일 버전)
2. 원격 백업(테이프, 클라우드)에서 백업셋 복사
3. RMAN으로 제어 파일 복원
RMAN> RESTORE CONTROLFILE FROM '/backup/ctrl.bkp';
4. DB MOUNT
RMAN> ALTER DATABASE MOUNT;
5. 데이터파일 복원
RMAN> RESTORE DATABASE;
6. 아카이브 로그 적용
RMAN> RECOVER DATABASE;
7. DB OPEN
RMAN> ALTER DATABASE OPEN RESETLOGS;
8. 즉시 전체 백업 수행
필수 조건: 백업이 원격지에 존재해야 함!백업 검증과 복구 테스트
백업이 있어도 복구가 안 되면 소용없습니다. 정기적인 검증이 필수입니다.
1. RMAN 백업 검증 (물리적 무결성)
RMAN> VALIDATE DATABASE;
RMAN> VALIDATE BACKUPSET 123;
→ 블록 손상 여부 확인
2. RESTORE PREVIEW (복원 가능 여부)
RMAN> RESTORE DATABASE PREVIEW;
→ 필요한 백업/아카이브 로그 존재 여부 확인
→ 실제 복원 없이 검증만 수행
3. 복구 테스트 (정기 실시)
→ 별도 서버에서 실제 복구 수행
→ 분기 1회 이상 권장
→ 복구 소요 시간(RTO) 측정
4. 아카이브 로그 연속성 확인
SELECT sequence#, first_time, next_time,
status
FROM v$archived_log
ORDER BY sequence#;
→ 누락된 시퀀스가 없는지 확인
5. 보존 정책 확인
RMAN> REPORT OBSOLETE;
RMAN> DELETE OBSOLETE;
→ 보존 기간 지난 백업 정리백업 보존 정책
──── 중복 보존 (Redundancy) ────
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
→ 전체 백업 2세트 유지
→ 2세트 초과 시 가장 오래된 백업 OBSOLETE 표시
──── 기간 보존 (Recovery Window) ────
RMAN> CONFIGURE RETENTION POLICY TO
RECOVERY WINDOW OF 7 DAYS;
→ 최근 7일 내 아무 시점으로 복구 가능하도록 백업 유지
→ 7일 넘은 백업은 OBSOLETE
──── 운영 환경 권장 ────
구분 최소 보존 권장 보존
운영 DB 7일 30일
아카이브 로그 7일 14일
원격 백업 30일 90일
테이프 백업 1년 법적 요건에 따름고가용성(HA) 아키텍처와 복구
대규모 시스템에서는 복구보다 장애 예방과 자동 전환이 더 중요합니다.
┌──────────────────────────────────────────────────┐
│ Oracle Data Guard │
│ │
│ Primary DB ──Redo전송──→ Standby DB │
│ (운영) (대기) │
│ │
│ 장애 발생 시: │
│ Standby → Primary 자동/수동 전환 (Failover) │
│ │
│ 보호 모드: │
│ * Maximum Performance: 비동기, 성능 우선 │
│ * Maximum Availability: 동기, 가용성 우선 │
│ * Maximum Protection: 동기, 데이터 손실 0 │
├──────────────────────────────────────────────────┤
│ MySQL Replication │
│ │
│ Master ──Binlog──→ Slave (1개 이상) │
│ │
│ * 비동기/반동기/그룹 복제 │
│ * MHA / Orchestrator로 자동 Failover │
├──────────────────────────────────────────────────┤
│ PostgreSQL Streaming Replication │
│ │
│ Primary ──WAL──→ Standby │
│ │
│ * 동기/비동기 선택 │
│ * Patroni로 자동 Failover 관리 │
└──────────────────────────────────────────────────┘복구 실무 종합 정리
┌─────────────────────────────────────────────────────────┐
│ 복구 전략 핵심 항목 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. RPO (Recovery Point Objective) 정의 │
│ → 허용 가능한 데이터 손실량 (예: 15분) │
│ → 아카이브 로그 백업 주기 결정 │
│ │
│ 2. RTO (Recovery Time Objective) 정의 │
│ → 허용 가능한 복구 소요 시간 (예: 1시간) │
│ → FAST_START_MTTR_TARGET, Data Guard 결정 │
│ │
│ 3. 백업 전략 문서화 │
│ → 전체/증분 스케줄, 보존 기간 │
│ → 원격 백업 위치와 전송 방법 │
│ │
│ 4. 복구 절차서 작성 │
│ → 시나리오별 단계적 절차 │
│ → 비상 연락망과 의사결정 체계 │
│ │
│ 5. 정기 복구 테스트 │
│ → 분기 1회 이상 실제 복구 연습 │
│ → RTO 충족 여부 측정 │
│ │
│ 6. 모니터링과 알림 │
│ → 백업 실패 즉시 알림 │
│ → 아카이브 로그 공간 부족 사전 경고 │
│ → 테이블스페이스 손상 감지 │
│ │
└─────────────────────────────────────────────────────────┘| DBMS | 물리적 백업 | 논리적 백업 | PITR | HA 솔루션 |
|---|---|---|---|---|
| Oracle | RMAN | Data Pump | Redo + Archive | Data Guard |
| MySQL | XtraBackup | mysqldump | Binlog | Replication + MHA |
| PostgreSQL | pg_basebackup | pg_dump | WAL Archive | Streaming Rep + Patroni |
| SQL Server | BACKUP DATABASE | BCP / SSIS | T-Log | Always On AG |
다음 장에서는 쿼리의 성능을 분석하고 개선하는 쿼리 최적화를 다루겠습니다.