Real MySQL 8.0 - MySQL 엔진 아키텍처 - (1) MySQL 엔진 아키텍처와 스레딩 구조
포스팅은 Real MySQL 8.0 책을 기반으로 작성되었습니다.
목차
1. MySQL 엔진 아키텍처
2. MySQL 스레딩 구조
1. MySQL 엔진 아키텍처
위 사진은 MySQL의 전체 구조를 나타낸다. MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있다. 저자는 이 둘을 모두 합쳐서 그냥 MySQL 또는 MySQL 서버라고 표현한다.
MySQL 엔진
MySQL 엔진은 클라이언트로부터 접속, 쿼리 요청을 처리하는 커넥션 핸들러, SQL 파서 및 전처리기, 옵티마이저가 중심을 이룬다. 또한 MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 표준 문법에 따라 작성된 쿼리는 타 DBMS와 호환되어 실행될 수 있다.
스토리지 엔진
실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 부분은 스토리지 엔진이 전담한다. MySQL 서버에서 MySQL 엔진은 하나지만 스토리지 엔진은 여러 개를 동시에 사용할 수 있다. 예를 들면 아래와 같이 테이블 별로 스토리지 엔진을 지정할 수 있다.
CREATE TABLE inno_table (fd1 int, fd2 int) ENGINE=INNODB;
핸들러 API
MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러 요청이라 한다. 그리고 여기에 사용되는 API를 핸들러 API라고 한다.
이 핸들러 API를 통해 얼마나 많은 데이터(레코드) 작업이 있었는지는 아래 명령어를 통해 확인할 수 있다.
show status like 'Handler_%';
2. MySQL 스레딩 구조
MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 작동하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있다. 아래 명령어를 통해 스레드를 확인해보자.
select thread_id, name, type from performance_schema.threads ORDER BY type, THREAD_ID;
대부분은 백그라운드 스레드이고 3개만 포그라운드 스레드이다. 마지막에 보이는 one_connection 스레드만 실제 사용자의 요청을 처리하는 포그라운드 스레드다. 백그라운드 스레드 중 동일한 이름의 스레드가 2개 이상씩 보이는 것은 MySQL 서버의 설정에 의해 여러 스레드가 동일 작업을 병렬로 처리하는 경우이다.
참고로 여기서 소개하는 스레드 모델은 커뮤니티 에디션에서 사용되는 기존의 전통적인 스레드 모델이다. MySQL 엔터프라이즈 에디션에서는 스레드 풀 모델을 사용할 수도 있다. 스레드 풀과 전통적인 스레드 모델의 가장 큰 차이점은 포그라운드 스레드와 커넥션의 관계이다.
전통적인 스레드 모델에서는 커넥션별로 포그라운드 스레드가 하나씩 생성되고 할당된다. 하지만 스레드 풀에서는 커넥션과 포그라운드 스레드가 1:1관계가 아니라 하나의 스레드가 여러 개의 커넥션 요청을 전담한다.
포그라운드 스레드
포그라운드 스레드는 최소 MySQL에 접속한 클라이언트 수만큼 존재한다. 주로 클라이언트가 요청하는 쿼리 문장을 처리한다. 클라이언트가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시로 되돌아간다.
이때 이미 스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면 스레드 캐시에 넣지 않고 스레드를 종료시킨다. 스레드 캐시에 일정 개수의 스레드만 존재하게 하는 것이다.
포그라운드 스레드는 데이터를 MySQL 데이터 버퍼 혹은 캐시로부터 가져온다. 버퍼나 캐시에 없는 경우 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.
MyISAM 스토리지 엔진의 경우 디스크 쓰기 작업까지 포그라운드 스레드가 처리한다.
InnoDB 스토리지 엔진의 경우 데이퍼 데이터 버퍼, 캐시까지만 포그라운드 스레드가 처리하고 버퍼로부터 디스크까지 기록하는 작업은 백그라운드 스레드가 처리한다.
백그라운드 스레드
MyISAM 경우에는 별로 해당 사항이 없는 부분이지만 InnoDB는 아래와 같은 여러가지 작업이 백그라운드로 처리된다.
인서트 버퍼를 병합하는 스레드
로그를 디스크로 기록하는 스레드
InnoDB 버퍼 풀의 데이터를 디스크레 기록하는 스레드
데이터를 버퍼로 읽어 오는 스레드
잠금이나 데드락 모니터링하는 스레드
사용자의 요청을 처리하는 도중 데이터의 쓰기 작업은 지연되어 처리될 수 있지만 데이터 읽기 작업은 절대 지연될 수 없다. InnoDB 또한 이러한 방식으로 처리한다. 이러한 이유로 InnoDB에서는 INSERT, UPDATE, DELETE 쿼리로 데이터가 변경되는 경우 데이터가 디스크의 데이터 파일로 완전히 저장될 떄까지 기다리지 않아도 된다.