Real MySQL InnoDB 버퍼 풀 · 리두 로그 · 더블라이트 버퍼

About this offer

1. 버퍼 풀 기본 Q1. 버퍼 풀이 무엇이고, 어디에 위치하나요? 버퍼 풀은 InnoDB가 테이블과 인덱스의 데이터 페이지를 메모리에 캐싱해 두는 공간 입니다. 디스크가 아니라 메모리 에 있습니다. 읽기 캐시 역할도 하고, 변경된 페이지를 모아 두었다가 나중에 디스크에 한꺼번에 쓰는 쓰기 버퍼 역할도 합니다. 그래서 InnoDB 성능에 가장 큰 영향을 주는 메모리 설정이 innodb_buffer_pool_size 입니다. Q2. 버퍼 풀이 없다면 어떤 문제가 생기나요? 왜 필요한가요? 모든 읽기와 쓰기가 매번 디스크 I/O로 이어집니다. 디스크, 특히 랜덤 I/O는 메모리보다 훨씬 느리기 때문에 쿼리 응답 시간과 처리량이 크게 떨어집니다. 읽기 : 자주 쓰는 페이지를 메모리에서 바로 제공해 디스크 읽기를 줄입니다. 쓰기 : 변경 내용을 메모리에 모았다가 쓰기 때문에, 같은 페이지가 여러 번 바뀌어도 디스크에는 한 번만 쓰면 됩니다. Q3. 버퍼 풀은 어떤 단위로 캐싱하나요? 페이지 단위 로 캐싱하며, 기본 크기는 16KB 입니다( innodb_page_size ). 레코드 한 건만 필요해도 그 레코드가 들어 있는 16KB 페이지 전체를 읽어 옵니다. 2. 캐시 히트 · 미스와 LRU Q4. 캐시 히트와 미스는 무엇이고, 미스가 나면 내부적으로 어떤 일이 일어나나요? 히트(hit) : 필요한 페이지가 이미 버퍼 풀에 있어서 메모리에서 바로 읽는 경우 미스(miss) : 버퍼 풀에 없어서 디스크에서 읽어 와야 하는 경우 미스가 나면 다음 순서로 처리합니다. Free 리스트에서 빈 페이지를 하나 받습니다. 빈 페이지가 없으면 LRU 리스트 끝에서 오래 안 쓴 페이지를 제거해 공간을 만듭니다. 그 페이지가 dirty라면 먼저 디스크에 flush합니다. 디스크에서 읽은 페이지를 LRU 리스트의 Old 서브리스트 맨 앞(중간점) 에 넣습니다. Q5. LRU 리스트의 Old 서브리스트란 무엇인가요? LRU 리스트 는 버퍼 풀에 올라온 페이지들을 한 줄로 세워 둔 목록입니다. 앞쪽은 최근에 쓴 페이지, 뒤쪽은 오래 안 쓴 페이지이고, 공간이 부족하면 맨 뒤의 페이지부터 버립니다. InnoDB는 이 리스트를 두 구역으로 나눕니다. [ 머리 ←─── New(Young) 서브리스트 ───→ | ←── Old 서브리스트 ──→ 꼬리 ] 자주 쓰이는 페이지 (약 63%) 중간점 새로 들어온 페이지 (약 37%) ↑ 여기부터 버려짐 Old 서브리스트는 LRU 리스트의 뒤쪽 약 37% 구역 ( innodb_old_blocks_pct )으로, 디스크에서 새로 읽어 온 페이지가 처음 들어가는 대기실 입니다. 새 페이지는 리스트 맨 앞이 아니라 Old 구역의 맨 앞(중간점) 에 들어갑니다. Old 구역에 있는 동안 다시 사용되지 않으면 뒤로 밀리다가 꼬리에서 버려집니다. 일정 시간( innodb_old_blocks_time , 기본 1초)이 지난 뒤 다시 사용되면 New 구역으로 승격 됩니다. 이렇게 하는 이유는 풀 스캔처럼 한 번 읽고 다시 안 쓸 페이지가 대량으로 들어와도, 그 페이지들이 Old 구역에서만 돌다가 버려지게 하기 위해서입니다. 그래서 자주 쓰는 New 구역의 페이지가 밀려나지 않습니다. 면접 답변 Old 서브리스트는 InnoDB LRU 리스트의 뒤쪽, 기본 37% 구간입니다. 디스크에서 새로 읽은 페이지가 처음 들어가는 영역으로, 여기서 다시 접근되면 New 구간으로 승격되고 접근되지 않으면 꼬리에서 가장 먼저 제거됩니다. 풀 스캔 같은 일회성 읽기가 자주 쓰는 페이지를 밀어내지 않게 하는 장치입니다. Q6. 캐시 미스는 왜 발생하나요? 처음 접근하는 데이터라서 아직 캐싱된 적이 없는 경우 자주 쓰는 데이터(워킹 셋)가 버퍼 풀보다 커서 페이지가 계속 밀려나는 경우 대량 스캔이나 배치 작업이 캐시를 오염시키는 경우 서버를 재시작해서 버퍼 풀이 비어 있는 경우 (버퍼 풀 덤프·로드 기능으로 완화할 수 있음) Q7. 데이터가 버퍼 풀보다 클 때 공간은 어떻게 확보하나요? (eviction) LRU 리스트의 끝, 즉 Old 서브리스트 꼬리에 있는 가장 오래 안 쓴 페이지부터 제거합니다. clean 페이지는 그냥 버리고, dirty 페이지는 먼저 디스크에 쓴 뒤 비웁니다. Page Cleaner 스레드가 백그라운드에서 LRU 끝부분을 미리 정리해 두기 때문에, 미스가 날 때마다 즉시 flush하는 상황을 최대한 피합니다. 3. Dirty Page와 Flush Q8. dirty page란 무엇이고, 변경 데이터는 언제 어떻게 디스크에 반영되나요? 버퍼 풀에서는 변경됐지만 아직 디스크에 쓰이지 않은 페이지 를 dirty page라고 합니다. 커밋할 때 바로 디스크에 쓰지 않고, Page Cleaner 스레드가 백그라운드에서 flush 합니다. flush가 일어나는 시점은 다음과 같습니다. 리두 로그 공간을 확보해야 할 때 (체크포인트 진행) dirty 페이지 비율이 설정값( innodb_max_dirty_pages_pct )에 가까워질 때 LRU에서 페이지를 제거해야 할 때 서버를 종료할 때 InnoDB는 어댑티브 플러시로 이 속도를 자동 조절합니다. Q9. 버퍼 풀의 세 가지 리스트(free / LRU / flush)는 각각 어떤 역할을 하나요? 리스트 역할 Free list 아직 사용하지 않은 빈 페이지 목록. 디스크에서 새 페이지를 읽어 올 때 여기서 공간을 받음 LRU list 디스크에서 읽어 온 페이지 목록. 최근 사용 순으로 관리하며, 어떤 페이지를 버릴지 정하는 기준 Flush list dirty page 목록. 처음 변경된 시점의 LSN 순으로 정렬되며, 체크포인트 때 어떤 페이지부터 쓸지 정하는 기준 LRU 리스트와 flush 리스트에 같은 페이지가 동시에 들어 있을 수 있습니다. 4. 리두 로그와 WAL Q10. 디스크에 바로 쓰지 않는데, 장애가 나도 데이터가 안전한 이유는? (redo log / WAL) WAL(Write-Ahead Logging) 원칙 때문입니다. 데이터 페이지보다 변경 내역인 리두 로그를 먼저 디스크에 기록 합니다. 커밋 시점에는 리두 로그만 디스크에 확실히 써 두면 됩니다(fsync). 장애로 버퍼 풀의 dirty page가 사라져도, 재시작할 때 리두 로그를 다시 적용해 커밋된 변경을 복구할 수 있습니다. Q11. 버퍼 풀과 리두 로그는 왜 둘 다 필요한가요? 역할이 다르기 때문입니다. 버퍼 풀은 성능 담당입니다. 데이터 페이지는 디스크 여기저기에 흩어져 있어서 바로 쓰면 랜덤 I/O가 되므로, 변경을 메모리에 모아 두었다가 나중에 몰아서 씁니다. 리두 로그는 내구성 담당입니다. 순차 append 방식이라 쓰기가 빠르고, 커밋된 내용이 사라지지 않게 보장합니다. 버퍼 풀만 있으면 장애가 났을 때 데이터를 잃고, 리두 로그만 있으면 커밋할 때마다 랜덤 I/O가 발생합니다. 둘을 함께 써서 빠르면서도 안전한 구조를 만듭니다. Q12. 커밋 시 디스크에 보장되는 것은 데이터 페이지인가요, 리두 로그인가요? 리두 로그 입니다. innodb_flush_log_at_trx_commit=1 (기본값)이면 커밋할 때마다 리두 로그를 디스크에 fsync합니다. 데이터 페이지는 나중에 비동기로 flush됩니다. 이 설정을 0이나 2로 바꾸면 성능은 좋아지지만, 장애 시 최대 약 1초 분량의 커밋을 잃을 수 있습니다. Q13. LSN이란 무엇이고, 버퍼 풀·리두 로그와 어떻게 연결되나요? 리두 로그에 기록이 쌓일 때마다 계속 커지기만 하는 일련번호 로, 실제로는 리두 로그상의 누적 바이트 위치입니다. 각 데이터 페이지는 자신을 마지막으로 변경한 LSN 을 페이지 헤더에 저장합니다. flush list는 페이지가 처음 변경된 LSN 순서로 정렬됩니다. 체크포인트 LSN 은 "이 지점까지의 변경은 모두 디스크에 반영됐다"는 기준선입니다. 복구할 때는 페이지에 저장된 LSN과 리두 레코드의 LSN을 비교해서, 아직 반영되지 않은 변경만 다시 적용합니다. Q14. 체크포인트란 무엇인가요? "이 LSN 이전의 변경은 모두 데이터 파일에 반영됐다"고 표시하는 지점 입니다. flush list에서 가장 오래된 dirty page부터 디스크에 쓰면 체크포인트가 앞으로 이동합니다. 체크포인트 이전의 리두 로그는 더 이상 필요 없으므로 그 공간을 재사용할 수 있고, 크래시 복구도 체크포인트 이후부터만 리두를 적용하면 됩니다. InnoDB는 서비스를 멈추지 않고 조금씩 진행하는 퍼지(fuzzy) 체크포인트 방식을 씁니다. Q15. 리두 로그가 너무 작으면(또는 꽉 차면) 어떻게 되나요? 리두 로그는 순환 구조라서, 체크포인트가 따라오지 못하면 새 로그를 쓸 공간이 없어집니다. 그러면 InnoDB가 dirty page를 급하게 강제 flush(sync flush) 하고, 그동안 쓰기 트랜잭션이 대기하면서 처리량이 갑자기 떨어지는 스톨 이 발생합니다. 반대로 리두 로그가 너무 크면 크래시 복구 시간이 길어질 수 있으므로 쓰기 부하에 맞게 크기를 정해야 합니다(8.0.30부터 innodb_redo_log_capacity ). Q16. 크래시가 났을 때 버퍼 풀은 비어 있는데, 복구는 어떻게 이뤄지나요? 마지막 체크포인트 LSN 을 찾습니다. 그 이후의 리두 로그를 순서대로 읽으면서 해당 페이지를 디스크에서 버퍼 풀로 읽어 옵니다. 페이지 LSN이 리두 레코드의 LSN보다 작은 경우에만 변경을 다시 적용합니다 ( Redo, roll-forward ). 그다음 언두 로그 로 커밋되지 않은 트랜잭션을 롤백합니다 ( Undo ). 결과적으로 커밋된 것은 살리고, 커밋 안 된 것은 되돌린 상태가 됩니다. Q17. 리두 로그와 바이너리 로그(binlog)는 어떻게 다른가요? 구분 리두 로그 바이너리 로그 계층 InnoDB 엔진 레벨 MySQL 서버 레벨 (모든 엔진) 내용 페이지 변경 (물리적) SQL문 또는 Row 변경 (논리적) 구조 고정 크기, 순환 재사용 파일 단위로 계속 추가 목적 크래시 복구 복제, 시점 복구(PITR) 면접 답변 두 로그는 소속 계층과 목적이 다릅니다. 리두 로그는 InnoDB 엔진 이 남기는 로그입니다. '어느 페이지를 어떻게 바꿨다'는 물리적인 변경 기록 이고, 목적은 크래시 복구 입니다. 크기가 고정돼 있어서 체크포인트가 지난 부분은 덮어쓰며 순환 재사용합니다. 바이너리 로그는 MySQL 서버 레벨 에서 엔진과 상관없이 남기는 로그입니다. 실행된 SQL이나 변경된 행 같은 논리적인 기록 이고, 목적은 복제 와 특정 시점 복구 입니다. 파일이 계속 추가되는 구조입니다. 커밋할 때 둘 중 하나만 기록되면 원본 서버와 복제 서버의 데이터가 어긋나기 때문에, MySQL은 내부적으로 2단계 커밋 으로 두 로그의 일관성을 맞춥니다. 한 줄 요약 : 리두 로그는 "이 서버를 살리기 위한 로그", 바이너리 로그는 "다른 서버에 똑같이 전달하거나 과거 시점으로 돌리기 위한 로그"입니다. 꼬리 질문: 2단계 커밋은 어떻게 동작하나요? 먼저 리두 로그에 prepare 상태로 기록하고, 이어서 바이너리 로그를 기록한 뒤, 마지막으로 리두 로그를 commit 상태로 표시합니다. 장애가 나면 바이너리 로그에 기록이 있는지를 기준으로 커밋할지 롤백할지 결정합니다. 5. 어댑티브 해시 인덱스 Q18. B-Tree 인덱스란 무엇인가요? 루트, 브랜치, 리프로 이루어진 균형 트리 입니다. 키가 정렬된 상태로 저장되고 리프 노드끼리 연결되어 있습니다. 어떤 키를 찾든 트리 높이만큼만 탐색하면 되므로 O(log N)이고, 정렬과 범위 검색에도 유리합니다. Q19. 어댑티브 해시 인덱스란 무엇이고, B-Tree와 어떤 관계인가요? InnoDB가 자주 조회되는 B-Tree 페이지를 감지해서 메모리에 자동으로 만드는 해시 인덱스 입니다. 키 값으로 버퍼 풀의 레코드 위치를 바로 찾기 때문에, 루트부터 리프까지 내려가는 탐색을 건너뜁니다. B-Tree를 대체하는 것이 아니라 B-Tree 위에 얹는 캐시 이며, 디스크에는 저장되지 않습니다. 동등 비교( = ) 조회에서만 효과가 있고 범위 검색에는 쓰이지 않습니다. 쓰기가 많은 환경에서는 오히려 락 경합이 생길 수 있어서 끄기도 합니다. 6. Doublewrite Buffer Q20. Doublewrite Buffer란 무엇인가요? 어떤 문제를 해결하나요? 면접 답변 더블라이트 버퍼는 InnoDB가 dirty page를 데이터 파일에 쓰기 전에, 같은 페이지를 별도 영역에 먼저 한 번 더 써 두는 안전장치 입니다. InnoDB 페이지는 16KB인데 OS나 디스크는 보통 4KB 단위로 씁니다. 그래서 쓰는 도중에 장애가 나면 페이지의 일부만 새 내용으로 바뀐 깨진 페이지(torn page) 가 생길 수 있습니다. 더블라이트 버퍼는 이런 경우에 대비해 온전한 사본을 남겨 두고, 장애가 나면 그 사본으로 페이지를 먼저 복원합니다. Q21. 리두 로그가 있는데 왜 더블라이트 버퍼가 따로 필요한가요? 리두 로그는 페이지 전체 이미지가 아니라 "이 페이지의 이 위치를 이렇게 바꿔라"라는 변경 기록 입니다. 그래서 원본 페이지가 온전하다는 전제 에서만 적용할 수 있습니다. 페이지 자체가 반쯤 깨져 있으면 리두를 적용할 기준이 없으므로, 더블라이트 버퍼가 온전한 페이지 사본 을 제공해야 리두 복구가 가능해집니다. Q22. 더블라이트 버퍼는 어떻게 동작하나요? 쓰기 순서로 설명해 보세요. 면접 답변 dirty page를 디스크에 쓸 때 두 단계로 나눠서 씁니다. 1단계 로, flush할 페이지들을 데이터 파일에 바로 쓰지 않고 먼저 더블라이트 영역에 여러 페이지를 묶어서 순차적으로 쓰고, fsync로 디스크 기록을 확정 합니다. 이제 온전한 사본이 디스크에 안전하게 남은 상태입니다. 2단계 로, 같은 페이지들을 데이터 파일의 원래 위치에 쓰고 다시 fsync 합니다. 이렇게 하면 어느 시점에 장애가 나도 둘 중 하나는 반드시 온전합니다. 1단계 도중에 장애가 나면 원본 데이터 파일은 손대지 않은 상태라 원본이 온전하고, 2단계 도중에 장애가 나서 원본이 깨지면 더블라이트 영역의 사본으로 복원합니다. 참고로 MySQL 8.0.20부터 더블라이트 영역은 시스템 테이블스페이스가 아닌 별도 파일( #ib_*.dblwr )로 분리됐습니다. 버퍼 풀의 dirty page │ ├─1 더블라이트 영역에 묶어서 순차 쓰기 → fsync (사본 확보) │ └─2 데이터 파일 원래 위치에 쓰기 → fsync (실제 반영) Q23. 데이터를 두 번 쓰니 성능이 절반으로 떨어지지 않나요? 절반까지 떨어지지는 않습니다. 더블라이트 쓰기는 여러 페이지를 묶어 한 번에 쓰는 순차 I/O 이고 fsync도 묶음 단위로 한 번만 합니다. 실제 비용이 큰 것은 원래 위치에 쓰는 랜덤 I/O 쪽입니다. 그래서 오버헤드는 보통 수 %에서 10% 정도 입니다. 파일 시스템이나 스토리지가 원자적 쓰기를 보장한다면(ZFS 등) innodb_doublewrite=OFF 로 끌 수도 있습니다. Q24. 크래시 복구 시 더블라이트 버퍼와 리두 로그는 어떤 순서로 동작하나요? 더블라이트 단계 : 데이터 파일의 페이지 체크섬을 검사해서 깨진 페이지를 찾고, 더블라이트 영역의 온전한 사본으로 교체합니다. 더블라이트 영역에 쓰는 도중에 크래시가 났다면 원본 페이지는 아직 손대지 않은 상태이므로 원본을 그대로 씁니다. 리두 단계 : 이제 모든 페이지가 온전하므로, 체크포인트 이후의 리두 로그를 적용해 커밋된 변경을 복구합니다. 언두 단계 : 커밋되지 않은 트랜잭션을 롤백합니다. 정리하면 페이지를 먼저 온전하게 만들고 → 리두로 변경을 다시 적용하고 → 언두로 미완료 트랜잭션을 정리 하는 순서입니다. 7. 추가 질문 Q25. InnoDB란 무엇이고, 어떻게 읽나요? "이노디비" 라고 읽습니다. 핀란드 회사 Innobase가 만들어서 붙은 이름입니다. InnoDB는 MySQL의 기본 스토리지 엔진 입니다. MySQL은 두 층으로 나눠 볼 수 있습니다. MySQL 서버 층 : SQL을 해석하고, 실행 계획을 세우고, 권한을 확인합니다. 스토리지 엔진 층 : 데이터를 실제로 디스크에 저장하고 읽습니다. InnoDB, MyISAM 등이 여기에 해당합니다. InnoDB는 트랜잭션, 행 단위 잠금, 장애 복구, 외래 키를 지원합니다. 버퍼 풀, 리두 로그, 언두 로그, 더블라이트 버퍼는 모두 InnoDB 안의 구성 요소입니다. Q26. 리두(Redo)와 언두(Undo)는 각각 무엇인가요? 이름 그대로 Redo는 "다시 하기", Undo는 "되돌리기" 입니다. 리두 로그 (Redo) 언두 로그 (Undo) 기록 내용 변경 후 내용 ("이렇게 바꿨다") 변경 전 내용 ("원래는 이랬다") 용도 장애 시 커밋된 변경을 다시 적용 커밋 안 된 변경을 되돌림 (롤백) 추가 용도 – MVCC: 다른 트랜잭션에게 변경 전 데이터를 보여줌 예를 들어 잔액을 100에서 50으로 바꾸면, 리두 로그: "잔액을 50으로 바꿨다" → 장애가 나면 다시 50으로 만듭니다. 언두 로그: "원래 100이었다" → 롤백하면 다시 100으로 되돌립니다. Q27. 데이터 페이지란 무엇인가요? InnoDB가 디스크와 메모리 사이에서 데이터를 주고받는 최소 단위 묶음이며, 기본 크기는 16KB입니다. 책에 비유하면 레코드(행)는 문장이고, 페이지는 책의 한 쪽입니다. 문장 하나만 읽고 싶어도 그 쪽을 통째로 펼쳐야 하듯이, 행 하나가 필요해도 InnoDB는 그 행이 들어 있는 16KB 페이지 전체를 읽어서 버퍼 풀에 올립니다. 테이블 데이터와 인덱스는 모두 이런 페이지들로 나뉘어 디스크 파일(.ibd)에 저장됩니다. Q28. LSN이 "단조 증가하는 일련번호"라는 것은 무슨 뜻인가요? 단조 증가 : 계속 커지기만 하고 절대 줄어들거나 되돌아가지 않는다는 뜻입니다. LSN(Log Sequence Number) : 리두 로그에 지금까지 몇 바이트를 기록했는지를 나타내는 누적 위치값입니다. 은행 대기표처럼 먼저 생긴 기록일수록 번호가 작습니다. 변경 A 기록 → LSN 1000 변경 B 기록 → LSN 1200 변경 C 기록 → LSN 1500 번호가 항상 커지기 때문에 어떤 일이 먼저 일어났는지 숫자 비교만으로 알 수 있습니다. 페이지에 "마지막 변경 LSN = 1200"이 적혀 있다면 변경 B까지는 반영돼 있고 변경 C(1500)는 아직이라는 뜻이므로, 복구할 때 변경 C만 다시 적용하면 됩니다. Q29. 퍼지 체크포인트(Fuzzy Checkpoint)란 무엇인가요? 체크포인트를 만드는 방식에는 두 가지가 있습니다. 샤프 체크포인트(Sharp) : 모든 dirty page를 한 번에 디스크에 씁니다. 그동안 다른 작업이 멈추며, 서버 종료 시 사용합니다. 퍼지 체크포인트(Fuzzy) : dirty page를 조금씩, 오래된 것부터 백그라운드에서 나눠 씁니다. 서비스를 멈추지 않습니다. 샤프는 손님을 다 내보내고 한 번에 대청소하는 방식이고, 퍼지는 영업 중에 틈틈이 조금씩 치우는 방식입니다. 운영 중인 InnoDB는 퍼지 방식을 쓰며, flush list에서 가장 오래된 변경부터 디스크에 쓰고 그만큼 체크포인트 LSN을 앞으로 옮깁니다. Q30. 클러스터드 인덱스와 세컨더리 인덱스는 무엇인가요? 클러스터드 인덱스 (Clustered Index) PK 기준으로 실제 데이터(행 전체)를 정렬해서 저장하는 인덱스 입니다. B-Tree의 리프 노드에 행 데이터 자체 가 들어 있습니다. 인덱스가 곧 테이블입니다. 테이블당 하나만 존재합니다. PK가 없으면 Unique 컬럼을 쓰고, 그것도 없으면 숨겨진 키를 만들어 씁니다. 세컨더리 인덱스 (Secondary Index) PK가 아닌 컬럼에 따로 만든 인덱스입니다 (예: email ). 리프 노드에 인덱스 컬럼 값과 PK 값 만 들어 있습니다. 그래서 조회가 두 단계입니다. 세컨더리 인덱스에서 PK를 찾은 뒤, 그 PK로 클러스터드 인덱스를 한 번 더 탐색해 실제 행을 가져옵니다. 책에 비유하면 클러스터드 인덱스는 쪽 번호 순서대로 정렬된 본문 자체 이고, 세컨더리 인덱스는 책 뒤의 찾아보기 입니다. Q31. flush와 fsync는 각각 무엇인가요? flush : 버퍼 풀(메모리)에서 바뀐 dirty page를 디스크로 내려 쓰는 것 입니다. fsync : OS에게 "방금 쓴 데이터를 OS 캐시에 두지 말고 실제 디스크에 기록하라" 고 강제하는 시스템 호출입니다. 프로그램이 write를 호출해도 데이터는 보통 OS의 메모리