정리중 -2

MySQL 은 MySQL 엔진과 스토리지 엔진으로 구성되어 있다고 했다.

2021.10.13 - [🌱Backend/DB(MySQL)] - 정리중 #1 엔진 아키텍처

정리중 #1 엔진 아키텍처

 

📌 MySQL은 어떻게 동작하는가

MySQL 엔진은 클라이언트로 오는 요청 처리, SQL문장을 분석하고 최적화하는 역할을 담당한다.

스토리지 엔진은 실제 데이터를 디스크에 저장, 조회하는 역할을 담당한다.

MySQL 서버에 [MySQL 엔진]은 하나만 사용 할 수 있지만, 스토리지는 여러 개를 사용할 수 있다. 

• MySQL 엔진
  ✔ 클라이언트의 요청을 처리하고, SQL문을 [스토리지 엔진의 Handler Api 요청]으로 변환하는 역할
  ✔ Connetion Handler : 커넥션 및 쿼리 요청을 담당
  ✔ SQL Interface : DML, DDL, Procedure, View 등 SQL 문법 인터페이스 제공
  ✔ SQL Parser :  SQL 문법 오류 탐지, 토큰 단위로 나눠 트리 형태로 변환.
  ✔ SQL Optimize : 쿼리의 최적화된 실행 담당. 실행 계획을 만듦
  ✔ Cache & Buffer
  ✔ Query execution engine (api calls) : 만들어진 실행 계획을 Storage 엔진에 요청, 결과를 받아 클라이언트 반환.

예를 들어 GROUP BY 라는 실행계획은 아래와 같은 작업이 진행된다.
1. 실행 엔진이 Handler API로 임시 테이블을 만들라고 요청
2. 실행 엔진은 WHERE 절에 일치하는 레코드를 읽어오라고 Handler API 요청
3. 읽어온 레코드들을 임시테이블에 저장하라고 Handler API 요청
4. 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어오라고 Handler API 요청
5. 최종적으로 실행 엔진은 결과를 사용자나 다른 모듈로 넘김

 

• Storage 엔진
  ✔ 실질적으로 디스크를 읽고, 쓰는 역할
  ✔ Handler Api 를 제공해주며, 이를 통해 MySQL 엔진이 디스크 읽기, 쓰기를 요청하여 결과를 반환 받음.
  ✔ 플러그인 형태로 MySQL 엔진과 의존성이 없으며 쿼리별로 다른 Storage Engine을 사용할 수 있음.

 

---

📌MySQL 쿼리는 어떻게 실행되는가

• MySQL 서버가 클라이언트의 요청(SQL문)을 받음.
• 파서(Parser) 가 SQL문이 유효한지 토큰 단위로 구분해서 파서 트리를 만든다.
• 전처리기(Pre-Processor)가 파서 트리의 구조적인 문제를 파악함. 존재하지 않는 테이블, 권한등을 여기서 구별 
  그리고 생성된 [유효한 SQL 쿼리문의 트리]를 바로 실행하는게 아니라, Optimizer로 넘김.
• 옵티마이저(Optimizer)는 요청받은 쿼리를 최적화시켜 실제 실행계획을 만든다.
  개발자는 EXPLAIN 문으로 MySQL Optimizer가 생성해낸 실행계획을 확인할 수 있다.
  만들어진 실행 계획을 분석하여 MySQL Optimizer가 최적화할 수 있는 쿼리를 작성해야 한다.
  
• 실행 엔진(Execution Engine)은 만들어진 실행 계획대로 Handler API를 통해 스토리지 엔진을 조작한다.
  Storage Engine은 실행 엔진에서 사용할 수 있도록 Handler API를 제공해준다. 그 외의 의존성은 없다.

쿼리를 꼭 개발자가 최적화 해야하나요? 간단한건 그냥 사용하면 안되요?

어떤 회사를 가던, 어떤 서비스를 운영하던 쿼리에는 정답이 없다. 또한 Optimizer는 만능 도구가 아니다.

예를 들어 아래와 같은 간단한 쿼리를 생각해보자.

/*
[직원정보 테이블 A, 부서정보 테이블 B]
각 부서별로 2000년 이후 입사한 사원수를 조회해서
GROUP BY로 입사한 연도별 사원수를 조회하는 쿼리
*/
SELECT
    B.부서명
    , COUNT(*) AS 사원수
    , SUBSTR(TO_CHAR(A.입사일,'yyyymmdd'),1,4) AS 입사년도
FROM
    직원정보 A
    , 부서정보 B ON B.부서ID = A.부서ID
WHERE
    TO_CHAR(A.입사일,'yyyy') >= '2000'
GROUP BY
    B.부서명
    , SUBSTR(TO_CHAR(A.입사일, 'yyyymmdd'),1,4)

 

해당 SQL문은 아래와 같은 조치를 취하면 Optimizer가 최적화 할 여지를 준다.

• 칼럼을 가공하면 인덱스를 안탄다.
  [ TO_CHAR(입사일) >= '2000' ] ➡ [ 입사일 >= TO_DATA(yyyymmdd) ]로 칼럼을 가공하지 않게 만든다.
  인덱스 생성시 Column 이름을 사용하기 때문에, Column에 손을 대면 인덱스를 사용하지 않고 조회한다.
  
  
• 먼저 범위를 줄이고 조건을 걸면 처리할 데이터량이 적어진다.
  [ 부서ID를 기준으로 먼저 GROUP BY ] 이후 [ WHERE 조건 ] 을 넣으면 직원과 부서 테이블이 1:1 관계가 된다.
  
  
• 불필요한 함수 사용을 줄이자
  SUBSTR(TO_CHAR(...)) 는 TO_DATE(...) 하나로 대체 가능하다.

SELECT
    B.부서명
    , A.사원수
    , A.입사년도
FROM
    (SELECT -- 범위를 줄였다. 직원정보 A 테이블을 GROUP BY로 먼저 뽑아냄
        부서ID
        , TO_CHAR(a.입사일, 'yyyy') AS 입사년도
        , COUNT(*) AS 사원수
     FROM
        직원정보
     WHERE
        입사일 >= TO_DATE('20000101','yyyymmdd')
     GROUP BY
        부서ID
        , TO_CHAR(a.입사일, 'yyyy')
    ) A
    , 부서정보 B ON B.부서ID = a.부서id

 

 

---

📌 MySQL 스레드 구조

기존의 MyISBM 스토리지 엔진은 forground thread에서 디스크를 읽고, 쓰는 걸 다 담당했었다.

하지만 InnoDB 엔진은 역할이 확실하게 분리되어, 대부분의 처리는 백그라운드 스레드가 담당한다.

(만약 캐시&버퍼에 값이 없는 경우에만 디스크에서 읽어들이며, 쓰기는 예외 없이 무조건 백그라운드가 담당함.)

foreground는 클라이언트 요청 처리, 읽기만 담당한다. 버퍼에 쓰는 것도 백그라운드의 몫 (InnoDB 기준)

• foreground thread
  ✔ 클라이언트당 하나의 스레드가 생성됨.
  ✔ 고객 창구 역할, 클라이언트가 요청한 쿼리 문장을 처리하는 스레드
  ✔ 데이터 조회 스레드 (버퍼나 캐시에서 가져오고, 없다면 인덱스나 디스크에 접근하여 데이터를 가져옴)
  ✔ 다만 스레드를 무한정 생성하는건 아니고, 설정값(thread_cache_size)을 초과했다면 다른 스레드 반납을 기다림.
  쓰레드는 생성되는 시점에 메모리가 할당된다. 커넥션 개수를 보고 피크 치보다 약간 낮은 size로 할당하자.
  - 필요 이상의 많은 스레드가 생성되고 사라지면 서버 성능에 많은 영향을 끼친다.
  - 반대로 스레드가 너무 부족하다면 다른 스레드 반납을 기다리면서 요청이 딜레이 된다. 
  
  
• background thread
  ✔ 데이터베이스 동작에 필요한 스레드들. 스레드 별로 역할이 나누어져있음.
  ✔ Insert buffer를 병합하는 스레드
  ✔ 로그 기록을 담당하는 스레드
  ✔ InnoDB 버퍼 풀의 데이터를 디스크로 기록(Write)하는 스레드
  ✔ 데이터를 버퍼로 가져오는(Read) 스레드
  ✔ 잠금, 데드락을 모니터링 하는 스레드
  ✔ 모든 백그라운드 스레드의 상태를 관리하는 메인 스레드

 

---

📌 MySQL 메모리 구조

MySQL은 Static과 Local처럼, 글로벌 메모리와 세션 메모리로 나누어짐.

• Global Memory
  ✔ MySQL 서버를 실행할 때 운영체제로 부터 할당받음. 모든 스레드가 공유해서 사용함
  * 다만 자바 static 영역처럼 무조건 처음부터 100% 할당되는건 아니고, 운영체제의 할당 방식에 따라 예약해두고 필요할 때 조금씩 할당해주는 경우도 있다.
  
  
• Session Memory (Local Memory, Connection Memory 라고도 불림)
  ✔ 클라이언트 스레드(foreground thread)가 쿼리를 처리하는데 사용하는 메모리 영역.
  ✔ 당연히 스레드 별로 독립적이며 공유되지 않음.
  ✔ 글로벌과 다르게 필요에 따라 메모리를 할당받으며, 필요없다면 아예 메모리 영역이 아예 없는 경우도 있음.
  세션 메모리의 생명주기는 버퍼의 종류에 따라 다르다. Connection, Result 버퍼는 클라이언트 커넥션이 살아있는 동안 계속 사용하고, Sort Join 버퍼는 쿼리를 실행할 때에만 잠깐 할당 받았다가 완료 후 다시 반환함.
  

 

---

📌 복제 (Replication)

2대 이상의 MySQL 서버가 동일한 데이터를 담도록 하는 데이터베이스 실시간 동기화 기술 이다.

보통 읽기, 쓰기가 모두 가능한 마스터(Primary)와 읽기만 가능한 여러 대의 슬레이브(Replica)로 구성하는게 일반적이다.

기존의 마스터-슬레이브라는 이름은 흑인비하..라는 이유로 Primary와 Replica 또는 Secondary 등으로 부른다. 

 

• 단순한 서버 백업용도를 넘어서, 쓰기 작업의 과부하가 읽기 작업에 영향끼치지 않도록 나눌 수있다.
• 특히 서비스를 운영하다보면, 비즈니스 고객 데이터 분석, 통계용으로 복잡한 쿼리를 작성하는 일이 많다.
  이 경우 별도의 Replica DB 서버를 구축해서 담당하게 만들어야 실제 서비스에 영향이 없다.
  
• 글로벌 서비스의 경우 지역 Replica DB를 구축하여 캐시처럼 사용하면 응답 속도를 크게 개선시킬 수 있다.
• 단, 실시간성이 중요한 데이터는 읽을 때 마스터(Primary)에서 가져와야 데이터 정합성을 보장할 수 있다.
  변경 후 바로 읽어버리면 Replica DB에 아직 반영되지 않아서, 간헐적으로 null이 반환되는 위험성이 있기 때문

맞는 말이지만, 같은 메서드안에서 이렇게 사용하면 간헐적으로 null을 받습니다. 그렇게 빠르게 동기화가 되는건 아니라서.

Primary DB 서버는 서버의 복제를 위해 MySQL 바이너리 로그를 활성화해서 로그를 남길 수 있다.

바이너리 로그에는 DML (데이터 조작)와 DDL(데이터 정의)등 데이터베이스에 변경된 모든 이벤트들을 기록한다.

 

이 바이너리 로그를 Replica DB가 받아와 그대로 복사/저장한 Relay Log를 생성한 뒤, 이를 읽어 동기화를 하는 방식이다.

 

이 과정에는 2개의 Primary 스레드, 1개의 Replica 스레드가 동작한다.

각 스레드는 SHOW REPLICA STATUS 명령을 통해 상태를 확인할 수 있다.

• Replica 서버는 Primary 서버에 접속해 바이너리 로그 정보를 요청한다.
  이 때 Primary에서 바이너리 로그 덤프 스레드 (Binlog dump thread)가 생성되어 로그를 Replica 서버로 전송한다.
  해당 스레드는 Replica에 전송할 이벤트 로그를 읽을 때 일시적으로 바이너리 로그를 잠궈 Thread-Safe 를 보장함.
• Replica 서버에서 START REPLICA 명령으로 복제가 시작되면 Replication I/O Thread가 생성된다.
  이 스레드는 Primary 서버의 Binlog dump 스레드에서 로그를 가져와 로컬 파일인 Relay Log에 복사/저장한다. 
• 그리고 Replica 서버에서 Replication SQL Thread를 만들어 Relay Log를 읽어들이고, 동기화를 진행한다.
  이렇게 쓰기(I/O)와 읽기(SQL)를 분리시켰기 때문에, Replica DB 동기화 속도가 느리더라도 Relay Log를 생성 시간에는 영향을 끼치지 않는다.

 

용어가 난해하긴 하지만 그림으로 보면 어렵지 않다.

Binary log를 통해 데이터베이스를 복구 할 수 있을까요?

mysqlbinlog 도구를 사용하면 해당 이진 파일을 사람이 볼 수 있는 형태로 전환이 가능합니다.

뜯어보면 알겠지만 바이너리 로그는 데이터베이스에 대한 정보가 아니라, 데이터베이스를 생성/수정한 SQL 을 가지고 있는 논리적인 정보 입니다. 그래서 복구는 가능하겠지만, 데이터 복구에 많은 시간이 소요됩니다.

 

2021.10.20 추가) DB 보안을 위해 바이너리 로그를 암호화 하기 때문에 mysqlbinlog를 사용해도 암호화된 바이너리 로그라서 열어볼 수 없다는 메시지가 뜹니다. 이를 사용하려면 로그파일을 생성한 MySQL 서버에서 있는 암호화 키를 사용해야 합니다. 즉, 로그파일만 가져오는게 아니라 실제 운영중인 MySQL 서버에 접속해야 합니다.

 

 

데이터베이스를 물리적으로 통째로 백업하려면 XtraBackup 등의 도구를 사용하면 됩니다.

아래에는 실제로 Maria DB를 날려버려서 Binary Log로 복원했다는 전) 배달의민족 이주현님의 기록입니다 😃

 

 

 

@ 복제 시 주의사항

• 하나의 Replica는 하나의 Primary만 설정 가능하다. 당연한 이야기
• Replica는 반드시 읽기 전용으로 구성해야한다. 성능 문제가 아니라, Primary와의 데이터 무결성, 정합성이 깨진다.
• Replica와 Primary DB의 서버 장비 사양은 동일한 것으로 사용해야한다. 그래야 복제가 가능하니까
• 복제를 위해 바이너리 로그를 생성하는 일은 매우 비용이 큰 작업이다. 복제를 하지 않는다면 로그 생성을 멈추자
• 그래서 바이너리 로그를 기록할 때 트랜잭션 격리수준을 2가지 제공해준다.
  ➡ 1. STATEMENT : Primary DB에 실행된 쿼리 자체를 기록한다. / 로그 용량이 작아서 네트워크 비용은 줄어들지만 쿼리에 따른 결과가 같아야해서 트랜잭션 격리수준을 REPEATABLE READ 이상으로 하는 단점이 있다.
  ➡ 2. ROW : Primary DB에 실행된 쿼리로 인해 변경된 레코드를 기록한다. / 네트워크 비용이 커진다는 단점이 있으나  트랜잭션 격리수준을 최소화(READ COMMITED) 할 수 있어서 레코드 Lock에 영향을 덜 끼친다.
   

---

📌 InnoDB 스토리지 엔진

MySQL이 밀고있는 엔진으로, 레코드 기반의 Lock을 제공하여 높은 동시성 처리가 가능하고, 매우 안정적이다.

위에서 언급한 [ MySQL의 메모리 구조 ]를 다시 가져와보자.

MyISAM 은 기존에 MySQL이 사용해왔던 스토리지 엔진이다.

InnoDB가 사용하는 메모리는 아래와 같다.

• 버퍼 풀 (실제 데이터 + insert 버퍼 + Undo 레코드)
• 바이너리 로그
• Redo 로그
• 스토리지 시스템 테이블 Space (기존의 MyISBM은 이를 파일로 관리해서 손상될 위험이 있었다.)
• 사용자 테이블 Space (Cache)

 

InnoDB 스토리지 엔진의 특징

• 테이블은 Primary Key 순서대로 저장된다. 즉 인덱스 테이블 구조라서 Range Scan이 매우 빠르다.
• 실행계획 결정에 있어 Primary Key가 인덱스로 선택될 확률이 높다.
• MVCC를 이용하여 읽기를 수행하는데 Lock을 걸지 않는다.
• 스토리지 엔진 레벨에서 외래키를 지원한다. 이는 부모 테이블과 자식 테이블에 인덱스를 생성하고, 유효성 검사를 InnoDB가 한다는 말이라서 잠금(Lock)이 전파되는 특징이 있다. 그래서 실무에서는 외래키 제약으 걸지 않는 경우가 많다.
• 자동 데드락 감지가 있다. 그러나 MySQL 엔진에서 발생한 테이블 데드락은 탐지하지 못한다. 이는 innodb_table_lock 을 활성화하면 레코드 뿐 아니라 테이블 레벨의 데드락도 감지하여 해결할 수 있다.
• 서버 시작시 트랜잭션/디스크에 기록된 장애를 자동으로 복구해주는 기능을 제공한다.

 

@ InnoDB 버퍼 풀이란?

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

실직적인 데이터가 들어가므로 메모리의 대부분을 버퍼 풀이 차지하게 된다. 당연히 크기가 클 수록 성능이 향상된다. 다만 실제 서비스에서는 서버 RAM 의 50% 정도로 할당해놨다가, 서버 상태를 보며 조금씩 올리는 것이 좋다. 버퍼 풀을 늘리는건 쉽지만 줄이는건 매우 부담스러운 작업이기 때문.

InnoDB의 전체적인 그림. 왼쪽 위에 버퍼풀의 동작 그림이 그려져있다.

쿼리로 인해 변경되어야 할 레코드들은 메모리 이곳 저곳에 위치한다.

이를 버퍼로 한번에 모아서 쓰기 작업을 만드는 "쓰기 지연"의 역할을 하며 Durty Page (아직 디스크에는 기록되지 않은 공간)를 주기적으로 확인하여 디스크에 저장한다.

 

기존의 InnoDB 버퍼풀은 하나만 사용했었다. 하지만 그로 인해 버퍼풀에 스레드 경합에 의한 Lock이 많이 발생했고, 현재는 그림처럼 여러 개의 작은 버퍼 풀로 나눌 수 있게 변경되었다. innodb_buffer_pool_instances 변수로 개수를 조정 가능하다. 단, 버퍼풀에 할당된 크기가 1GB 미만이라면 1개만 생성된다.

 

Insert나 Update등 데이터 파일을 변경할 때에는, 그 데이터와 연관된 인덱스도 함께 변경해주어야 한다.

이는 작업소모가 크기 때문에, InnoDB 버퍼풀에 변경해햐할 인덱스를 저장할 임시공간( Change buffer )을 만들어둔다.

 

[ Change Buffer ]에는 데이터와 연관되어 변경해야 할 인덱스 페이지를 저장해두고, 즉시 업데이트 하지 않고 쓰기지연을 통해 한번에 처리한다.

 

@ InnoDB가 버퍼풀를 사용하는 방법

버퍼 풀은 3가지 자료구조를 사용하여 백그라운드 스레드로 작동하도록 구현되어 있다.

• LRU + MRU 리스트 [ page_new, page1, page2, page3, ...., page_old ]
  (Most Recnetly Used, 가장 최근에 사용 한 페이지 <-> Least Recently Used, 가장 오랫동안 참조되지 않은 페이지)
• Flush 리스트 - 디스크에 기록할 Durty 페이지가 저장되는 공간
• Free 리스트 - 수정되지 않은 Clean 페이지가 저장되는 공간 ( LRU+MRU에 있는 Clean 페이지가 여기로 옮겨짐 )

 

• 1-1. InnoDB는 필요한 데이터(레코드)가 있다면 먼저 버퍼 풀에 존재여부를 검사한다.
  ( 어댑티브 해쉬 인덱스로 페이지검색 ➡ 테이블 인덱스 B-Tree를 이용해 버퍼풀 탐색 ➡ 찾았다면 해당 페이지 포인터를 MRU 쪽으로 승급)
• 1-2. 만약 버퍼풀에 없다면, 디스크를 읽어 버퍼풀에 적재하고 해당 페이지의 포인터를 LRU 헤더에 추가한다.
• 2. 작동하다가 LRU 헤더 부분에 적재된 데이터가 읽힌다면 MRU 방향으로 포인터를 이동한다.
  단 대량 읽기의 경우 실제 쿼리보다 더 많은량을 가져오는 경우가 있다. 이때는 MRU 이동이 발생하지 않는다.
• 3. 오랫동안 사용하지 않아 LRU 끝부분으로 밀려난 경우(Aging) 버퍼 풀의 공간을 확보(Eviction)할 때 삭제된다.
• 4. 반대로 데이터가 자주 접근되어 MRU 부분으로 왔다면 해당 페이지를 [ 어댑티브 해시 인덱스 ]에 추가한다.

 

다만 이렇게 버퍼를 거쳐서 동작하게되면, 실제 디스크에는 나중에 기록되므로 DB의 ACID를 보장할 수 없다.

그래서 InnoDB는 ReDo 로그라는걸 사용한다.

Redo Log는 하나가 아닐 수도 있다. 여러 개 사용가능.

InnoDB 버퍼풀에는 디스크와 동일한 상태인 Clean Page와 쿼리로 변경된 Durty Page가 함께 있을 것이다.

Redo 로그는 Durty Page의 포인터를 가지고 있는 리스트이며 앞과 뒤가 연결된 순환 리스트처럼 사용한다.

즉, 계속 사용하다보면 Redo 로그에 있는 진입점(Log Entry)은 언젠가 덮어 씌워지게 된다.

 

여기에서 아직 기록이 안되서 재사용하면 안되는 곳을 Active Redo Log이라 부른다.

 

기본적으로 로그는 계속 증가하는 숫자인 LSN (Log Sequence Number)을 사용한다. InnoDB 스토리지 엔진은 주기적으로 Redo로그의 내용을 디스크에 저장하는 체크포인트 이벤트를 발생시키는데 이 때 LSN을 기준으로 저장한다.

 

그래서 LSN을 이용해서 가장 최근 체크포인트와 마지막 Redo log 엔트리의 차이를 [ Checkpoint Age ]라고 부른다. 말 그대로 아직 디스크에 저장되지 않은 페이지 개수이다.

 

참고로 Redo 로그는 메모리 공간을 낭비를 막기 위해서 전체 페이지가 아니라, 변경된 부분만 기록해둔다.

그래서 하드웨어 오작동, 서버 다운등이 발생하면 Redo로그만으로는 복구 할 수 없는데, 이를 위해 InnoDB에서 Double Write Buffer를 제공한다.

 쉽게 말하면 파일의 변경 내용을 기록하기 전, 따로 InnoDB 시스템 테이블공간(DoubleWrite Buffer)에 더티 페이지를 복사해둔다. 이는 MySQL 서버를 시작할 때 '복구' 용도로만 사용된다. 그래서 대충 기록만 해두고 만약 하드웨어 오작동, 서버 장애등이 났을 떄 DoubleWrite 버퍼 내용을 하나하나 모두 비교해서 다른 내용을 담은 페이지가 있다면, 버퍼에 있는 내용으로 덮어씌운다. 

 

내용을 보면 I/O 작업에 상당한 부하를 줄 것 같지만, 하드디스크의 특성상 연속된 순차기록은 거의 부담이 되지 않는다.

다만 SSD의 경우 랜덤 I/O와 순차 I/O 둘 다 부담이 되기 떄문에 데이터 무결성이 중요한 경우에만 innodb_doublewrite 변수로 해당 기능을 사용하는 것이 좋다. 

만약 성능을 높이려고 [Redo 로그 동기화 기능]_(innodb_flush_log_at_trx_commit) 을 off했다면, 이 기능도 함께 꺼서 성능을 향상 시키도록 하자. 

 

@ 이렇게까지 Redo로그를 설명한 이유는, 아래의 예시를 이해하기 위함이다.

1 버퍼풀은 100GB 인데, Redo 로그의 전체 크기는 100MB인 경우
2 버퍼풀은 100MB 인데, Redo 로그의 전체 크기는 100GB인 경우

1번의 경우 Redo로그의 크기가 100MB라서, 로그의 크기(Checkpoint Age)는 최대 100MB만 허용된다.

만약 평균적인 로그의 크기가 4KB라면, 대충 25600개의 페이지만 버퍼 풀에 저장할 수 있다는 말이다. 이 경우 버퍼풀을 아무리 크게 할당한다고 한들, Redo 로그 크기가 부족해서 대부분(99G 정도가) 사용하지 않고 비어있게 된다.

 

2번의 경우 이론적으로는 아무런 문제가 없다고 할 수도 있겠다. 그냥 버퍼 풀이 작은거니까

하지만 JVM의 GC를 생각해보자. 2번의 상태로 서비스를 운영해서 Checkpoint Age가 어마어마하게 커진다면, 어떤 상황이 발생할까? InnoDB 엔진은 한번에 어마어마한 디스크 작업을 받게되어 다른 작업을 처리하지 못할 것이다.

 

 

 

@ MVCC (Multi Version Concurrency Control), Undo 로그

Undo 로그는 데이터가 변경되었을 때 (Update, Delete) 변경되기 이전의 데이터를 보관하는 공간이다.

롤백이나 트랜잭션 격리수준에 대응하는 MVCC에 사용된다.

 

MVCC는 하나의 레코드에 대해 여러가지 버전의 데이터를 관리하는 방법이다.

쉽게말해 트랜잭션의 커밋/롤백 여부랑 관계없이, 항상 변경 이전의 레코드를 Undo로그에 남겨둔다.

 

굳이 이렇게 사용하는 이유는, 트랜잭션 데이터 정합성(REPEATABLE READ)를 스레드 Lock 없이 구현하기 위함이다.

한 트랜잭션에서 같은 데이터를 여러번 읽었을 때, 데이터의 값이 달라질 수 있는 정합성 문제를 Undo 로그로 해결한다.

처음 읽었을 땐 Jeju였는데, 중간에 다른 스레드가 Commit해버려서 값이 변경되어버리면? 난감하다. 같은 트랜잭션인데 다시 읽으면 값이 바뀐다.

단, 이렇게 Undo를 사용하면 트랜잭션의 범위가 길어지고 이전 버전의 레코드(데이터)들이 쌓여서 시스템 테이블을 낭비할 수 있기 때문에 [REPEATABLE_READ를 트랜잭션 격리수준으로 사용]한다면 트랜잭션 범위를 최소화할 필요가 있다.