04. 아키텍처 [4.1 MySQL 엔진 아키텍처]

각 단원별 핵심 키워드

• 4.1 MySQL 엔진 아키텍처: 전체 구조, 스레드, 메모리, 스토리지 엔진, 컴포넌트, 쿼리 실행, MySQL 8.0 변경점.
• 4.1.1 MySQL 서버의 전체 구조: 두 가지 주요 계층, Handler API, MySQL 엔진, 스토리지 엔진, 데이터 읽기/쓰기.
  • 4.1.1.1 MySQL 엔진: SQL 쿼리 처리, 클라이언트 연결 관리, 쿼리 파싱 및 최적화, 쿼리 실행.
  • 4.1.1.2 스토리지 엔진: 데이터 읽기/쓰기, 플러그인 아키텍처, InnoDB, MyISAM.
  • 4.1.1.3 핸들러 API: MySQL 엔진과 스토리지 엔진 간 통신, 데이터 작업 함수.
• 4.1.2 MySQL 스레드 구조: 스레드 기반 모델, 포그라운드 스레드, 백그라운드 스레드.
  • 4.1.2.1 포그라운드 스레드: 클라이언트 연결, 사용자 요청 처리, SQL 문 실행, 데이터 읽기/쓰기.
  • 4.1.2.2 백그라운드 스레드: 서버 안정성 및 효율성, 쓰기 스레드, 로그 스레드, 읽기 스레드, 잠금 스레드, 퍼지 스레드.
• 4.1.3 메모리 할당 및 사용 구조: 글로벌 메모리 영역, 로컬 (세션) 메모리 영역.
  • 4.1.3.1 글로벌 메모리 영역: 모든 스레드 공유, 테이블 캐시, InnoDB 버퍼 풀, 어댑티브 해시 인덱스, 리두 로그 버퍼.
  • 4.1.3.2 로컬 (세션) 메모리 영역: 클라이언트 스레드별 할당, 정렬 버퍼, 조인 버퍼, 네트워크 버퍼, 바이너리 로그 버퍼.
• 4.1.4 플러그인 스토리지 엔진 모델: 확장성, InnoDB, MyISAM.
• 4.1.5 컴포넌트: MySQL 8.0 새로운 확장 메커니즘, validate_password 컴포넌트.
• 4.1.6 쿼리 실행 구조: 쿼리 파싱, 전처리기, 옵티마이저, 쿼리 실행, 결과 반환.
  • 4.1.6.1 쿼리 파서: SQL 문 토큰화, 구문 검사, 파스 트리 변환.
  • 4.1.6.2 전처리기: 파스 트리 분석, 이름 유효성 검사, 사용자 권한 확인.
  • 4.1.6.3 옵티마이저: 최적의 실행 계획 결정, 인덱스, 테이블 통계.
  • 4.1.6.4 쿼리 실행기: 최적화된 계획 실행, Handler API 활용, 스토리지 엔진 상호작용.
  • 4.1.6.5 핸들러(스토리지 엔진): MySQL 엔진 요청에 따라 데이터 읽기/쓰기.
• 4.1.7 복제: 
• 4.1.8 쿼리 캐시: MySQL 8.0에서 제거, 동시성 환경 성능 저하 문제.
• 4.1.9 스레드 풀: 엔터프라이즈 에디션 기능, 고정된 워커 스레드, 컨텍스트 스위칭 감소, 오버헤드 감소.
• 4.1.10 트랜잭션 지원 메타데이터: MySQL 8.0 주요 변경점, 모든 시스템 테이블 및 데이터 딕셔너리 정보 InnoDB 저장, 메타데이터 작업 트랜잭션 지원, 데이터 일관성 및 안정성, 크래시-세이프, mysql.ibd.

---

I. MySQL 서버의 전체 구조

MySQL 엔진 (4.1.1.1)

클라이언트로 부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러와 SQL파서 및 전처리기, 옵티마이저가 중심이다.

표준SQL(ANSI) 문법 지원하므로  타 DBMS와 호환가능하다.

 

스토리지 엔진 (4.1.1.2)

스토리지 엔진은 MySQL 서버의 하위 계층으로, 디스크에 데이터를 직접 읽고 쓰는 부분을 담당한다. MySQL 엔진이 요청한 SQL 문장을 분석하여 최적의 실행 계획을 수립하면, 스토리지 엔진은 그 지시에 따라 데이터를 디스크에 저장하거나 읽어오는 역할을 수행한다.

 

MySQL의 독특한 플러그인 아키텍처 덕분에 사용자는 필요에 따라 다양한 스토리지 엔진을 선택할 수 있다. InnoDB가 기본 스토리지 엔진으로 가장 널리 사용되며, MyISAM도 주목할 만한 옵션 중 하나이다.

 

각 테이블은 독립적인 스토리지 엔진을 가질 수 있으며, 특정 테이블에 대한 모든 읽기/쓰기 작업은 해당 테이블에 지정된 스토리지 엔진이 전담하여 처리한다.

 

핸들러 API (4.1.1.3)

핸들러 API는 MySQL 엔진과 스토리지 엔진 간의 상호작용을 위한 인터페이스이다. MySQL 엔진은 쿼리 실행기에서 스토리지 엔진에 데이터를 읽거나 쓰도록 요청할 때 이 API를 사용한다.

이 API는 스토리지 엔진이 데이터 작업을 수행하기 위해 구현해야 할 함수들을 정의하며, 이를 통해 MySQL 엔진은 각 스토리지 엔진의 구체적인 구현 방식을 알 필요 없이 상호작용할 수 있다.

'SHOW GLOBAL STATUS LIKE 'Handler%' 명령어를 통해 핸들러 API를 통한 데이터 작업(읽기, 쓰기, 수정, 삭제 등)이 얼마나 발생했는지 확인할 수 있다.

 

II. MySQL 스레드 구조 (4.1.2)

MySQL 서버는 프로세스 기반이 아닌 스레드 기반 모델을 사용하여 작동하며, 스레드는 크게 포그라운드(클라이언트) 스레드와 백그라운드 스레드로 나뉜다. performance_schema.threads 테이블을 조회하여 현재 실행 중인 스레드 목록을 확인할 수 있다.

 

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

포그라운드 스레드는 클라이언트 연결을 처리하고 사용자 요청을 수행하는 데 주로 사용된다.

각 클라이언트 연결에는 스레드 캐시에서 가져오거나 새로 생성된 포그라운드 스레드가 하나씩 할당된다.

이 스레드들은 SQL 문장을 실행하고, 버퍼나 디스크로부터 데이터를 읽거나 쓰는 작업을 수행한다. 작업이 끝나면 비활성 상태가 된 클라이언트 스레드는 스레드 캐시(Thread Cache)로 돌아가며, 일정 시간 동안 유휴 상태가 지속되면 종료될 수 있다.

 

백그라운드 스레드 (4.1.2.2)

백그라운드 스레드는 서버의 안정성과 효율성을 위해 중요한 내부 작업을 수행한다. InnoDB에서는 여러 작업이 백그라운드 스레드에 의해 처리된다.

주요 백그라운드 스레드는 다음과 같다

- 쓰기 스레드(Write Thread): 메모리 버퍼(예: InnoDB 버퍼 풀)의 데이터를 디스크로 플러시(flush)한다.

- 로그 스레드(Log Thread): 리두 로그(redo log)와 같은 로그 파일에 변경 사항을 기록하여 데이터의 내구성을 보장한다.

- 읽기 스레드(Read Thread): 디스크의 데이터를 메모리 버퍼로 읽어들인다.

- 잠금 스레드(Lock Thread): 특히 InnoDB에서 교착 상태(deadlock)를 모니터링하고 처리한다.

- 퍼지 스레드(Purge Thread): 트랜잭션이 완료된 후 데이터의 이전 버전을 정리한다.

 

InnoDB의 경우 innodb_read_io_threads 및 innodb_write_io_threads와 같은 시스템 변수를 사용하여 읽기/쓰기 스레드의 수를 설정할 수 있다.

III. 메모리 할당 및 사용 구조 (4.1.3)

MySQL은 메모리를 크게 글로벌 메모리 영역과 로컬(세션) 메모리 영역 두 가지로 나누어 관리한다.

글로벌 메모리 영역 (4.1.3.1)

이 메모리 공간은 모든 MySQL 스레드가 공유하며, MySQL 서버가 시작될 때 운영체제로부터 할당받는다. (하나의 메모리 공간만 할당)

대표적인 글로벌 메모리 영역은 다음과 같다:

 

- 테이블 캐시(Table Cache): 열려 있는 테이블의 메타데이터를 저장한다.

- InnoDB 버퍼 풀(InnoDB Buffer Pool): InnoDB 성능에 매우 중요한 요소로, 디스크의 데이터 및 인덱스 페이지를 캐시하여 I/O 속도를 높인다.

- InnoDB 어댑티브 해시 인덱스(InnoDB Adaptive Hash Index): 자주 접근하는 데이터에 대한 조회 속도를 향상시킨다.

- InnoDB 리두 로그 버퍼(InnoDB Redo Log Buffer): 리두 로그 항목을 디스크에 기록하기 전에 임시로 저장하여 트랜잭션 내구성을 보장한다.

 

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

이 메모리는 각 클라이언트 스레드별로 독립적으로 할당(절대 공유되지 않음)되며, 스레드가 종료될 때 해제된다.

대표적인 로컬 메모리 영역은 다음과 같다:

 

- 정렬 버퍼(Sort Buffer): ORDER BY 및 GROUP BY 작업에 사용된다.

- 조인 버퍼(Join Buffer): 테이블 조인에 사용된다.

- 네트워크 버퍼(Network Buffer): 클라이언트와의 데이터 교환을 용이하게 한다.

- 바이너리 로그 버퍼(Binary Log Buffer): 바이너리 로그 이벤트를 저장한다.

 

이 버퍼들의 크기를 신중하게 설정하는 것이 중요하다. 크기가 너무 작으면 성능이 저하될 수 있고, 스레드마다 과도하게 할당하면 메모리 부족 현상이 발생할 수 있다.

IV. 플러그인 스토리지 엔진 모델 (4.1.4)

MySQL의 아키텍처는 확장성이 뛰어나며, 이는 플러그인 스토리지 엔진 모델 덕분이다.

사용자는 InnoDB나 MyISAM과 같은 다양한 스토리지 엔진을 특정 요구 사항에 맞춰 선택하거나 직접 개발하여 서버의 기능을 확장할 수 있다.

SHOW ENGINES 명령어를 사용하면 현재 사용 가능한 스토리지 엔진 목록을 확인할 수 있다.

 

<정리>

MySQL 서버에서 MySQL엔진은 사람 역할을 하고, 각 스토리지 엔진은 자동차 역할을한다.

MySQL엔진이 스토리지 엔진을 조정하기 위해 핸들러라는것을 사용하게 된다.

MySQL엔진이 각 스토리지 엔진에게 데이터를 읽어오거나 저장하도록 명령하려면 반드시 핸들러를 통해야한다

V. 컴포넌트 (4.1.5)

MySQL 8.0부터 도입된 컴포넌트는 기존 플러그인보다 더 견고한 확장 메커니즘이다.

컴포넌트는 플러그인 간 통신이나 의존성 관리와 같은 기존 플러그인의 한계를 해결하기 위해 설계되었다.

대표적인 예로, 이전 버전의 플러그인을 대체한 validate_password 컴포넌트가 있다.

VI. 쿼리 실행 구조

SQL 쿼리가 전송되면 MySQL 엔진은 여러 단계를 거쳐 처리한다.

 

- 쿼리 파서 (4.1.6.1)

SQL 문장을 토큰 단위로 분해하고, 문법적으로 올바른지 검사한 후, 내부적인 파스 트리(parse tree)로 변환한다.

 

- 전처리기 (4.1.6.2)

파스 트리를 추가로 분석하여 이름(테이블, 컬럼 등)의 유효성을 검사하고 사용자의 접근 권한을 확인한다.

 

- 옵티마이저 (4.1.6.3)

가장 핵심적인 단계로, 인덱스 및 테이블 통계와 같은 요소를 고려하여 쿼리에 대한 가장 효율적인 실행 계획을 결정한다.

 

- 쿼리 실행기 (4.1.6.4)

옵티마이저가 수립한 계획을 실행하며, 핸들러 API를 통해 관련 스토리지 엔진과 상호작용하여 데이터 작업을 수행한다.

 

- 핸들러(스토리지 엔진) (4.1.6.5)

쿼리 실행기의 요청에 따라 실제 데이터를 읽고 쓰는 작업을 수행한다. 예를 들어, InnoDB 테이블에 대한 작업은 InnoDB 스토리지 엔진이 담당한다.

VII. 복제

제공된 소스에는 "Real MySQL 8.0" 책의 목차에 '복제' 항목이 언급되어 있으나, 해당 주제에 대한 상세한 정보는 포함되어 있지 않다. 책에서는 이 주제를 16장에서 별도로 다룬다고 명시하고 있다.

 

VIII. 쿼리 캐시

쿼리 캐시는 MySQL 8.0에서 제거되었다.

이전 버전에서는 SELECT 쿼리의 결과를 저장하여 빠른 응답을 제공했지만, 데이터 변경 시 캐시가 자주 무효화되어 동시성이 높은 환경에서 오히려 성능 저하를 유발하는 원인이 되었다.

쿼리 캐시를 제거함으로써 아키텍처가 단순화되고 보다 효율적인 캐싱 전략을 장려하게 되었다.

IX. 스레드 풀

스레드 풀은 MySQL 엔터프라이즈 에디션에서만 제공되는 기능이다. 커뮤니티 에디션에서는 지원되지 않는다.

이 기능은 부하가 높은 상황에서 모든 연결마다 새로운 스레드를 생성하는 대신, 고정된 수의 워커 스레드를 관리한다.

이를 통해 컨텍스트 스위칭과 오버헤드를 줄여 효율성을 향상시킨다.

X. 트랜잭션 지원 메타데이터

MySQL 8.0의 중요한 변경 사항으로, 이전 버전에서 FRM 파일 등 여러 파일에 나뉘어 저장되던 모든 시스템 테이블과 데이터 딕셔너리 정보가 이제는 모두 InnoDB 스토리지 엔진 테이블 내에 저장된다.

 

이 변경으로 인해 모든 메타데이터 작업이 트랜잭션을 지원하게 되어 데이터 일관성과 안정성이 크게 향상되었다.

이제 스키마나 데이터 딕셔너리 변경 작업은 크래시-세이프(crash-safe) 상태가 되어, 서버가 변경 도중에 비정상적으로 종료되더라도 일관된 상태로 복구할 수 있다. 이 정보는 mysql.ibd 파일에 저장되어 전체적인 안정성과 복구 가능성을 높인다.