MySQL 기동과 정지 1

여러가지 기동방법

MySQL를 기동하는 방법은 여러가지 방법이 준비되어있다.
MySQL5.0부터는 mysqlmanager라는 툴도 추가되었다.

MySQL기동방법

operator ---> mysql.server(init 스크립트) ---> mysqld_safe---> mysqld

operator ---> mysql.server(init 스크립트) ---> mysqlmanager --->(1...N) mysqld

operator --->(1...N)mysql_safe ---> mysqld

operator --->(1...N)mysqld

operator ---> mysqlmanager --->(1...N) mysqld

operator ---> mysqld_multi --->(1...N) mysql_safe --->mysqld

operator ---> mysqld_multi --->(1...N) mysqld

1...N의 의미는 1개이상의 커맨드를 실행가능하다는 것을 의미한다.

예를 들어 mysqlmanager에서 mysqld로의 화살표는 mysqlmanager1개가 mysqld를 1개 이상 기동가능하다는 말이 된다.

이처럼 기동방법은 많지만 결국 어떤식으로 mysqld를 기동시키느냐라는 것만 다르다.

보통 mysqld를 직접 기동시키는 것보다 다른 스크립트나 명령어를 이용해서 mysqld를 기동시키는게 많은 것이다.

mysql.server는 init스크립트이어서 OS기동시에 MySQL를 자동으로 시동시키고 싶은 경우 사용된다.

이때 OS 기동시에 한번 실행되는 것뿐이다. 물론 관리자가 수동으로 실행해도 상관없다.

이 mysql.server스크립트는 mysqld_safe나 mysqlmanager를 기동한후 자신은 종료한다.

mysqld_safe는 mysqld가 죽었을 경우에 자동으로 mysqld를 시동시키는 쉘 스크립트이다.

한번 올라오면 계속 상주한다.

mysqld_multi는 mysqld_safe 또는 여러개의 mysqld를 기동하거나 정지하거나 하는 Perl스크립트이다. 이것은 단순한 명령어로 데몬처럼 상주하지 않는다.

mysqlmanager는 mysqld_multi와 mysql_safe의 장점을 합하고 리모트 머신에서도 서버 기동, 정지 조작가능하도록 개량된 우수한 녀석이다.

오퍼레이터(유저)는 상황이나 용도에 맞게 어떤 방법이라도 MySQL서버를 기동할 수 있게 된다.

Unix계열의 경우 mysqld, mydqld_safe, mysqlmanger, mysql.server, mysqld_multi등 각 프로세스 실행계정은 이것들의 커맨드를 기동한 계정이 되게 된다.

Falcon: 설정파라미터

Falcon에서는  현재 다음과 같은 설정 파라미터가 준비되어있다.  

현재는 매우 적지만 안정판까지 어느정도 늘어날 예정이다. 

Falcon 설정파라미터 

falcon_log_dir    시리얼로그 파일 배치 디렉토리 (현재는 기능하지 않음)   기본값은 데이터디렉토리 하고 같다. 

falcon_page_cache_size 페이지 캐쉬 사이즈  기본값은 4MB

falcon_min_record_memory  레코드 캐쉬 최소 사이즈 기본값은 0

falcon_max_record_memory  레코드 캐쉬 최대 사이즈 기본값은 20MB

falcon_page_size 페이지 사이즈 기본값은 4KB

Falcon: 인덱스

인덱스 구성은 InnoDB와 Falcon에서 크게 차이가 난다.  InnoDB는 클러스터드인덱스(Oracle에서는 색인 구성 테이블에 상당)이 채용되어 있어 프라이머리 키용의 인덱스가 특별 관리되고 있다.

프라이머리키에 따른 인덱스를 프라이머리 인덱스 , 그 외에의 인덱스를 세컨더리 인덱스라 부른다. 

프라이머리 인덱스는  프라이머리 키값을 키로하고 나머지 컬럼값을 취득한다. 

따라서 세컨더리 인덱스를 이용해서  비 인덱스 컬러값을 취득할 때 세컨더리 인덱스를 보고 프라이머리 키 값을 찾은 후 프라이머리 인덱스를 보고 컬럼값을 취득하는 2단계 처리가 수행된다. 

그리고 프라이머리 키 검색은 매우 빠르다. 

Falcon에서는 클러스터드 인덱스를 채용하고 있지않다. 

인덱스는 B-Tree색인을 개량한 것으로 인덱스의 컬러값을 키로하고 내부적으로 관리하고 있는 유니크한 행번호를 취득하는 것으로 되어있다. 

비트맵 검색

기존의 B-Tree인덱스에서는 추출조건을 만족하는 레코드가 여러개 있을 경우 

최초의 레코드를 취득하기 위한 인덱스 트리를 검색

↓

대응하는 데이터 부분을 읽기

↓

다음 레코드를 취득하기 위한 인덱스 트리를 검색

↓

대응하는  데이터 블록을 읽기

↓

...

처럼 인덱스 부분과 데이터 부분을 왔다갔다하게 된다. 

캐쉬에 실을 수 없는 대량 데이터를 다룰 경우 디스크의 랜덤 I/O가 문제가 되는 경우가 많다. 

Falcon에서는 이런 구현을 하지 않는다. 

구체적으로  우선 인덱스트리를 검색해 추출조건을 만족하는 전 레코드의 행번호를 취득한다. 

이 행번호에는 레코드의 물리적인 배치정보가 포함되어 있다.

다음에 물리적으로 배치순을 소트해서 그 순번대로 데이터를 취득하는 것이다. 

이렇게 하므로써 가장 병목현상이 나기 쉬운 디스크의 seek대기 시간이나 회전 대기 시간을 줄이게 된다. 

한개의 테이블에 대해서 프라이머리 키 검색이나 유니크 키 검색으로 레코드를 단 한개를 취득하는 것 같은경우에는 우수하지는 않지만 IN문 이나 OR문등의  복수 레코드 추출에서는 효과가 있다.  같은 이유로  서브 쿼리나  조인에서도 효과를 기대할 수 있다. 

인덱스관리

Falcon에서는 인덱스 값을 갱신하는 처리(INSERT/UPDATE/DELETE)를 실행한 경우에 인덱스 본체에 갑자기 반영을 하는 것이 아니라 본체 인덱스와는 별도로 전용메모리 영역에 써넣는 구성을 하고 있다.  이 전용 메모리 영역은 트랜잭션마다 독립해서 확보된다. 

본체 인덱스로의 반영은 커밋할 때 소트가 끝난 상태에서 수행된다.  이 때문에 대량 데이터를 한개의 트랜잭션에서 다루는 처리나 롤백등의 부하가 매우 적게 된다. 

한편 인덱스를 조사하는 처리는 본체인덱스만 아니라 각 트랜잭션에서 관리하는 메모리 영역도 참조할 필요가 있기 때문에  오버헤드가 다소 커지는 경향이 있다. 

Falcon : 프로세스/스레드, 메모리구성

MySQL에서는 전체가 mysqld라는 한개의 프로세스에서 동작한다.

멀티스레드구성으로 접속당 전용 스레드가 할당되는 것 이외에 백그라운드로 동작하는 유틸리티용 스레드등이 있다.

또, 스토리지 엔진마다 전용 스레드가 존재하는 경우도 있다.

Falcon에서는 접속당 동작하는 스레드와 별도로 Falcon전용 스레드가 존재한다.

구체적으로 시리얼 로그 파일의 내용을 데이터 파일에 비동기로 반영하는 스레드나 메모리영역과 데이터 파일간의 읽기쓰기를 비동기적으로 수행하는 스레드등이 백그라운드에서 동작한다.

InnoDB에서도 비슷하게 백그라운드에서 동작하는 스레드가 존재한다.

Falcon메모리 영역은 로그 캐쉬, 시스템 캐쉬, 페이지 캐쉬, 레코드 캐쉬의 4종류로부터 구성된다.

로그 캐쉬는 REDO정보를 메모리상에 유지하는 영역으로 InnoDB로그 버퍼와 동등하다.

커밋할 때 시리얼 로그 파일에 동기 저장을 한다.

시스템캐쉬는 각종 메타데이터를 저장하는 영역이다.

페이지 캐쉬는 데이터 파일 정보를 캐쉬하는 영역으로 InnoDB buffer pool하고 비슷하다.

InnoDB의 경우는 페이지 사이즈가 16KB로 고정이어서 변경하기위해서는 소스코드를 직접 수정할 필요가 있지만 Falcon에서는 설정파일에서 수정할 수 있도록 되어있다. (현재는 1/2/4/8/16/32KB중에서 선택가능)

페이지 사이즈 변경으로 성능이 크게 변하는 경우는 드물지 않으므로 튜닝의 여지가 넓어졌다고 말할 수 있겠다.

Falcon특유의 메모리 영역이라고 말할 수 있는 것이 레코드 캐쉬이다.

레코드 캐쉬는 어플리케이션에 의해 작성/추출된 레코드 데이터(커밋전의것도 포함)를 캐쉬해두는 영역이다. MVCC의 기반이기도 하고 대부분의 처리는 레코드 캐쉬상에서 수행되게 된다.

레코드 캐쉬의 포인트는 레코드를 관리하는 데 필요한 정보만을 가지고 있기 때문에 InnoDB같은 페이지 내에 레코드를 관리하는 것에 비해 같은 캐쉬 사이즈임에도 보다 많은 레코드를 캐쉬상에서 관리할 수 있다는 장점이 있다.

메모리에 올릴 수 없을 정도의 대량 테이블 데이터를 다루는 경우에 Falcon의 장점이 발휘될 가능성이 높다고 말할 수 있겠다.

또 페이지 경유로 레코드를 (간접적으로 ) 참조하는 것에 비해서 참조 오버헤드도 가볍다라는 점도 놓칠 수 없다.