책너두 (Real MySQL 8.0 1권) 8일차 (~107p)

요약

• InnoDB 스토리지 엔진 아키텍처의 전체 그림과 각 요소의 일부분에 대한 역할을 이해하게 됨.
• 스토리지 엔진별 인덱싱 전략과 프라이머리 키와 클러스터링 인덱스에 대한 간략한 내용을 이해하게 됨.
• 외래 키 작업의 불편함에 대한 내용을 다시한번 인식하게 됨.
  • 실제 서비스에서 자주 사용하지 않는다고 하는데, 잘 모르겠음. 다른 회사에서 많이 쓰고 있는지도 잘 모르겠다. 우리 회사에서는 JPA 연관관계를 이용해서 자주 쓰고 있는편임. → 책에서 말한 불편함을 경험한 적이 있음.
• MVCC 를 이해하게 됨.
  • 트랜잭션처리와 묶어서 언두 영역의 존재를 알게되고 어떻게 잠금 없는 읽기가 가능한지 이해하게 됨.
• 여러 장애 복구 모드에 대한 이해를 하게 됨.
  • 복구 모드별 특이사항을 이해하게 되고, 복구 모드가 발생되기 전 MySQL 서버 재시작시 장애 시점 복구에 대한 프로세스를 이해하게 됨 (언두로그 → 리두로그 실행)

발췌

• MVCC 는 일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능이며, MVCC 의 가장 큰 목적은 잠금을 사용하지 않는 일관된 읽기를 제공하는 데 있다.
  • InnoDB 는 언두 로그를 이용하여 이 기능을 구현한다.

메모

InnoDB 스토리지 엔진 아키텍처

• InnoDB 는 MySQL 에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공한다.
  • 이로 인해 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어남.

프라이머리 키에 의한 클러스터링

• InnoDB 의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장됨
  • 즉, 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻
  • 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다.
  • 프라이머리 키가 클러스터링 인덱스 이기 떄문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리 될 수 있다.
  • 쿼리 실행 계획에서 프라이머리 키는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정된다.
  • 오라클 DBMS 의 IOT (Index Organized Table) 과 동일한 구조가 InnoDB 에서 일반적인 테이블의 구조이다.
• InnoDB 스토리지 엔진과 달리 MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않음.
  • MyISAM 테이블에서는 프라이머리 키와 세컨더리 인덱스는 구조적으로 아무런 차이가 없다.
    • 프라이머리 키는 유니크 제약을 가진 세컨더리 인덱스 일 뿐임.
  • MyISAM 테이블의 프라이머리 키를 포함한 모든 인덱스는 물리적인 레코드의 주소 값(ROWID)을 가진다.

외래 키 지원

• 외래 키에 대한 지원은 InnoDB 스토리지 엔진 레벨에서 지원하는 기능이다.
  • MyISAM 이나 MEMORY 테이블에서는 사용할 수 없다.
• 외래 키는 데이터베이스 서버 운영의 불편함 때문에 서비스용 데이터베이스에서 생성하지 않는 경우가 자주 있음.
  • 그래도 개발 환경의 데이터베이스에서는 좋은 가이드 역할을 할 수 있다.
• InnoDB 에서 외래 키는 부모 테이블과 자식 테이블 모두 해당 칼럼에 인덱스 생성이 필요하다.
  • 변경 시에는 부모 테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하다.
    • 잠금이 여러 테이블로 전파되고, 그로 인해 데드락이 발생할 떄가 많음. → 개발 시, 외래 키의 존재에 주의해야 함.
• 수동으로 데이터를 적재하거나 스키마 변경 등의 관리 작업이 실패할 수 있음.
  • 물론, 부모 테이블과 자식 테이블의 관계를 명확히 파악해서 순서대로 작업한다면 문제없이 실행할 수 있음.
    • 하지만 외래 키가 복잡하게 얽힌 경우에는 그렇게 간단하지 않음.
    • 긴급하게 조치가 필요한 상황에 이런 문제가 발생하면 더 곤란해짐.
    • foreign_key_checks 시스템 변수를 OFF 로 설정하면 외래 키 관계에 대한 체크 작업을 일시적으로 멈출 수 있음.
      • 레코드 적재나 삭제 등의 작업도 부가적인 체크가 필요 없으므로 훨씬 빠르게 처리 가능
• 키 체크를 일시적으로 해제 하더라도 부모와 자식 테이블 간의 관계가 깨진 상태로 그대로 유지해도 된다는 것은 아님.
  • 만약 키 체크를 일시적으로 중지하고 부모 테이블의 레코드를 삭제했다면 반드시 자식 테이블 레코드도 삭제해서 일관성을 맞춘 후 외래키 체크 기능을 활성화 해야 함.

foreign_key_checks 시스템 변수는 GLOBAL 과 SESSION 모두 설정 가능한 변수임. 그래서 해당 작업은 반드시 현재 작업을 진행하는 세션에서만 외래 키 체크 기능을 멈추게 해야 함. → 작업이 완료되면 현재 세션을 종류하거나 현재 세션의 외래키 체크를 다시 활성화 해야 함.

MVCC (Multi Version Concurrency Control)

• 레코드 레벨의 트랜잭션을 지원하는 DBMS 가 제공하는 기능이다.
• 잠금을 사용하지 않는 일관된 읽기를 제공한다.
• InnoDB 는 언두 로그(Undo log) 를 이용해 이 기능을 구현한다.
• 여기서 멀티 버전이 뜻하는 것은 하나의 레코드에 대해 여러 개의 버전이 동시에 관리된다는 의미이다.
• ex) 격리 수준이 READ_COMMITTED 인 MySQL 서버에서 InnoDB 스토리지 엔진을 사용하는 테이블의 데이터 변경 처리 과정을 그림으로 살펴 본다.

mysql> CREATE TABLE member (
                m_id INT NOT NULL,
                m_name VARCHAR(20) NOT NULL,
                m_area VARCHAR(100) NOT NULL,
                PRIMARY KEY (m_id),
                INDEX ix_area (m_area)
            );

mysql> INSERT INTO member (m_id, m_name, m_area) VALUES (12, '홍길동', '서울');
mysql> COMMIT;

• 테이블을 생성하고 값을 insert 한 뒤, 버퍼 풀과 디스크에 member 테이블에 대한 데이터가 동일하게 남아있는 모습이다.

mysql> UPDATE member SET m_area='경기' WHERE m_id=12;

• m_area 를 경기로 UPDATE 쿼리를 날리는 상황이다.
• COMMIT 실행 여부와 상관 없이 InnoDB 의 버퍼 풀은 새로운 값이 ‘경기’ 로 업데이트 된다.
• 디스크의 데이터 파일에는 체크 포인트나 InnoDB 의 Write 스레드에 의해 새로운 값으로 업데이트되어 있을 수도 있고 아닐 수도 있다.
  • InnoDB 는 ACID 를 보장하기 때문에 일반적으로 InnoDB의 버퍼 풀과 데이터 파일은 동일한 상태라고 가정해도 무방하다.

mysql> SELECT * FROM member WHERE m_id=12;

• 지금 COMMIT, 혹은 ROLLBACK 이 되지 않은 상태에서 다른 사용자가 다음과 같이 작업 중인 레코드로 조회 쿼리를 날리는 상황이다.
• 어떤 값을 읽어 오는 지는 MySQL 서버의 시스템 변수 (transaction_isolation) 에 설정된 격리 수준에 따라 다르다.
  • 격리 수준이 READ_UNCOMMITTED 인 경우에는 InnoDB 버퍼 풀이 현재 가지고 있는 변경된 데이터를 읽어서 반환한다.
    • 즉, 데이터가 커밋됐든 아니든 변경된 상태의 데이터를 반환한다.
  • READ_COMMITTED 이거나 그 이상의 격리 수준(REPEATABLE_READ, SERIALIZABLE) 인 경우에는 아직 커밋 되지 않았기 때문에 InnoDB 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 이전의 내용을 보관하고 있는 언두 영역의 데이터를 반환한다.
    • 이런 과정을 DBMS 에서는 MVCC 라고 표현한다.
    • 즉, 하나의 레코드 (회원 번호가 12 인 레코드) 에 대해 2개의 버전이 유지되고, 필요에 따라 어느 데이터가 보여지는지 여러 가지 상황에 따라 달라지는 구조이다.
    • 예시와 달리 실제로 관리해야 하는 예전 버전의 데이터가 무한히 많아질 수 있다.
      • 트랜잭션이 길어지면 언두에서 관리하는 예전 데이터가 삭제되지 못하고 오랫동안 관리되어야 함.
      • 따라서 자연히 언두 영역이 저장되는 시스템 테이블스페이스의 공간이 많이 늘어나는 상황이 발생할 수도 있음.
• 정리하면, UPDATE 쿼리가 실행되면 InnoDB 버퍼 풀은 즉시 새로운 데이터로 변경되고, 기존 데이터는 언두 영역으로 복사된다.
  • 이 상태에서 COMMIT 명령을 실행하면 InnoDB 는 더 이상의 변경 작업 없이 지금의 상태를 영구적인 데이터로 만들어 버린다.
  • 만약 ROLLBACK 을 실행하면 InnoDB 는 언두 영역에 있는 백업된 데이터를 InnoDB 버퍼 풀로 다시 복구하고, 언두 영역의 내용을 삭제해 버린다.
  • 커밋된다고 언두 영역의 백업 데이터가 항상 바로 삭제되는 것은 아님.
    • 언두 영역을 필요로 하는 트랜잭션이 더는 없을 때 삭제된다.

잠금 없는 일관된 읽기 (Non-Locking Consistent Read)

• InnoDB 스토리지 엔진은 MVCC 기술을 이용해 잠금을 걸지 않고 읽기 작업을 수행함.
  • 즉, 읽기 작업시 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고 읽기 작업이 가능함.
  • 격리 수준이 SERIALIZABLE 이 아닌 READ_UNCOMMITTED 나 READ_COMMITTED , REPEATABLE_READ 수준인 경우, INSERT 와 연결되지 않은 순수한 읽기 (SELECT) 작업은 다른 트랜잭션의 변경 작업과 관계 없이 항상 잠금을 대기하지 않고 바로 실행함.

 

• 특정 사용자가 레코드를 변경하고 아직 커밋을 수행하지 않았더라도 이 변경 트랜잭션이 다른 사용자의 SELECT 작업을 방해하지 않는다. 
  • 이를 ‘잠금 없는 읽관된 읽기’ 라고 표현함.
  • InnoDB 에서는 변경되기 전의 데이터를 읽기 위해 언두 로그를 사용한다.
  • 오래 활성 상태인 트랜잭션으로 인해 MySQL 서버가 느려지는 문제가 가끔발생함
    • 바로 이러한 일관된 읽기를 위해 언두 로그를 삭제하지 못하고 계속 유지해야 하기 때문에 발생하는 문제임
    • 따라서 트랜잭션이 시작됐다면 가능한 빨리 롤백이나 커밋을 통해 트랜잭션을 완료하는 것이 좋음.

 

자동 데드락 감지

• InnoDB 스토리지 엔진은 내부적으로 잠금이 교착 상태에 빠지지 않았는지 체크하기 위해 잠금 대기 목록을 그래프 (Wait-for List) 형태로 관리함.
  • InnoDB 스토리지 엔진은 데드락 감지 스레드를 가지고 있음.
    • 데드락 감지 스레드는 주기적으로 잠금 대기 그래프를 검사해 교착 상태에 빠진 트랜잭션들을 찾아서 그중 하나를 강제 종료함.
    • 트랜잭션의 언두 로그 양을 기준으로 어느 트랜잭션을 먼저 강제 종료할지 판단한다.
      • 언두 로그 레코드를 더 적게 가진 트랜잭션이 일반적으로 롤백 대상이 된다.
      • 언두 로그 레코드가 적다는 것은 롤백을 해도 언두 처리를 해야할 내용이 적다는 것을 의미.
        • 트랜잭션 강제 롤백으로 인한 MySQL 서버의 부하도 덜 유발함.
• InnoDB 스토리지 엔진은 상위 레이어인 MySQL 엔진에서 관리되는 테이블 잠금(LOCK TABLES 명령으로 잠긴 테이블)은 볼 수가 없어서 데드락 감지가 불확실할 수 있음.
  • innodb_table_locks 시스템 변수를 활성화 하면 InnoDB 스토리지 엔진 내부의 레코드잠금 뿐만 아니라 테이블 레벨의 잠금까지 감지할 수 있게 됨.
  • 특별한 이유가 없으면 해당 시스템 변수를 활성화 하자.
• 동시 처리 스레드가 매우 많아지거나 각 트랜잭션이 가진 잠금 개수가 많아지면 데드락 감지 스레드가 느려진다.
  • 데드락 감지 스레드는 잠금 목록을 검사해야 하므로 잠금 상태가 변경되지 않도록 잠금 목록이 저장된 리스트(잠금 테이블)에 새로운 잠금을 걸고 데드락 스레드를 찾는다.
  • 만약 데드락 감지 스레드가 느려지면 서비스 쿼리를 처리 중인 스레드는 더 작업을 진행하지 못하고 계속 대기하게 되면서 서비스에 악영향을 미치게 됨.
  • 동시 처리 스레드가 많아지게되면 데드락 감지 스레드가 더 많은 CPU 자원을 소모할 수도 있음.
    • 이러한 문제를 해결하기 위해 MySQL 서버는 innodb_deadlock_detect 시스템 변수를 제공함.
      • 해당 변수를 OFF 로 설정하면 데드락 감지 스레드는 더 이상 작동하지 않음.
      • 데드락 감지 스레드가 작동하지 않으면, InnoDB 스토리지 엔진 내부에서 데드락이 발생해도 누군가가 중재하지 않기 때문에 무한정 대기하게 된다.
        • innodb_lock_wait_timeout 시스템 변수를 활성화 하면 이러한 데드락 상황에서 일정 시간이 지나면 자동으로 요청이 실패하고 에러 메시지를 반환함.
          • 해당 시스템 변수는 초 단위로 설정할 수 있음.
          • 설정한 시간 동안 잠금을 획득하지 못하면 쿼리는 실패하고 에러를 반환함.
          • 데드락 감지 스레드가 부담되어 innodb_deadlock_detect 를 OFF 로 사용한다면 innodb_lock_wait_timeout 값은 기본 값인 50초 보다 훨씬 낮은 시간으로 변경해서 사용하는 것을 권장함.

구글에서 프라이머리 키 기반의 조회 & 변경이 높은 빈도로 실행되는 서비스가 많았고 이로 인해 데드락 감지 스레드가 상당한 성능을 저하시킨다는 것을 알아냈다고 함. → MySQL 서버의 소스코드를 변경하여 데드락 감지 스레드를 비활성화 할 수있게 변경하여 사용했다고 함.
오라클에서도 이 기능의 필요성을 인지하고 MySQL 서버에 추가했다고 함.

 

자동화된 장애 복구

• InnoDB 에는 손실이나 장애로부터 데이터를 보호하기 위한 여러 메커니즘이 탑재됨.
  • 이 메커니즘을 사용하여 MySQL 서버가 시작될 때 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 (Partial write) 데이터 페이지 등에 대한 복구 작업이 자동으로 진행됨.
• InnoDB 스토리지 엔진은 매우 견고하여 데이터 파일이 손상되거나 MySQL 서버가 시작되지 못하는 경우는 거의 없음.
  • MySQL 서버와 무관하게 디스크나 서버 하드웨어 이슈로 인해 InnoDB 스토리지 엔진이 자동으로 복구를 못하는 상황이 발생할 수 있음.
    • 일단 한번 문제가 생기면 복구하기 쉽지 않음.
    • InnoDB 데이터 파일은 기본적으로 MySQL 서버가 시작될 떄 항상 자동 복구를 수행한다.
    • 이 단계에서 자동으로 복구될 수 없는 손상이 있다면 자동 복구를 멈추고 MySQL 서버를 종료시켜버림.
      • 위 문제를 해결하기 위해MySQL 서버의 설정 파일에 innodb_force_recovery 시스템 변수를 설정해서 MySQL 서버를 시작해야함.
      • 이 설정값은 MySQL 서버가 시작될 때 InnoDB 스토리지 엔진이 데이터 파일이나 로그 파일의 손상 여부 검사 과정을 선별적으로 진행할 수 있게 함.
        • InnoDB 로그 파일이 손상됐다면 6으로 설정하고 MySQL 서버를 기동한다.
        • InnoDB 테이블의 데이터 파일이 손상됐다면 1로 설정하고 MySQL 서버를 기동한다.
        • 어떤 부분인지 문제를 알 수 없다면 innodb_force_recovery 설정 값을 1 부터 6까지 변경하면서 MySQL 을 재시작한다.
        • 해당 시스템 변수 값이 커질 수록 심각한 상황이다. → 데이터 손실 가능성이 커지고 복구 가능성은 적어진다.
• 일단 MySQL 서버가 기동되고 InnoDB 테이블이 인식된다면 mysqldump 를 이용해 데이터를 가능한 만큼 백업하고 그 데이터로 MySQL 서버의 DB 와 테이블을 다시 생성하는 것이 좋다.
• innodb_force_recovery 시스템 변수에 따른 장애 상황과 해결 방법이다.
  • 0 일때는 복구 모드가 아니므로 SELECT, INSERT, UPDATE, DELETE 쿼리 실행이 가능함.
  • 0이 아닌 복구 모드일때는 SELECT 이외의 INSERT, UPDATE, DELETE 쿼리는 수행 할 수 없음.
  • 1 (SRV_FORCE_IGNORE_CORRUPT)
    • InnoDB 의 테이블스페이스의 데이터나 인덱스 페이지에서 손상된 부분이 발견되어도 무시하고 MySQL 서버를 시작한다.
    • 에러 로그 파일에 ‘Database page corruption on disk or a failed’ 메시지가 출력될 때, 대부분이 이 경우 임.
    • 이때는 mysqldump 프로그램이나 SELECT INTO OUTFILE … 명령을 이용해 덤프해서 데이터베이스를 다시 구축하는게 좋음.
  • 2 (SRV_FORCE_NO_BACKGROUND)
    • InnoDB 는 쿼리 처리르 위해 여러 종류의 백그라운드 스레드를 동시에 사용한다.
    • 이 복구 모드에서는 백그라운드 스레드 중, 메인 스레드를 시작하지 않고 MySQL 서버를 시작한다.
    • InnoDB 는 트랜잭션의 롤백을 위해 언두 데이터를 관리하는데, 트랜잭션이 커밋되어 불필요한 언두 데이터는 InnoDB 메인 스레드에 의해 주기적으로 삭제된다. (Undo purge 라고 함)
    • InnoDB 의 메인 스레드가 언두 데이터를 삭제하는 과정에서 장애가 발생한다면 이 모드로 복구하면 됨.
  • 3 (SRV_FORCE_NO_TRX_UNDO)
    • InnoDB 에서 트랜잭션이 실행되면 롤백에 대비해 변경 전의 데이터를 언두 영역에 기록함.
    • 일반적으로 MySQL 서버는 다시 시작하면서 언두 영역의 데이터를 먼저 데이터 파일에 적용함.
    • 그 다음 리두 로그의 내용을 다시 덮어써서 장애 시점의 데이터 상태를 만들어냄.
    • 정상적인 MySQL 서버 시작시, 최종적으로 커밋되지 않은 트랜잭션은 롤백을 수행한다.
      • 하지만 SRV_FORCE_NO_TRX_UNDO 모드에서는 커밋되지 않은 트랜잭션 작업을 롤백하지 않고 그대로 둔다.
    • 이때도 MySQL 서버가 시작되면 mysqldump 를 이용해 데이터 백업해서 다시 데이터베이스를 구축하는게 좋음.
  • 4 (SRV_FORCE_NO_IBUF_MERGE)
    • InnoDB 는 INSERT, UPDATE, DELETE 등의 데이터 변경이 일어날 때, 인덱스 변경 작업을 수행함.
    • 상황에 따라 즉시 처리할 수도 있고, 인서트 버퍼에 저장해두고 나중에 처리할 수도 있음.
      • 이때, 인서트 버퍼에 기록된 내용은 언제 데이터 파일에 병합될지 알 수 없음.
      • MySQL 을 종료해도 병합되지 않을 수 있음.
      • 만약 MySQL 이 재시작되면서 인서트 버퍼의 손상이 감지되면 InnoDB 는 에러를 발생시키고 MySQL 서버는 시작하지 못함.
    • SRV_FORCE_NO_IBUF_MERGE 상황에서는 InnoDB 스토리지 엔진이 인서트 버퍼의 내용을 무시하고 강제로 MySQL 이 시작되게 함.
      • 인서트 버퍼는 실제 데이터와 관련된 부분이 아니라 인덱스와 관련된 부분이다.
      • 따라서 테이블을 덤프하고 다시 데이터베이스를 구축하면 데이터 손실 없이 복구가 가능함.
  • 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
    • MySQL 서버가 장애 or 정상 종료 시점에 진행 중인 트랜잭션이 있다면 단순히 커넥션을 강제로 끊고 별도 정리 작업없이 종료함.
    • MySQL 서버 다시 시작하면 InnoDB 엔진 언두 레코드로 데이터 페이지 복구후 리두 로그를 적용해 종료 시점이나 장애 발생 시점의 상태를 재현하고, 커밋되지 않은 트랜잭션에서 변경한 작업을 모두 롤백함.
    • 만약, 이 상황에서 언두 로그를 사용할 수 없다면 InnoDB 엔진은 에러로 MySQL 서버를 시작할 수 없음.
    • SRV_FORCE_NO_UNDO_LOG_SCAN 상황에서 InnoDB 엔진은 언두 로그를 모두 무시하고 MySQL 을 시작할 수 있음.
      • 하지만 이 모드로 복구되면 MySQL 서버가 종료되던 시점에 커밋되지 않았던 작업도 모두 커밋된 것처럼 처리됨.
      • 따라서 잘못된 데이터가 데이터베이스에 남게됨.
      • 이때도 mysqldump 를 이용해 데이터를 백업하고 데이터베이스를 새로 구축해야 함.
  • 6 (SRV_FORCE_NO_LOG_REDO)
    • InnoDB 스토리지 엔진은 리두 로그가 손상되면 MySQL 서버가 시작되지 못함.
    • 이 복구 모드로 시작하면 InnoDB 엔진은 리두 로그를 모두 무시한 채로 MySQL 서버를 시작함.
    • 트랜잭션이 커밋됐어도 리두 로그에만 기록됨.
      • 따라서 리두 로그 손상이 되면, 이후 기록은 쌓이지 않고, 결국 데이터파일에 기록되지 않은 데이터는 모두 무시됨.
      • 즉, 마지막 체크 포인트 시점의 데이터만 남게 되고, 리두 로그 손상 이후의 트랜잭션처리는 모두 버리게 된다. (잘 수행했던 데이터 변경 작업들이 다 날아가게 됨)
      • 따라서 기존의 InnoDB 리두 로그는 모두 삭제 (혹은 별도 디렉터리에 백업) 하고 MySQL 서버를 시작하는 것이 좋음.
      • MySQL 서버는 리두 로그가 없으면 새로 생성하기 때문에 별도 파일을 만들 필요는 없음.
      • 이 복구모드 상황도 mysqldump 를 이용해 데이터 모두 백업후 MySQL 서버를 새로 구축하는게 좋음.
• 위 방법으로도 MySQL 서버가 시작되지 않으면 백업을 이용해 다시 구축하는 방법밖에 없음.
  • 백업이 있다면 마지막 백업으로 데이터베이스를 구축한다.
  • 바이너리 로그를 사용해 최대한 장애 시점까지의 데이터를 복구할 수도 있음.
  • 마지막 풀 백업 시점 부터, 장애 시점까지의 바이너리 로그가 있다면 InnoDB 의 복구를 이용하는 것 보다 풀 백업과 바이너리 로그로 복구하는 편이 데이터 손실이 더 적을 수 있다.
    • 복제 바이너리 로그가 없거나 손실됐다면 마지막 백업 시점까지만 복구할 수 있음.