[MYSQL] Real MySQL 8.0 4장 정리

MYSQL 서버 ⇒ MYSQL 엔진+스토리지 엔진(누구나 구현해서 서버에 추가해서 사용가능)

MySQL 엔진 아키텍쳐

MySQL 엔진 구조

.NET의 표준 드라이버를 이용하여 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있도록 지원

MySQL 엔진

커넥션 핸들러+SQL 파서 및 전처리기+옵티마이저

• 커넥션 핸들러: 클라이언트로부터의 접속 및 쿼리 요청 처리
• 옵티마이저: 쿼리의 최적화된 실행을 위한 것

스토리지 엔진

실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분 전담

여러개를 동시에 사용 가능

핸들러 API

핸들러 요청: MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는것

핸들러 요청에서 사용되는 API가 핸들러 API

//얼마나 많은 데이터 작업이 있었는지 알아보는 명령어
SHOW GLOVAL STATUS LIKE 'Handler%';

MySQL 스레딩 구조

MySQL 서버는 스레드 기반으로 작동

포그라운드 스레드 / 백그라운드 스레드로 구분

포그라운드 스레드(클라이언트 스레드)

최소한 MySQL 서버에 접속된 클라이언트의 수만큼 존재

각 클라이언트 사용자가 요청하는 쿼리 문장을 처리

사용자가 커넥션 종료하면 해당 커넥션을 담당하던 스레드는 스레드 캐시로 되돌아감

thread_cache_size: 스레드 캐시에 유지할 수 있는 최대 스레드 개수

데이터를 MySQL의 데이터 버퍼나 캐시로 부터 가져옴 ( 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업 처리 )

• MyISAM 테이블: 디스크 쓰기 작업까지 포그라운드 스레드가 처리
• InnoDB 테이블: 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고 나머지 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리

백그라운드 스레드

백그라운드로 처리되는 작업

• 인서트 버퍼를 병합하는 스레드
• 로그를 디스크로 기록하는 스레드(중요)
• InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 스레드(중요)
• 데이터를 버퍼로 읽어 오는 스레드
• 잠금이나 데드락을 모니터링하는 스레드

데이터 쓰기 작업은 지연되어 처리될 수 있지만 데이터의 읽기 작업은 지연될 수 없다

→ 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능 탑재

• InnoDB: INSERT,UPDATE,DELETE 쿼리로 데이터가 변경되는 경우 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 됨
• MyISAM: 일반적인 쿼리는 쓰기 버퍼링 기능을 사용할 수 없음

메모리 할당 및 사용 구조

많은 스레드가 공유해서 사용하는 공간인지 여부에 따라 구분

글로벌 메모리 영역

클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당

• 테이블 캐시
• InnoDB 버퍼 풀
• InnoDB 어댑티브 해시 인덱스
• InnoDB 리두 로그 버퍼

로컬 메모리 영역(세션 메모리 영역)

MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역

각 클라이언트 스레드별로 독립적으로 할당되며 절대 공유되어 사용되지 않는다

• 정렬 버퍼
• 조인 버퍼
• 바이너리 로그 캐시
• 네트워크 버퍼

플러그인 스토리지 엔진 모델

MySQL의 독특한 구조 중 대표적인 것

위와 같이 쿼리 실행 과정을 나타낸다면 마지막의 데이터 읽기/쓰기만 스토리지 엔진에 의해 처리

핸들러: 프로그래밍 언어에서 어떤 기능을 호출하기 위해 사용하는 운전대와 같은 역할을 하는 객체

MySQL 엔진은 스토리지 엔진을 조정하기 위해 핸들러 사용

우리는 하나의 쿼리 작업이 여러 하위 작업으로 나뉘는데 각 하위 작업이 MySQL 엔진 영역에서 처리되는지 스토리지 엔진 영역에서 처리되는지 구분할 줄 알아야함

컴포넌트

8.0부터 기존의 플러그인 아키텍처를 대체하기 위해 컴포넌트 아키텍처가 지원됨

• 플러그인 단점
  • 오직 MySQL 서버와 인터페이스 할 수 있고, 플러그인끼리는 통신할 수 없음
  • MySQL 서버의 변수나 함수를 직접 호출하여 안전하지 않음
  • 상호 의존 관계를 설정할 수 없음

쿼리 실행 구조

쿼리 파서

사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어 내는 작업

전처리기

파서 과정에서 만들어진 파서 트리를 기반으로 쿼리 문장에 구조적 문제점이 있는지 확인

→ 객체의 존재 여부와 객체의 접근 권한 등을 확인하는 과정을 수행

옵티마이저

사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정하는 역할 수행

실행 엔진

만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할 수행

핸들러(스토리지 엔진)

MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당

복제

16장 에서 다룸…

쿼리 캐시

SQL의 실행 결과를 메모리에 캐시하고, 동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 즉시 결과를 반환

하지만, 동시 처리 성능 저하와 많은 버그의 원인이 되어 8.0에서는 서버의 기능에서 완전히 제거 됨.

스레드 풀(Percona Server 에서의)

플러그인 형태로 작동

내부적으로 사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있게 해서 서버의 자원 소모를 줄이도록 함

일반적으로 스레드 그룹은 CPU코어의 개수와 맞추는 것이 효율적

선순위 큐와 후순위 큐를 이용해 특정 트랜잭션이나 쿼리를 우선적으로 처리할 수 있는 기능 제공

트랜잭션 지원 메타데이터

메타데이터: 데이터베이스 서버에서 테이블의 구조 정보와 스토어드 프로그램 등의 정보

파일 기반의 메타데이터: 생성 및 변경 작업이 트랜잭션 지원하지 않음, 서버가 비정상적으로 종료되었을때 일관되지 않은 상태로 남는 문제 발생

8.0버전: 테이블의 구조 정보나 스토어드 프로그램의 코드 관련 정보를 모두 InnoDB 테이블에 저장하도록 개선됨

• 시스템 테이블: MySQL 서버가 작동하는데 기본적으로 필요한 테이블들을 묶어서 부르는것

InnoDB 스토리지 엔진 아키텍처

레코드 기반의 잠금 제공

→ 높은 동시성 처리 가능, 안정적, 성능이 뛰어남

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

InnoDB의 모든 테이블은 프라이머리 키를 기준으로 클러스터링 되어 저장

= 프라이머리 키 값의 순서대로 디스크에 저장

→ 프라이머리 키를 이용한 레인지 스캔이 빠른 속도에 처리 가능

• 클러스터링이란
• DB 분산 기법 중 하나로 DB 서버를 여러개 두어(DB를 수평적인 구조로 구축) 한 대가 죽었을 때 대비할 수 있는 기법

MyISAM 스토리지 엔진은 클러스터링 키 지원 X

= 프라이머리 키는 유니크 제약을 가진 세컨더리 인덱스일 뿐

외래 키 지원

InnoDB 스토리지 엔진 레벨에서 지원(MyISAM, MEMORY 테이블 X)

외래 키는 부모 테이블, 자식 테이블 모두 해당 칼럼에 인덱스 생성 필요, 변경 시에 두 테이블다 데이터가 있는지 체크하는 작업 필요, 이로인해 데드락 발생할 수 있음

MVCC(Multi Version Concurrency Control)

레코드 레벨의 트랜잭션을 지원하는 DBMS가 제공하는 기능

잠금을 사용하지 않는 일관된 읽기 제공

InnoDB는 언두 로그를 이용하여 기능 구현

예시) 아직 COMMIT , ROLLBACK이 되지 않은 상태에서 사용자가 작업 중인 레코드를 조회하면 어디에 있는 데이터를 조회할까?

READ_COMMITTED나 그 이상의 격리 수준(REPEATABLE_READ, SERIALIZABLE) 인 경우 아직 커밋되지 않아 InnoDB 버퍼 풀이나 데이터 파일에 있는 내용 대신 변경되기 이전의 내용을 보관하고 있는 언두 영역의 데이터를 반환 = MVCC

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

InnoDB 스토리지 엔진은 MVCC를 이용하여 잠금을 걸지 않고 읽기 작업 수행

따라서 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고, 읽기 작업 가능

하지만 일관된 읽기를 위해 언두로그를 삭제하지 못하고 느려지거나 문제가 발생할 수 있어서 트랜잭션이 시작됐다면 빨리 롤백이나 커밋을 통해 트랜잭션을 완료하는 것이 좋음

자동 데드락 감지

InnoDB 스토리지 엔진은 잠금 대기 목록을 그래프(Wait-for List) 형태로 관리

데드락 감지 스레드를 가지고 있어서 주기적으로 잠금 대기 그래프를 검사해 교착 상태에 빠진 트랜잭션들 찾아서 하나를 강제 종료함

• 어느 트랜잭션을 먼저 강제 종료 할 것인지의 기준 = 트랜잭션의 언두 로그 양, 더 적게 가진것이 일반적으로 롤백의 대상이 됨
• 일반적으로 innodb_table_locks 변수 활성화 하여 데드락 감지하기

하지만 동시 처리 스레드가 많아지거나 트랜잭션이 가진 잠금 갯수가 많아지면 데드락 감지 스레드가 느려진다

→innodb_lock_wait_timeout 시스템 변수를 활성화 하면 데드락 상황에서 일정 시간이 지났을때 자동으로 요청 실패하고 에러 메시지 반환

자동화된 장애 복구

서버가 시작될 때 완료되지 못한 트랜잭션이나 디스크에 일부만 기록된 데이터 페이지 등에 대한 일련의 복구 작업이 자동으로 진행됨

innodb_force_recovery 데이터 파일이나 로그 파일의 손상 여부 검사 과정을 선별적으로 진행하게 하는 시스템 변수

• 1(SRV_FORCE_IGNORE_CORRUPT)
• 테이블스페이스의 데이터나 인덱스 페이지에서 손상된 부분이 발견되도 무시하고 시작
• 2(SRV_FORCE_NO_BACKGROUND)메인 스레드가 언두 데이터를 삭제하는 과정에서 장애가 발생하였을때
• 백그라운드 스레드 가운데 메인 스레드를 시작하지 않고 서버를 시작
• 3(SRV_FORCE_NO_TRX_UNDO)
• 커밋되지 않은 트랜잭션의 작업을 롤백하지 않고 그대로 놔둠
• 4(SRV_FORCE_NO_IBUF_MERGE)
  • 인서트 버퍼: 실제 데이터와 관련된 부분 X
• 인서트 버퍼의 내용 무시하고 강제로 시작되게 한다
• 5(SRV_FORCE_NO_UNDO_LOG_SCAN)실제로는 잘못된 데이터가 디비에 남는 것이라 볼 수 있음 → mysqldump 이용하여 데이터 백업 및 데이터베이스 새로 구축
• 언두 로그를 모두 무시하고 시작
• 6(SRV_FORCE_NO_LOG_REDO)
• 리두 로그를 모두 무시한 채로 서버가 시작됨, 커밋됐다 하더라도 리두 로그에만 기록되고 데이터 파일에 기록되지 않은 데이터는 모두 무시

⇒ 위와 같이 했는데도 서버가 시작되지 않으면 백업을 이용해 다시 구축

InnoDB 버퍼 풀

엔진에서 가장 핵심적인 부분

디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간

쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 함

• 버퍼 풀의 크기 설정
  • 정확히 필요한 메모리 공간의 크기 계산 불가
  • 크기를 동적으로 조절할 수 있게 됨
  • innodb_buffer_pool_size 버퍼 풀 크기 설정 할 수 있는 시스템 변수
  • innodb_buffer_pool_instances 버퍼 풀을 여러 개로 분리할 수 있는 시스템 변수
• 버퍼 풀의 구조
  • InnoDB 스토리지 엔진이 관리하는 자료 구조: LRU(Least Recently Used) 리스트, 플러시(Flush) 리스트, 프리(Free) 리스트
    • 프리 리스트: 실제 사용자 데이터로 채워지지 않은 비어 있는 페이지들의 목록
    • LRU 리스트: LRU+MRU(Most Recently Used) 리스트 결합된 형태
      • 디스크로부터 한 번 읽어온 페이지를 최대한 오랫동안 InnoDB 버퍼 풀의 메모리에 유지해서 디스크 읽기를 최소화 하기 위해서 쓰는 리스트
    • 플러시 리스트: 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지 변경 시점 기준의 페이지 목록을 관리
• 버퍼 풀과 리두 로그
  • InnoDB의 버퍼 풀은 크게 설정할 수록 쿼리의 성능이 빨라짐
  • 버퍼 풀의 더티 페이지는 특정 리두 로그 엔트리와 관계를 가지고, 체크포인트가 발생하면 체크포인트 LSN보다 작은 리두 로그 엔트리와 관련된 더티 페이지는 모두 디스크로 동기화돼야 함
    • LSN: 리두 로그 파일의 공간은 계속 순환되어 재사용 되지만 매번 기록될 때마다 로그 포지션이 계속 증가된 값
• 버퍼 풀 플러시
  • InnoDB 스토리지 엔진은 버퍼 풀에서 아직 디스크로 기록되지 않은 더티 페이지 들을 성능상의 악영향없이 디스크에 동기화하기 위해 2개의 플러시 기능을 백그라운드로 실행
    • 플러시 리스트 플러시
      • 플러시 리스트에서 오래전에 변경된 데이터 페이지 순서대로 디스크에 동기와 하는 작업 수행
    • LRU 리스트 플러시
      • LRU 리스트에서 사용 빈도가 낮은 데이터 페이지들을 제거하여 새로운 페이지들을 읽어올 공간을 만들기 위해 LRU 플러시 함수 사용
• 버퍼 풀 상태 백업 및 복구
  • InnoDB 스토리지 엔진이 서버가 셧다운 되기 직전에 버퍼 풀의 백업을 실행하고, 서버가 시작되면 자동으로 백업된 버퍼 풀의 상태를 복구할 수 있는 기능 제공
  • innodb_buffer_pool_dump_dt_shutdown, innodb_pool_load_at_startup 설정을 서버 설정파일에 넣어두면 됨
• 버퍼 풀의 적재 내용 확인
  • 버퍼 풀이 큰 경우 테이블 조회가 큰 부하를 일으킴, 서비스 쿼리가 많이 느려짐
  • 8.0 버전부터 information_schema 데이터 베이스에 innodb_cached_indexes 테이블이 추가되어 테이블의 인덱스별로 데이터 페이지가 얼마나 InnoDB 버퍼 풀에 적재돼 있는지 확인 할 수 있음

Double Write Buffer

페이지가 일부만 기록되는 현상(파셜 페이지, 톤 페이지)은 하드웨어의 오작동이나 시스템의 비정상 종료를 발생할 수 있음

→ 이 문제를 해결하기 위해 Double Write 기법 이용

InnoDB 엔진은 재시작될 때 항상 DoubleWrite 버퍼의 내용과 데이터 파일의 페이지들을 모두 비교, 다른 내용 담고 있으면 버퍼의 내용을 데이터 파일의 페이지로 복사

데이터 안정성 위해 사용

데이터 무결성이 중요한 서비스에서 사용

언두 로그

트랜잭션과 격리 수준을 보장하기 위해 DML로 변경 되기 이전의 데이터를 백업한 데이터

• 트랜잭션 보장
  • 트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 언두 로그에 백업해 둔 이전 버전의 데이터를 이용해 복구
• 격리 수준 보장, 높은 동시성 제공
  • 특정 커넥션에서 데이터를 변경하는 도중에 다른 커넥션에서 데이터를 조회 했을때 트랜잭션 격리 수준에 맞게 변경중인 레코드를 읽지 않고 언두 로그에 백업해둔 데이터를 읽어서 반환
• 언두 테이블스페이스 관리
  • 언두 로그가 저장되는 공간
  • 8.0버전부터 시스템 테이블스페이스 외부의 별도 로그 파일에 기록
  • 8.0 버전부터 새로운 언두 테이블스페이스를 동적으로 추가하고 삭제 가능
    • CREATE UNDO TABLESPACE, DROP TABLESPACE
  • 최대 동시 트랜잭션 수 = (InnoDB 페이지 크기) / 16 * (롤백 세그먼트 개수) *(언두 테이블 스페이스 개수)

체인지 버퍼

InnoDB가 변경해야 할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트 수행

디스크로부터 읽어와서 업데이트 해야할 때 임시 공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 수행, 이때의 임시 메모리 공간이 체인지 버퍼

작업의 종류별로 체인지 버퍼를 활성화 할 수 있음

• innodb_change_buffering 변수에 설정할 수 있는 값
  • all: 모든 인덱스 관련 작업을 버퍼링
  • none: 버퍼링 안함
  • inserts: 인덱스에 새로운 아이템을 추가하는 작업만 버퍼링
  • deletes: 인덱스에서 기존 아이템을 삭제하는 작업만 버퍼링
  • changes: 인덱스에 추가하고 삭제하는 작업만 버퍼링
  • purges: 인덱스 아이템을 영구적으로 삭제하는 작업만 버퍼링

리두 로그 및 로그 버퍼

리두로그는 영속성과 가장 밀접하게 연관됨

서버가 비정상 종료되는 경우 스토리지 엔진의 데이터 파일은 두가지의 일관되지 않은 데이터를 가질 수 있음

• 커밋됐지만 데이터 파일에 기록되지 않은 데이터 → 리두 로그에 저장된 데이터를 데이터 파일에 다시 복사
• 롤백됐지만 데이터 파일에 이미 기록된 데이터 →리두 로그로만은 해결할 수 없음

리두 로그는 트랜잭션이 커밋되면 즉시 디스크로 기록되도록 시스템 변수를 설정하는 것을 권장, 하지만 많은 부하를 유발

→ 어느 주기로 디스크에 동기화 할지 결정 innodb_flush_log_at_trx_commit 변수 사용

• 0: 1초에 한 번씩 리두 로그를 디스크로 기록하고 동기화 실행
• 1: 매번 트랜잭션이 커밋될 때마다 디스크로 기록되고 동기화까지 수행
• 2: 매번 트랜잭션이 커밋될 때마다 디스크로 기록은 되지만 실질적 동기화는 1초에 한 번씩 실행
• 리두 로그 아카이빙아카이빙된 리두 로그를 정상적으로 사용하기 위해 커넥션을 그대로 유지해야함, 작업 완료시 아카이빙을 정상적으로 종료해야함
• 8.0 부터 추가됨, 데이터 변경이 많아서 리두 로그가 덮어 쓰인다 하더라도 백업이 실패하지 않게 해줌
• 리두 로그 활성화 및 비활성화
  • 8.0 부터 데이터를 복구하거나 대용량 데이터를 한번에 적재하는 경우 리두 로그를 비활성화하여 데이터의 적재 시간을 단축시킬 수 있음

  //활성화 비활성화 여부 확인, Innodb_redo_log_enabled 상태 보기
  ALTER INSTANCE [ENABLE|DISABLE] INNODB REDO_LOG
  

• 항상 활성화 되어 있음

어댑티브 해시 인덱스

사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스

B-Tree 검색 시간을 줄여주기 위해 사용

• 자주 읽히는 데이터 페이지의 키 값을 이용해 해시 인덱스를 만들고, 필요할 때마다 해시 인덱스를 검색하여 레코드가 저장된 데이터 페이지를 찾아감

성능 향상에 크게 도움이 안되는 경우

• 디스크 읽기가 많은 경우
• 특정 패턴의 쿼리가 많은 경우
• 매우 큰 데이터를 가진 테이블의 레코드를 폭넓게 읽는 경우

도움이 되는 경우

• 디스크의 데이터가 InnoDB 버퍼 풀 크기와 비슷한 경우(디스크 읽기가 적은 경우)
• 동등 조건 검색이 많은 경우
• 쿼리가 데이터 중에서 일부 데이터에만 집중되는 경우

서버의 상태 값들을 살펴봄으로써 어댑티프 해시 인덱스가 도움이 되는지 확인 가능

InnoDB 와 MyISAM, MEMORY 스토리지 엔진 비교

8.0 버전 부터 서버의 모든 시스템 테이블이 InnoDB 스토리지 엔진으로 교체, 공간 좌표 검색이나 전문 검색 기능이 모두 InnoDB 스토리지 엔진 지원

→ MyISAM 스토리지 엔진 없어질 것

MyISAM 스토리지 엔진 아키텍쳐

키 캐시

InnoDB 의 버퍼 풀과 비슷한 역할

인덱스만을 대상으로 작동, 인덱스의 디스크 쓰기 작업에 대해서만 부분적으로 버퍼링 역할

운영체제의 캐시 및 버퍼

MyISAM 테이블의 데이터 읽기나 쓰기 작업은 항상 운영체제의 디스크 읽기 또는 쓰기 작업으로 요청됨

MyISAM 테이블의 데이터에 대해서 디스크로부터의 입출력을 해결해 줄 만한 캐시나 버퍼링 기능이 없음

데이터 파일과 프라이머리 키 구조

프라이머리 키에 의한 클러스터링 없이 데이터 파일이 힙 공간 처럼 사용됨

테이블에 저장되는 레코드는 모두 ROWID라는 물리적인 주솟값을 가짐

ROWID 저장 방법 두가지

• 가변 길이: 데이터 파일에서 레코드의 위치가 ROWID로 사용됨
• 고정 길이: MAX_ROWS 옵션에 의해 테이블이 가질 수 있는 레코드의 개수가 한정되면 ROWID값으로 4바이트 정수 사용, 레코드가 삽입된 순번이 ROWID로 사용됨

MySQL 로그 파일

로그 파일을 이용하여 MySQL의 상태나 부하를 일으키는 원인을 쉽게 찾아서 해결

에러 로그 파일

MySQL이 실행되는 도중에 발생하는 에러나 경고 메세지가 출력되는 로그 파일

• MySQL 이 시작하는 과정과 관련된 정보성 및 에러 메시지
• 마지막으로 종료할 때 비정상적으로 종료된 경우 나타나는 InnoDB의 트랜잭션 복구 메시지
• 쿼리 처리 도중에 발생하는 문제에 대한 에러 메시지
  • 사전 예방이 어려움
  • 주기적으로 에러 로그 파일을 검토하는 과정에서 알게됨
• 비정상적으로 종료된 커넥션 메시지(Aborted connection)
  • 클라이언트 애플리케이션에서 정상적으로 접속 종료를 하지 못하고 프로그램이 종료된 경우
• InnoDB의 모니터링 또는 상태 조회 명령의 결과 메시지
• MySQL의 종료 메시지
  • 아무도 모르게 종료돼 있거나 아무도 모르게 재시작 되는 경우
  • 서버가 세그먼테이션 폴트로 비정상적으로 종료된 것으로 판단 할 수 있음
    • 스택 트레이스의 내용을 최대한 참조하여 MySQL 버그와 연관이 있는지 조사한 후 버전을 업그레이드 하거나 회피책을 찾아야함

제너럴 쿼리 로그 파일(제너럴 로그 파일)

제너럴 쿼리 로그는 실행되기 전에 MySQL이 쿼리 요청을 받으면 바로 기록, 따라서 쿼리 실행 중에 에러가 발생해도 일단 로그 파일에 기록됨

슬로우 쿼리 로그

long_query_time 변수에 설정한 시간 이상의 시간이 소요된 쿼리가 모두 기록

⇒ 일반적으로 슬로우 쿼리 또는 제너럴 로그 파일의 내용이 많아서 어떤걸 집중적으로 식별해야할지 어려울 수 있고 시간이 너무 많이 걸릴 수 있다

⇒ Percona Toolkit의 pt-query-digest 이용