■ 버퍼 풀 플러싱 구성 InnoDB는 버퍼 풀에서 더티 페이지 플러시를 포함하여 백그라운드에서 특정 작업을 수행합니다. 더티 페이지란 버퍼풀의 페이지가 수정되었지만 아직 디스크의 데이터 파일에 기록되지 않은 페이지입니다. MySQL 5.7에서는 버퍼 풀 플러싱이 페이지 클리너 스레드에 의해 수행됩니다. 페이지 클리너 스레드 수는 기본값이 4인 innodb_page_cleaners 변수에 의해 제어됩니다. 그러나 페이지 클리너 스레드 수가 버퍼 풀 인스턴스 수를 초과하면 innodb_page_cleaners는 자동으로 innodb_buffer_pool_instances와 동일한 값으로 설정됩니다. 더티 페이지의 백분율이 innodb_max_dirty_pages_pct_lwm 변수에 의해 정의 된 낮은 워..
■ Innodb Buffer Pool 크기 설정 서버가 실행되는 동안 InnoDB 버퍼 풀 크기를 오프라인(시작시) 또는 온라인으로 구성 할 수 있습니다. 이 곳에 설명 된 동작은 두 방법 모두에 적용됩니다. innodb_buffer_pool_size를 늘리거나 줄이면 작업이 청크로 수행됩니다. 청크 크기는 innodb_buffer_pool_chunk_size 구성 옵션에 의해 정의되며 기본값은 128M입니다. 버퍼 풀 크기는 항상 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances의 배수와 같아야합니다. innodb_buffer_pool_size를 innodb_buffer_pool_chunk_size * innodb_buffer_pool_inst..
■ Doublewrite Buffer 이중 쓰기 버퍼는 InnoDB 데이터 파일의 적절한 위치에 페이지를 쓰기 전에 InnoDB가 버퍼 풀에서 플러시 된 페이지를 쓰는 저장 영역입니다. 페이지 쓰기 도중에 운영 체제, 스토리지 서브 시스템 또는 mysqld 프로세스 충돌이있는 경우 InnoDB는 응급 복구 중에 이중 쓰기 버퍼에서 올바른 페이지 사본을 찾을 수 있습니다. 데이터가 두 번 기록되지만 이중 쓰기 버퍼에는 두배의 I/O 오버 헤드 또는 두배의 I/O 작업이 필요하지 않습니다. 운영 체제에 대한 단일 fsync() 호출로 innodb_flush_method가 O_DIRECT_NO_FSYNC로 설정된 경우를 제외하고는 큰 순차 청크로 이중 쓰기 버퍼에 데이터가 기록됩니다. 이중 쓰기 버퍼는 대부분..
■ 시스템 테이블 스페이스 시스템 테이블 스페이스는 InnoDB 데이터 딕셔너리, 이중 쓰기 버퍼, 변경 버퍼 및 실행 취소 로그의 저장 영역입니다. 테이블이 파일당 또는 일반 테이블 스페이스가 아닌 시스템 테이블 스페이스에서 테이블을 작성하는 경우 테이블 및 인덱스 데이터도 포함 할 수 있습니다. 시스템 테이블 스페이스에는 하나 이상의 데이터 파일이 있을 수 있습니다. 기본적으로 ibdata1이라는 단일 시스템 테이블 스페이스 데이터 파일이 데이터 디렉토리에 작성됩니다. 시스템 테이블 스페이스 데이터 파일의 크기와 수는 innodb_data_file_path 시작 옵션으로 정의됩니다. 시스템 테이블 스페이스에 대한 추가 정보는 섹션의 다음 주제에서 제공됩니다. - 시스템 테이블 스페이스 크기 조정 - ..
■ Bufferpool 버퍼 풀은 InnoDB가 액세스 할 때 테이블 및 인덱스 데이터를 캐시하는 메인 메모리의 영역입니다. 버퍼 풀은 자주 사용하는 데이터를 메모리에서 직접 처리 할 수있게하여 처리 속도를 높입니다. 전용 서버에서 실제 메모리의 최대 80%정도가 버퍼 풀에 할당됩니다. 대량 읽기 조작의 효율성을 위해 버퍼 풀은 여러 행을 보유 할 수있는 페이지로 분할됩니다. 캐시 관리 효율성을 위해 버퍼 풀은 링크 된 페이지 목록으로 구현됩니다. 거의 사용되지 않는 데이터는 다양한 LRU 알고리즘을 사용하여 캐시에서 종료(혹은 만료:aged out)됩니다. 버퍼 풀을 활용하여 자주 액세스하는 데이터를 메모리에 유지하는 노하우(기술)는 MySQL 튜닝의 중요한 측면입니다. ▶ Buffer Pool LRU..
■ Shared and Exclusive Locks InnoDB는 공유 (S) 잠금과 배타적 (X) 잠금의 두 가지 유형의 잠금이있는 표준 행 수준 잠금을 구현합니다. + 공유 (S) 잠금은 잠금을 보유한 트랜잭션이 행을 읽을 수 있도록합니다. + 독점 (X) 잠금은 잠금을 보유한 트랜잭션이 행을 업데이트하거나 삭제할 수 있도록 합니다. 트랜잭션 T1이 행 r에 공유 (S) 잠금을 보유하는 경우, 행 r에 대한 잠금에 대한 일부 고유 트랜잭션 T2의 요청은 다음과 같이 처리됩니다. + T2가 S 잠금 요청을 즉시 승인 할 수 있습니다. 결과적으로 T1과 T2는 모두 r에 S 잠금을 유지합니다. + T2에서 X 잠금 요청을 즉시 승인 할 수 없습니다. 트랜잭션 T1이 행 r에서 배타적 (X) 잠금을 보유하..
MySQL은 스토리지 엔진이라 불리는 플러그인 방식으로 데이터베이스를 관리합니다. 이 스토리지 엔진은 MyISAM, Memory, Aria등 여러가지가 있는데 각 스토리지 엔진 특성에 따라 관리하는 방법이 틀립니다. 그중에서도 가장 많이 쓰이는게 InnoDB라는 스토리지 엔진인데 굉장히 많은 기능들을 지원하고 있습니다. 이 InnoDB 스토리지 엔진에 대해서 알아보겠습니다. ■ InnoDB Storage Engine 소개 - DML 작업은 ACID 모델을 따르며 커밋, 롤백 및 응급 복구 기능을 갖춘 트랜잭션으로 사용자 데이터를 보호합니다. - Row-level 잠금 및 Oracle 스타일의 일관된 읽기는 다중 접속 및 사용자에게 동시성 및 성능을 향상시킵니다. - InnoDB 테이블은 기본 키를 기반으..
https://lalitvc.wordpress.com/2016/11/03/mysql-architecture-and-components/ 이 블로그 게시물은 새로운 MySQL 5.7 물리적, 논리적 아키텍처 및 구성 요소에 대한 것입니다.이 블로그 게시물에서는 다이어그램을 사용하여 MySQL의 데이터 처리 및 SQL 실행을 포함한 흐름에 대해 설명하려고합니다. 다른 데이터베이스와 달리 MySQL은 매우 유연하며 다양한 종류의 스토리지 엔진을 다양한 종류의 요구에 대한 플러그인으로 제공합니다. 이 때문에 스토리지 엔진의 사용에 따라 MySQL 아키텍처 및 동작도 변경됩니다 (예 : 트랜잭션 [InnoDB] 및 비 트랜잭션 [MyISAM] 엔진) 데이터 스토리지 및 SQL 실행 방법이 다르며 서버 내에서 엔진..
1. 문제점 Centos 7 + apache 2.4.x + php 7.x + mysql 5.7.x 설치 도중 mysql 설치과정에서 아래와 같은 에러메시지를 발견하였습니다. -- Running cmake version 2.8.11 -- Could NOT find Git (missing: GIT_EXECUTABLE) -- Configuring with MAX_INDEXES = 64U -- SIZEOF_VOIDP 8 -- MySQL 5.7.11 -- Packaging as: mysql-5.7.11-Linux-x86_64 -- Looked for boost/version.hpp in and -- BOOST_INCLUDE_DIR BOOST_INCLUDE_DIR-NOTFOUND -- LOCAL_BOOST_DIR ..
특정 시점 복구는 특정 시점 이후의 데이터 변경 사항까지 적용한 복구를 의미합니다. 일반적으로 이 유형의 복구는 전체 백업을 복원 한 후 백업 시점의 서버 상태로 복원 한 후에 수행됩니다. (7.2 절.“데이터베이스 백업 방법”에 나열된 것과 같은 여러 가지 방법으로 전체 백업을 수행 할 수 있습니다.) 특정 시점 복구는 전체 풀 백업 시간에서 가능한 한 최신 시점까지 시간을 적용하여 최근의 데이터베이스와 비슷하게 만드는 것입니다. 또는 특정 용도에 따라 원하는 시간까지만 복구할 수도 있습니다. 예를 들어 풀백업 이후 몇월 몇일 몇시까지의 특정 데이터베이스가 필요한경우 이 방법을 이용해서 특정 시간으로 복구를 할 수 있습니다. ■ 사전 지식사항 여기에있는 몇몇 예제는 mysqlbinlog에 의해 생성 된..