[MYSQL] MYSQL 아키텍처

MYSQL 엔진 아키텍처 

-. 요청된 SQL 문장을 분석하거나 최적화하는 등, DBMS의 두뇌에 해당하는 처리를 수행한다.

-. MySQL 엔진의 중심 구성 요소

• 접속 및 쿼리 요청을 처리하는 커넥션 핸들러
• SQL파서
  -. 들어온 쿼리를 MySQL이 인식할 수 있는 어휘나 기호로 분리해 트리 형태의 구조로 만들어내는 작업을 수행한다. 
  -. 쿼리의 기본 문법 오류가 이 과정에서 발견되고 사용자에게 오류 메세지를 전달한다.
• 전처리기
  - 파서 과정에서 만들어진 파서 쿼리를 기반으로 문장에 구조적 문제점을 확인한다. 
  -. 데이블 이름이나, 컬럼, 내장 함수와 같은 개체를 매핑해 객체의 존재 여부와 접근 권한 등을 확인하는 과정을 수행한다.
• 옵티마이저
  -. 쿼리를 저렴한 비용으로 가장 빠르게 할 수 있도록 최적화를 하는 역할
  
  

-. MySQL 서버에서도 MySQL 엔진은 하나만 존재한다 

스토리지 엔진

- 스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 읽어오는 부분을 담당한다.
-. MySQL 엔진과 다르게 스토리지 엔진은 여러 개를 동시에 사용할 수 있다. 

※ 8.0 Version

8.0 Version

-. 8.0 부터는 Undo Tablespace 위치가 System Tablespace와 분리 되었고 System, User 영역으로 구분되어 User Undo Tablespace가 System 영역에 영향을 주지 않도록 개선되었다.
-. System Tablespace 내에 존재하던 Data Dictionary는 8.0부터 별도의 Data Fictionary에 저장되비다.

-> frm 파일 읽으며서 생기는 I/O 병목 문제해결

- Temp Tablespaces 구조가 global, session 영역으로 구분되어 관리의 효율성이 높아졌습니다.

 

※ 5.7 version 

 

MySQL의 아키텍처 특징

1. Change Buffer
-. MySQL InnoDB에는 보조 인덱스 I/O 성능 향상을 위한 체인지 버퍼가 존재한다.

1. 보조 인덱스 INSERT, UPDATE, DELETE 연산 요청 시, 해당 페이지 Buffer Pool 상 존재 여부 확인 있을 경우 버퍼에 변경 사항 적용 2. 디스크에 보조 인덱스 변경 사항을 적용 3. Buffer Pool에 없는 페이지의 경우 Change Buffer 영역에 저장 후 추후 디스크로 프러시됨 4. 디스크의 변경된 내용을 버퍼풀에서 읽어옴 ※ 체인지 버퍼의 경우 DML 후 보조 인덱스를 최신 상태로 유지하는데 사용되는 상당한 I/O를 줄일 수 있다. 다만 과거 디스크가 느린 시절에 큰 효과가 있었지만 SSD 등 디스크의 성능이 개선됨에 따라 극적인 성능 개선을 가져오지는 않는다. 또한 변경 사항이 많을 경우 재부팅, 복구 작업이 지연될 수 있기에 주의해야한다. 추가로 이러한 이유 때문인지 Aurora MySQL의 경우 체인지 버퍼를 사용하지 않는다.(None으로 설정되어있으며 변경 불가 )

 

2. DoubleWrite buffer

InnoDB 스토리지 엔진의 Redo Log는 리두 로그 공간의 낭비를 막고 빠르게 Redo log에 쓰기 위해 페이지의 변경된 내용만 기록하게 된다.  (Oracle에서는 이런 내용을 Redo에 Change Vector를 생성하여 표현하고 있으며 블록 변경의 최소 단위를 의미한다.) 이로 인해 InnoDB의 스토리지 엔진에서 Dirty Page를 디스크 파일로 Flush 할때 페이지중 일부만 Disk에 기록된 상태에서 장애 발생 시 그 페이지의 내용은 복구 할 수 없을 수도 있다.  이렇게 페이지가 일부만 기록되는 현상을 파셜 페이지(Patial Page) or 톤 페이지(Torn Page)라고 하는데, 이러 현상은 하드웨어 오작동이나 시스템의 비정상 종료 등으로 발생할 수 있다.  InnoDB 스토리지 엔진에서는 이 같은 문제를 막기 위해 Double Write기법을 이용한다. -. Double Write Buffer(이중 쓰기 버퍼)는 InnoDB 데이터 파일의 적절한 위치에 페이지를 쓰기 전에 버퍼풀에 플러시된 페이즈를 쓰는 저장 연역입니다. -. 페이지 쓰기중 운영체제나 스토리지 하위 시스템 장애 또는 mysqld 프로세스 종료가 있는 경우InnoDB는 Crash Recovery를 하게 되며 복구중에 필요한 페이지를 Double Write Buffer에서 복사본을 찾울 수있다.

A~D까지의 더티 페이지(Dirty Page) 를 디스크로 플러시 한다고 할때 InnoDB 스토리지 엔진은 실제 데이터 파일에 변경 내용을 기록하기 전에 A~D까지의 더티 페이지를 우선 묶어서 한번의 디스크 쓰기로 시스템 테이블스페이스(8.0.20 부터는 별개의 파일) 의 DoubleWrite 버퍼에 기록하게 됩니다. 그리고 InnoDB 스토리지 엔진은 각 더티 페이지를 각가의 파일의 적당한 위치에 하나씩 랜덤으로 쓰기를 실행하게 됩니다. 이렇게 시스템 테이블스페이스의 DoubleWrite 버퍼 공간에 기록된 변경 내용은 실제 데이터 파일 'A'~'D' 더티 페이지가 정상적으로 기록되면 더이상 필요가 없어지게 됩니다. Double Write Buffer(이중 쓰기 버퍼) 의 목적은 실제 데이터 파일의 쓰기가 중간에 실패할 때 복구에 목적이 있습니다. 만약 'A' 와 'B' 페이지는 정상적으로 기록됐지만 'C' 페이지가 기록되는 도중에 운영체제가 비정상적으로 종료 되었다고 가정해보도록 하겠습니다. 그러면 InnoDB 스토리지 엔진은 재시작 될 때 항상 DoubleWrite 버퍼의 내용과 데이터 파일의 페이지들을 모두 비교해서 다른 내용을 담고 있는 페이지가 있으면 Double Write Buffer(이중 쓰기 버퍼) 내용을 데이터 파일의 페이지로 복사를 하게 됩니다.

 

MySQL 쓰레딩 구조

 

-. MySQL 서버는 프로세스 기반이 아닌 쓰레드 기반으로 동작하며, 크게 포그라운드 쓰레드와 백그라운드 쓰레드로 구분 할 수 있다. 

 

 

#참고사이트

https://hinweis.tistory.com/66  

[MySQL] InnoDB 아키텍쳐 구성

https://omty.tistory.com/59

[MySQL] Innodb Change Buffer를 통한 보조 인덱스 I/O 개선