MySQL

책너두 6기 18일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.185 ~ p.194 내용정리 06 데이터 압축 디스크에 저장된 데이터 파일의 크기는 쿼리의 처리 성능, 백업 및 복구 시간과도 연결된다. 시간과 비용을 절약하기 위해 데이터 압축 기능이 있다. 6.1 페이지 압축 “Transparent Page Compression"이라고도 불린다. 서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장 서버가 디스크에서 데이터 페이지를 잃어올 때 압축이 해제 페이지 압축 작동 방식 16KB 페이지를 압축(압축 결과를 7KB로 가정) MySQL 서버는 디스크에 압축된 결과 7KB를 기록(이때 MySQL 서버는 압축 데이터 7KB에 9KB의 빈 데이터를 기록) 디스크에 데이터를 기록한 후, 7KB 이후의 공간 9KB에 대해 펀치 홀(Punch-hole)을 생성 파일 시스템은 7KB만 남기고 나머지 디스크의 9KB 공간은 다시 운영체제로 반납 여러 이유로 페이지 압축은 거의 사용되지 않는다. ...

책너두 6기 17일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.176 ~ p.184 내용정리 05 트랜잭션과 잠금 5.4 MySQL의 격리 수준 격리 수준(isolation level)이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다. 5.4.1 READ UNCOMMITTED 각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관없이 다른 트랜잭션에서 보인다. 이를 더티 리드(Dirty read)라 한다. 5.4.2 READ COMMITTED 오라클 DBMS에서 기본으로 사용되는 격리 수준. 가장 흔하게 사용된다. ...

책너두 6기 16일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.170 ~ p.175 내용정리 05 트랜잭션과 잠금 5.3.2 인덱스와 잠금 InnoDB의 잠금은 레코드를 잠그는 것이 아니라 인덱스를 잠그는 방식으로 처리한다. 즉, 변경해야 할 레코드를 찾기 위해 검색한 인덱스의 레코드를 모두 락을 걸어야 한다. 5.3.3 레코드 수준의 잠금 확인 및 해제 테이블 잠금에서는 문제의 원인이 쉽게 발견되고 해결된다. 하지만 레코드 수준의 잠금은 테이블의 레코드 각각에 잠금이 걸리므로 자주 사용되지 않는다면 오랜 시간동안 잠겨진 상태로 남아 있어도 잘 발견하지 않는다. 읽고 나서 슬슬 어렵다. ...

책너두 6기 15일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.160 ~ p.169 내용정리 05 트랜잭션과 잠금 5.2 MySQL 엔진의 잠금 MySQL에서 사용되는 잠금은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다. MySQL 엔진은 서버에서 스토리지 엔진을 제외한 나머지 부분으로 이라 볼 수 있다. 5.2.1 글로벌 락 글로벌 락(GLOBAL LOCK)은 가장 범위가 크다. 한 세션엣 획득하면 다른 세션에서 SELECT를 제외한 대부분의 문장이 대기 상태로 남는다. MySQL 서버 전체에 영향을 미치며 테이블이나 데이터베이스가 달라도 미친다. Xtrabackup이나 Enterprise Backup 과 같은 백업 락: 조금 더 가벼운 글로벌 락. 일반적인 테이블의 데이터 변경은 허용된다. 5.2.2 테이블 락 테이블 락(Table Lock)은 ㄱ별적인 테이블 단위로 설정되는 잠금. 명시적 또는 묵시적으로 획득할 수 있다. 5.2.3 네임드 락 네임드 락(Named Lock)은 GET_LOCK()함수를 이용해 임의의 문자열에 대해 잠금을 설정할 수 있다. 단순히 사용자가 지정한 문자열(String)에 대해 획득하고 반납(해제)하는 잠금이다. 5.2.4 메타데이터 락 메타데이터 락(Metadata Lock)은 데이터베이스 객체(테이블이나 뷰 등)의 이름이나 구조를 변경하는 경우에 획득하는 잠금이다. 명시적으로 획득하거나 해제하지 않는다. 테이블의 이름을 변경하는 경우 자동으로 획득하는 잠금 5.3 InnoDB 스토리지 엔진 잠금 5.3.1 InnoDB 스토리지 엔진의 잠금 잠금 정보가 상당히 작은 공간으로 관리되기 때문에 레코드락 -> 페이지락 or 테이블락 으로 레벨업 되는 경우(락 에스컬레이션)는 없다. 5.3.1.1 레코드 락 레코드 자체만을 잠그는 것(Reocord lock, Record only lock)이라고 한다. 다른 상용 DBMS의 레코드 락과 동일한 역할을 한다. 5.3.1.2 갭 락 갭 락(Gap lcok)은 레코드 자체가 아니라 레코드와의 바로 인접한 레코드 사이의 간격만을 잠그는 것을 의미한다. 레코드와 레코드 사이의 간격에 새로운 레코드가 생성(Insert)되는 것을 의미한다. 5.3.1.3 넥스트 키 락 레코드락과 갭 락을 합쳐 놓은 형태가 넥스트 키 락(Next key lock)이라고 한다. 5.3.1.4 자동 증가 락 읽고 나서 다양한 Lock의 종류가 있다. 알아는 두자 ...

책너두 6기 14일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.150 ~ p.159 내용정리 04 아키텍처 4.4.3 슬로우 쿼리 로그 MySQL 서버의 쿼리 튜닝은 서비스가 적용되기 전 튜닝과 운영 중 전체적인 성능 검사나 정기 점검 튜닝으로 나눌 수 있다. 슬로우 쿼리 로그 파일에는 설정한 시간 이상의 시간이 소요된 쿼리가 모두 기록된다. 실행 완료 후 기록으로 판단하기 때문에 실행이 정상적으로 완료되야만 기록될 수 있다. Time : 쿼리가 종료된 시점 User@Host : 쿼리를 실행한 사용자의 계정 ...

책너두 6기 13일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.142 ~ p.149 내용정리 04 아키텍처 4.2.13 InnoDB와 MyISAM, MEMORY 스토리지 엔진 비교 예전에는 MyISAM 스토리지 엔진을 많이 썼지만 이제는 도태되고 있고, 이후 버전에서는 사라질 전망이다. 4.3 MyISAM 스토리지 엔진 아키텍처 4.3.1 키캐시 InnoDB의 버퍼 풀과 비슷한 역할을 한다. 인덱스 만을 대상으로 작동한다. 4.3.2 운영체제의 캐시 및 버퍼 MyISAM 테이블의 데이터 읽기나 쓰기 작업은 운영체제의 디스크 읽기 또는 쓰기 작업으로 요청된다. 4.3.3 데이터 파일과 프라이머리 키(인덱스) 구조 프라이머리 키에 의한 클러스터링 없이 데이터 파일이 힙(Heap) 공간 처럼 활용된다. 키값과 무관하게 Insert 되는 순서대로 저장된다. ...

책너두 6기 12일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.130 ~ p.141 내용정리 04 아키텍처 4.2.11 리두 로그 및 로그 버퍼 리두 로그(Redo Log)는 트랜잭션의 4가지 요소인 ACID 중에서 D(Durable)에 해당하는 영속성과 가장 밀접하게 연관돼 있다. 리두 로그는 서버가 비정상적으로 종료됐을 때 데이터 파일에 기록되지 못한 데이터를 잃지 안헥 해주는 안전장치다. 대부분 데이터베이스 서버는 데이터 변경 내용을 로그로 먼저 기록한다. 데이터베이스 서버에서 리두 로그는 트랜잭션이 커밋되면 즉시 디스크로 기록되도록 시스테 변수를 설정하는 것을 권장한다. innodb_flush_log_at_trx_commit 시스템 변수이다. ACID는 데이터베이스에서 트랜잭션의 무결성을 보장하기 위해 꼭 필요한 4가지 요소(기능)을 의미한다. ...

책너두 6기 11일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.120 ~ p.129 내용정리 04 아키텍처 4.2.8 Double Write Buffer InnoDB 스토리지 엔진의 리두 로그는 리두 로그 공간의 낭비를 막기 위해 페이지의 변경된 내용만 기록한다. 이로 인해 스토리지 엔진에서 더티 페이지를 디스크 파일로 플러시할 때 일부만 기록되는 문제가 발생하면 그 페이지의 내용은 복구할 수 없을 수도 있다. 이렇게 페이지가 일부만 기록되는 현상을 파셜 페이지(Partial-page) 또는 톤 페이지(Torn-page)라고 한다. 데이터의 무결성이 매우 중요한 서비스에서는 고려할만하다. ...

책너두 6기 10일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.108 ~ p.119 내용정리 04 아키텍처 4.2.7 InnoDB 버퍼 풀 InnoDB 스토리지 엔진에서 가장 핵심적인 부분 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할 4.2.7.1 버퍼 풀의 크기 설정 운영체제와 각 클라이언트 스레드가 사용할 메모리도 충분히 고려해서 설정 시스템 변수 innodb_buffer_pool_size로 동적 설정 가능 운영체제의 전체 메모리 공간이 8GB 미만이라면 50% 정도만 InnoDB 버퍼 풀로 설정 나머지 메모리 공간은 MySQL 서버와 운영체제, 그리고 다른 프로그램을 위한 공간으로 설정 권장 전체 메모리가 그 이상이면 버퍼 풀의 크기를 점차 증가시키며 최적점을 찾을 것 4.2.7.2 버퍼 풀의 구조 버퍼 풀이라는 거대한 메모리 공간을 페이지 크기(innodb_page_size시스템 변수로 설정)의 조각으로 쪼갠다 InnoDB 스토리지 엔진이 데이터를 필요로 할 때 해당 페이지를 읽어 각 조각에 저장한다 페이지 크기 조각 관리를 위한 LRU 리스트, 플러시 리스트, 프리 리스트라는 3개 자료구조를 관리한다. LRU(Least Recently Used) : 디스크로부터 한 번 읽어온 페이지를 최대한 오랫동안 메모리에 유지해서 읽기를 최소화 플러시(Flush) : 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지(더티 페이지)의 목록 관리 프리(Free) : InnoDB 버퍼 풀에서 실제 사용자 데이터로 채워지지 않은 비어 있는 페이지들의 목록 4.2.7.3 버퍼 풀과 리두 로그 InnoDB의 버퍼 풀은 디스크에서 읽은 상태로 전혀 변경되지 않은 클린 페이지(Clean Page)와 함께 insert,update,delete 명령으로 변경된 데이터를 가진 더티 페이지(Dirty Page)도 가지고 있다. 더티 페이지는 언젠가 디스크로 기록되야 하며 버퍼 풀에 무한정 머무를 수 있지 않다. ...

책너두 6기 9일차 백은빈, 이성욱의 Real MySQL8.0 1권 p.98 ~ p.107 내용정리 04 아키텍처 4.2 InnoDB 스토리지 엔진 아키텍처 InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 리코드 기반의 잠금을 제공하며, 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. 4.2.1 프라이머리 키에 의한 클러스터링 InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장된다. 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻이며 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다. ...