본문 바로가기
카테고리 없음

4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(3)

by 규난 2022. 12. 2.
728x90

2022.12.01 - [RealMySQL] - 4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(2)

 

4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(2)

2022.11.28 - [RealMySQL] - 4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(1) 4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(1) 이번 포스트에서는 MySQL의 스토리지 엔진 중 하나인 InnoDB 스토리지

rbsks.tistory.com

2022.11.28 - [RealMySQL] - 4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(1)

 

4.MySQL 아키텍처 - 4.2 InnoDB 스토리지 엔진 아키텍처(1)

이번 포스트에서는 MySQL의 스토리지 엔진 중 하나인 InnoDB 스토리지 엔진 아키텍처에 대해서 포스트하려합니다. InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의

rbsks.tistory.com

전 포스트에 이어서 MySQL InnoDB 스토리지 엔진 아키텍처에 대해서 더 알아보려고 합니다.

 

언두 로그

InnoDB 스토리지 엔진은 트랜잭션과 격리 수준을 보장하기 위해 DML(INSERT, UPDATE, DELETE)로 변경되기 이전 버전의 데이터를 별도로 백업하는데 이렇게 백업된 데이터를 언두 로그라고 합니다.

 

언두 로그는 크게 두 가지 용도로 사용되는데, 첫 번재 용도는 트랜잭션 롤백 대비용으로 두 번째 용도는 트랜잭션 격리 수준을 유지하면서 높은 동시성을 제공하는 목적으로 사용됩니다.

 

트랜잭션이 롤백되면 트랜잭션 도중 변경된 데이터를 언두 로그에 백업해둔 이전 버전의 데이터를 이용해 복구합니다.(트랜잭션 보장)

 

특정 트랜잭션에서 데이터를 변경하는 도중에 다른 트랜잭션에서 데이터를 조회하면 트랜잭션 격리 수준에 맞게 바로 변경된 데이터를 반환하거나 언두 로그에 백업해둔 데이터를 읽어서 반환합니다.(격리 수준 보장)

 

체인지 버퍼

RDMS에서 레코드가 INSERT, UPDATE 될 때는 데이터 파일을 변경하는 작업뿐 아니라 해당 테이블에 포함된 인덱스를 업데이트하는 작업도 필요합니다. 인덱스를 업데이틑 하는 작업은 랜덤하게 디스크를 읽는 작업이 필요하므로 테이블에 인덱스가 많다면 이 작업은 상당히 많은 자원을 소모하게 됩니다. InnoDB는 변경해야 할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하지만 그렇지 않고 디스크로부터 읽어와서 업데이트해야 한다면 즉시 반영하지 않고 임시 공간에 두고 사용자에게 결과를 반환하는 형태로 성능을 향상시키게 되는데 이를 체인지 버퍼라고 합니다.

 

사용자에게 결과를 전달하기 전에 반드시 중복 여부를 체크해야하는 유니크 인덱스는 체인지 버퍼를 사용할 수 없습니다.

체인지 버퍼에 임시로 저장된 인덱스 레코드 조각은 이후 백그라운드 스레드에 의해 병합되는데, 이 스레드를 체인지 버퍼 머지 스레드라고 합니다.

 

리두 로그 및 로그 버퍼

리두 로그는 트랜잭션 4가지 요소인 ACID 중에서 D(Durable)에 해당하는 영속성과 가장 밀접하게 연관되어 있습니다.

하드웨어나 소프트웨어 등 여러 가지 문제점으로 인해 MySQL 서버가 비정상 적으로 종료됐을 때 데이터 파일에 기록되지 못한 데이터를 잃지 않게 해주는 안전장치 입니다.

 

MySQL 서버를 포함한 대부분 데이터베이스 서버는 데이터 변경 내용을 로그에 먼저 기록하고 비정상적으로 서버가 종료되었을 때 리두 로그의 내용을 이용해 데이터 파일을 다시 서버가 종료되기 직전의 상태로 복구합니다.

 

MySQL 서버가 비정상 종료되는 경우 InnoDB 스토리지 엔진의 데이터 파일은 두 가지 종류의 일관되지 않은 데이터를 가질 수 있습니다.

  1. 커밋됐지만 데이터 파일에 기록되지 않은 데이터
  2. 롤백됐지만 데이터 파일에 이미 기록된 데이터

1번의 경우 리두 로그에 저장된 데이터를 데이터 파일에 다시 복사하기만 하면 됩니다.

2번의 경우에는 리두 로그에서 변경이 커밋 되었는지, 롤백이 되었는지, 아니면 트랜잭션 실행 중간 상태였는지 확인을 하고 변경되기 전 데이터를 가진 언두 로그의 내용을 가져와 데이터 파일에 복사하면 됩니다. 

 

어댑티브 해시 인덱스

사용자가 수동으로 생성하는 인덱스가 아니라 InnoDB 스토리지 엔진에서 사용자가 자주 요청하는 데이터에 대해 자동으로 생성하는 인덱스이며, 사용자는 innodb_adaptive_hash_index 시스템 변수를 이용해서 어댑티브 해시 인덱스를 활성화하거나 비활성화할 수 있습니다.

 

InnoDB 스토리지 엔진은 자주 읽히는 데이터 페이지의 키 값을 이용해서 해시 인덱스를 만들고, 필요할 때 마다 어댑티브 해시 인덱스를 검색해서 레코드가 저장된 데이터 페이지를 즉시 찾아갈 수 있습니다. 어댑티브 해시 인덱스는 버퍼 풀에 올려진 데이터 페이지에 대해서만 관리되고, 버퍼 풀에서 해당 데이터 페이지가 없어지면 어댑티브 해시 인덱스에서도 해당 페이지에 대한 정보는 없어지게 됩니다.

728x90