[MySQL] InnoDB 스토리지 엔진의 특징(2)

박상준·2024년 4월 11일
0

mysql

목록 보기
5/8

자동화된 장애 복구

InnoDB 의 자동 복구 메커니즘

  • 개요
    • InnoDB 는 데이터 손실이나 장애로부터 데이터를 보호하기 위하여 다양한 메커니즘을 가지고 있다.
    • MySQL 서버가 시작되는 경우, 완료되지 못한 트랜잭션, 디스크에 부분적으로만 기록된 데이터 페이지 등에 대해 자동 복구 작업을 수행한다.
  • 견고함
    • InnoDB 스토리지 엔진의 경우 매우 견고하다고함(?)
    • 데이터 파일이 손상되거나 MySQL 서버가 시작되지 못하는 경우가 드물다.
    • 그러나 디스크나 서버 하드웨어의 문제로 자동 복구가 불가능한 상황이 발생가능

복구의 방법

  1. innodb_force_recovery 설정
    1. MySQL 서버가 시작될 때 InnoDB 가 데이터 파일이나 로그 파일의 손상여부를 검사하는 과정을 조절 가능
    • 손상 유형에 따라
      • 데이터 파일 손상 : 1 으로 설정
      • 로그 파일 손상 : 6 으로 설정
    • 접근
      • 1 ~ 6 까지 차례로 변경하면서 MySQL 을 재시작한다.
      • 값이 클수록 더 심각한 상황을 의미하는데, 데이터 손실 가능성이 커지고 복구 가능성이 줄어들게 된다.

innodb_force_recovery 옵션 설명

  • 1(SRV_FORCE_IGNORE_CORRUPT)
    • 데이터나 인덱스 페이지의 손상을 무시하고 MySQL 서버를 시작합니다.
    • 적용 상황
      • 에러 로그에 Database page corruption on disk or a failed 메시지 출력시
    • 복구 조치
      • mysqldump 프로그램이나 SELECT INTO OUTFILE 명령을 사용하여 데이터베이스를 백업하고 재구축한다.
  • 2(SRV_FORCE_NO_BACKGROUND)
    • 백그라운드 스레드 중 메인 스레드를 시작하지 않고 MySQL 서버를 시작합니다.
    • 적용 상황
      • 언두 데이터 삭제 과정에서 장애가 발생시
    • 복구 조치
      • 메인 스레드가 시작되지 않으므로, 트랜잭션 롤백이나 언두 데이터 관리에 문제가 있을 때 사용함.
        • 메인 스레드는 주기적으로 불필요한 언두 데이터를 삭제 ( Undo purge ) 하기에, 메인 스레드가 언두 데이터를 삭제하는 과정에서 장애가 발생시 사용함.
  • 3(SRV_FORCE_NO_TRX_UNDO)
    • 커밋되지 않은 트랜잭션의 작업을 롤백하지 않고 그대로 둡니다.
    • 적용 상황
      • 커밋되지 않은 트랜잭션이 있는 경우
    • 복구 조치
      • 데이터를 mysqldump 로 백업 후 데이터베이스를 재구축한다.
  • 4(SRV_FORCE_NO_IBUF_MERGE)
    • 인서트 버퍼의 내용을 무시하고 MySQL 서버를 시작합니다.
    • 언제 씀
      • 인서트 버퍼의 손상 감지시
    • 복구 어케함
      • DB 백업하고 재구축하여 인덱스 관련 손실 없이 복구
  • 5(SRV_FORCE_NO_UNDO_LOG_SCAN)
    • 언두 로그를 모두 무시하고 MySQL 서버를 시작합니다.
    • 언제 씀
      • 언두 로드 사용 불가능시
    • 복구 조치
      • mysqldump 를 사용하여 데이터 백업하고, 데이터베이스를 새로 구축
  • 6(SRV_FORCE_NO_LOG_REDO)
    • 리두 로그를 모두 무시하고 MySQL 서버를 시작합니다.
    • 언제 씀
      • 리두 로드 손상
    • 복구 어케함
      • 리두 로그 삭제 혹은 백업 후 MySQL 재시작
        • mysqldump 데이터를 백업 DB 새로 구축

복구 후의 조치

  • MySQL 서버가 기동 → InnoDB 테이블 인식 → mysqldump 로 데이터를 백업, 그 데이터로 MySQL 서버의 DB와 테이블을 다시 생성함.
  • 백업이 있고, 바이너리 로그가 있다면, 마지막 백업부터 장애 시점까지 바이너리 로그를 사용해 데이터를 복구하는 것이 데이터 손실을 줄일 수 있음.

InnoDB 버퍼풀

  • 디스크 상의 데이터 파일과 인덱스 정보를 메모리에 캐싱
  • 빠른 데이터 접근 유도

기능

  • 데이터 캐싱
    • DB 테이블 데이터와 인덱스를 메모리에 캐싱, 디스크 I/O 를 줄이고 db 읽기 성능 향상
  • 쓰기 지연
    • INSERT, UPDATE, DELETE 와 같은 쓰기 작업을 즉시 디스크에 반영하지 않는다.
    • 버퍼 풀에 모아 두었다가 일괄적으로 디스크에 쓰기 작업을 수행
      • 랜덤 쓰기 작업을 줄이고

        랜덤 쓰기 작업?

        • 컴퓨터의 저장 장치 (디스크) 에 데이터를 저장하는 경우, 데이터가 저장 장치의 여러 다른 위치에 흩어져서 쓰여지는 작업을 말한다.
        • 저장 장치가 데이터를 여러 다른 위치에 저장해야하기에, 이동해야하는 거리가 멀어지고, 결과적으로 시간이 더 많이 소요된다.
        • 하드 드라이브의 경우, 읽기/쓰기 헤드가 움직여야 하는 거리가 멀어지며, SSD 의 경우에도 여러 다른 셀에 데이터를 쓰기 위해 추가적인 작업이 필요함
      • 디스크 I/O 효율성을 높일 수 있다.

최적화

  • 버퍼 풀 크기의 설정
    • 적절한 버퍼풀 설정
      • 너무 작으면 캐싱 효과 DOWN
      • 너무 크면 시스템의 다른 프로세스에 영향을 줄 수 있음.
  • 페이지 교체 알고리즘
    • 버퍼 풀 내에서 페이지(데이터 블록)을 교체할 때 사용하는 알고리즘의 성능에 영향
    • LRU(Least Recently Used) 알고리즘 사용 → 자주 접근되는 데이터를 메모리에 유지함.
profile
이전 블로그 : https://oth3410.tistory.com/

0개의 댓글