아카이브 모드(Archive Mode)

모든 RDBMS는 데이터 무결성을 위해 로그를 먼저 쓰고 데이터를 쓴다(WAL: Write Ahead Logging)이라는 대원칙을 따름

따라서 이 로그를 보관해서 복구에 쓰는 기능을 필수적으로 다 있다.

아카이브 모드

- Redo Log 파일이 덮어쓰여지기 전에, 다른 곳에 복사본을 떠놓는 모드

작동 매커니즘(LGWR와 ARCn의 협동)

- 오라클의 Redo Log는 기본적으로 순환(Round-Robin)구조

1) No Archive Mode(기본 모드)
    1. LGWR가 1번 로그 파일을 다 채움
    2. 2번 로그 파일로 넘어감(Log Switch)
    3. 3번 로그 파일까지 모두 채우면?
    4. 다시 1번 로그 파일로 돌아와서 데이터를 덮어 씀(과거 데이터 소멸)

2) Archive Mode(운영 필수 모드)
    1. LGWR가 1번 로그 파일을 다 채우고 2번으로 넘어감
    2. 이때, ARCn(Archive process)라는 백그라운드 프로세스가 깨어남
    3. 덮어쓰기 전에 1번 파일을 아카이브 로그 폴더(별도 디스크)로 복사
    4. 나중에 LGWR가 한 바퀴 돌아서 다시 1번을 쓰려고 할 때, 복사(Archiving)가 안 끝났으면 덮어쓰지 않고 기다림(데이터 보호 우선)    

포인트

1. 백업의 자유(Hot Backup)
    - 아카이브 모드를 써야만 서비스 중단 없이 백업을 할 수 있음

2. 시점 복구(Time Machine)
    - 어제 오후 2시 30분 시점으로 되돌려주세요 라는 요청이 들어오면?
        - 아카이브 모드: 어제 밤 백업본 +_ 아카이브 로그들을 순서대로 적용(Roll forward)해서 2시 30분 상태를 재현
        - 노 아카이브 모드: 불가능

3. 디스크 관리(주의사항)
    - 아카이브 로그는 DB가 변경되는 만큼 계속 쌓이는 파일
        - 만약 아카이브 저장 공간(Disk)이 꽉 차면?
        - ARCn 프로세스가 더 이상 복사할 곳이 없다고 멈춤
        - 그럼 LGWR도 복사가 안 끝났으니 덮어쓸 수 없다고 멈춤
        - 결과: DB 전체가 멈춤
        - 해결: DBA는 주기적으로 아카이브 로그를 테이프 백업 장치로 옮기고 디스크를 비워줘야함

DBMS별 명칭

1. Oracle
    - 용어: Archivelog mode
    - 설명: 위와 같음

2. MySQL / MariaDB
    - 용어: Binary Log (Binlog)활성화
    - 설명:
        - log_bin = on 설정을 켜면, 변경되는 모든 데이터 내역이 Binlog 파일에 기록됨
    - 용도: 오라클의 아카이브 로그와 똑같이 시점복구(PIRT)에 쓰이고, 특히 MySQL은 이중화(Replication)을 할 때 
            이 파일을 슬레이브 서버로 보내는 방식을 사용

3. PostgreSQL
    - 용어: WAL Archiving(archive_mode)
    - 설명:
        - 오라클과 가장 비슷함
        - 로그파일을 WAL(Write Ahead Log)이라고 부름
        - 설정 파일(postgresql.conf)에서 archive_mode = on으로 켜고, archive_command에 파일을 어디로 복사할지
            스크립트를 적어주면 작동

4. MS SQL Server (MSSQL)
    - 용어: Full Recovery Model (전체 복구 모델)
    - 설명: 
        - 여기는 모드 대신 복구 모델이라는 표현을 사용
        - Simple Recovery Model: 로그를 알아서 잘라내고 버림, 복구 불가능
        - Full Recovery Model: 로그를 백업받을 때까지 계속 보관, 시점 복구 가능