mysqlmanager 4

mysqlmanager기동

shell$ ./bin/mysql -umycom -p -S /tmp/mysqlmanager.sock

또는

shell$ ./bin/mysql -umycom -p --port=2273

...

mysql>SHOW INSTANCES;

+---------------+----------+-

|instance_name | status |

+---------------+----------+-

|mysqld | online |

+---------------+----------+-

mysqlmanager에 대해서는 mysql명령어로 액세스한다. 그때 /etc/mysqlmanager.passwd에 정의되어있는 사용자명과 패스워드가 필요하다.

따라서 mysql명령어의 인수에는 -u하고 -p옵션이 필수이다.

또 mysqlmanager는 로컬머신에서는 /tmp/mysqlmanager.sock 소켓 파일을, TCP/IP에서는 2273번 포트를 표준으로 사용한다. 따라서 소켓파일명이나 TCP/IP 포트번호를 지정하지않으면 안된다.

종래의 MySQL에서는 mysqld_safe에서나 mysql.server스크립트에서도 로컬머신에서 명령어를 실행하는 방법만 있었지만 mysqlmanager에서는 TCP/IP를 이용해서 리모트 머신에서 mysqld의 기동이나 정지가 된다는 것은 평가해줄 만 하다. 대기업 상용 RDBMS와 같이 조작이 가능하게 되었다는 점이다.

그러나 사용하는 경우는 시큐리티에 신경을 잘 써야한다.

SHOW INSTANCES

여기에서 말하는 "인스턴스"라는 것은 mysqld 데몬(프로세스)를 말한다.

SHOW INSTANCES는 정의되어있는 mysqld와 그 상태를 나타낸다. online은 기동중, offline은 정지중이다.

여러개의 mysqld를 my.cnf내에 정의한 경우에는 다음과 같다.

mysql>SHOW INSTANCES;

+---------------+----------+-

|instance_name | status |

+---------------+----------+-

|mysqld | online |

|mysqld1 | online |

|mysqld2 | offline |

+---------------+----------+-

예에서는 [mysqld]와 [mysqld1]은 기동중, [mysqld2]는 정지중이다.

STOP INSTANCE 이름

해당 mysqld 데몬을 정지시킨다.

START INSTANCE 이름

해당 mysqld 데몬을 기동시킨다.

SHOW INSTANCE STATUS 이름

해당 mysqld 버전을 보여준다.

SHOW 이름 LOG FILES

로그 파일 위치와 사이즈를 보여준다.

mysqld 로그 파일 사이즈보기

mysql> SHOW mysqld LOG FILES;

+---------------+----------+----------+-

|Logfile | Path |File size |

+---------------+----------+----------+-

|GENERAL LOG| ... | ... |

+---------------+----------+----------+-

|SLOW LOG| ... | ... |

+---------------+----------+----------+-

SET 이름.변수명=값

지정된 mysqld 변수(옵션) 값을 설정한다.

mysql> SET mysql1.port=6612;

이 예에서는 mysqld1 포트 번호를 6612로 변경한다.

UNSET 이름.변수명

SET의 반대동작이다.

mysql> SET mysql1.port;

이 예에서는 mysqld1 포트 번호를 표준값으로 되돌린다.

FLASH 이름

SET로 변경된 값을 원래의 상태로 되돌리는 명령어이다.

간단하게 명령어를 설명했으나 앞으로 명령어가 확장될 가능성은 상존한다.

mysqlmanager 3

mysql.server init스크립트 변경

mysql.server init스크립트는 기본적으로 OS 기동시에 mysqld_safe가 기동하는 것으로 되어있다.

이것을 mysqlmanager가 기동하는 것으로 my.cnf를 변경해보자.

my.cnf에 다음처럼 기술한다. (버전 5.0.19이후만 유효하다. 그 미만버전에서는 init 스크립트 편집이 필요하다. )

my.cnf에 추가

[mysql.server]

use-manager

이것으로 mysql.server init스크립트가 mysqlmanager를 기동하고 그리고 mysqlmanager가 mysqld를 기동한다.

이 밖에도 mysql.server init스크립트를 편집하는 방법도 있다. mysql.server init스크립트내의 다음 부분을 찾아서 1을 0으로 바꾸어놓는다.

mysql.server init스크립트

use_mysqld_safe=1

이것으로 use-manager를 지정하는 것과 같은 동작이 된다. 다만, [mysqld]에 nonguarded 옵션이 지정되어있으면 mysqlmanager는 자기가 기동시에 mysqld를 동작시키지않으므로 주의해야한다.

mysqlmanager 2

/etc/my.cnf에 복수의 mysqld를 정의하기

my.cnf에 다음처럼 쓰게 되면 그 그룹이 mysqlmanager에 인식된다.

[mysqldn] (n은 1이상의 정수)

[mysqldn]그룹이 한개도 존재하지 않는다면 mysqlmanager는 [mysqld] 그룹만 관리한다.

[mysqld] 및 [mysqldn]그룹내의 기술방법은 보통 mysqld의 my.cnf의 기술과 다르지 않다.

다만 여기에서 한개 주의가 필요하다.

MySQL 5.0.24/5.1.12-beta에서의 mysqlmanager는 다음 파일들만 읽어들일 수 있다.

다른 명령어처럼 my.cnf를 여러개의 디렉토리로 찾아나서는 짓은 하지 않는다.

• /etc/my.cnf파일 (windows에서는 mysqlmanager.exe가 존재하는 디렉토리에 있는 my.ini파일)
• --defaults-file=옵션에서 지정된 파일

/etc/my.cnf 파일예

[manager]

run-as-service

default-mysqld-path = /usr/local/mysql/bin/mysqld

#한개째 정의

[mysqld]

datadir=/data0

port=3306

socket=/tmp/mysql.sock

log-error

#두개째 정의

[mysqld2]

nonguarded

mysqld-path = /usr/local/mysql-5.0/bin/mysqld

datadir =/data2

port=3307

socket=/tmp/mysql.sock2

log-error=/data2/debian.err

옵션

mysqld를 정의할 때 각 [mysqld]그룹에 대해서 다음과같은 옵션을 사용할 수 있다.

nonguarded : 이 옵션이 지정되면 mysqlmanager기동시에 mysqld가 자동으로 기동되지 않는다.

또 msyqlmanager정지시에는 mysqld는 정지하지 않는다.

이 옵션이 없으면 mysqlamanager기동시에는 mysqld가 자동으로 기동한다.

mysqlmanager가 정지하면 mysqld도 같이 정지된다.

mysqld-path=패스: mysqld의 패스를 지정한다. manager사용하는 mysqld하고 다른 경우 지정

shutdown-delay=초: mysqld가 정지하기까지 기다리는 초수. 표준은 35초

에러 출력위치

mysqlmanager에서 mysqld를 기동하는 경우는 필요에 따라서 각 [mysqld]그룹에 log-error옵션을 지정한다.

이 옵션이 없으면 mysqld의 에러출력은 mysqlmanager의 로그파일이다.

--help를 보면 tar.gz바이너리 표준에서는 /usr/local/mysql/data/mysqlmanager.log에 쓰여진다.

mysqld에 아무것도 옵션이 없는 경우, mysqld는 에러 메세지를 표준에러 출력에 출력한다.

mysqld_safe는 그것을 호스트명.err파일에 써 넣는다. 이것이 전통적인 mysqld와 에러 메세지 기록방법이었다.

mysqlmanager는 mysqld_safe와는 달리 에러메세지를 자기의 로그 파일에 써 내린다.

그런 운용에 문제가 없는 경우는 신경 쓸 필요는 없다.

그러나 각각 mysqld별로 err로그를 작성하고픈 경우는 mysqld에 log-error옵션을 지정하면 된다.

log-error옵션은 표준 에러 출력에 출력하는 것 대신에 mysqld자신이 에러출력을 지정된 파일에 쓰는 옵션이다. 이것으로 각각 mysqld별로 에러파일이 작성된다.

mysqlmanager 1

①/etc/mysqlmanger.passwd파일 생성

mysqlmanager를 동작시키기위해서는 패스워드 파일이 필요하다.

패스워드 작성은 다음과 같다.

사용자와 패스워드 작성

shell$ ./bin/mysqlmanager --passwd

Creating record for new user.

Enter user name: mycom

Enter password: pass

Re-type password: pass

mycom:*568F812313123123131312312312

이처럼 --passwd옵션을 사용하면 사용자명과 패스워드를 물어본다.

사용자명과 패스워드를 입력하면 예 처럼 "mycom:*568F812313123123131312312312"라는 문자열을 볼수 있다.

이것을 패스워드 파일에 추가하면 되는 것이다.

실제로는 다음과 같이 조작하면 필요한 정보가 패스워드 파일에 추가된다.

사용자와 패스워드를 패스워드 파일에 추가

shell$ ./bin/mysqlmanager --passwd >> /etc/mysqlmanager.passwd

Creating record for new user.

Enter user name: mycom

Enter password: pass

Re-type password: pass

mysqlmanager

여기에서는 버전 5.0에서 도입된 mysqlmanager에 대해서 정리해보자.

mysqlmanager는 mysqld_safe처럼 mysqld를 감시해 만약에 mysqld가 정지하면 자동적으로 mysqld를 다시 기동시킨다.

또 mysqld_multi처럼 여러개의 mysqld를 기동, 정지하는 것이 가능하다.

더욱이 mysql명령어를 사용해서 mysqlmanager를 접속하는 것으로 리모트 머신에서 mysqld를 기동, 정지하는 것도 가능하다.

사용방법은 다음과 같다.

①/etc/mysqlmanager.passwd파일을 생성

이것은 mysqlmanager를 실행할 사용자와 그 패스워드를 기록한다.

다시말하면 사용자와 패스워드를 mysqlmanager용으로 새롭게 작성해두지 않으면 안된다는 것이다.

②필요하면 /etc/my.cnf에 [manager]그룹을 써둔다.

③여러개의 mysqld를 관리하고 싶은 경우는 /etc/my.cnf에 [mysql1][mysql2]... [mysqln]그룹을 정의한다. (n은 자연수)

④mysqlmanager --run-as-service로 기동

⑤만약 OS기동시에 mysqlmanager를 mysqld_safe대신에 기동시키고 싶다면 my.cnf의 [mysql.server]에 use-manger옵션을 써넣던지 mysql.server init 스크립트를 편집한다.

mysqld 부팅순서

기동할 때 설정 문제등으로 MySQL이 정지한 경우 문제해결의 힌트가 될지 모르겠다.

mysqld기동후 클라이언트로부터의 접속대기 상태로 되기까지에는 다음의 처리가 순서대로 이루어진다.

1. bin_log스레드 작성
2. ↓
3. 호스트명 해결
4. ↓
5. my.cnf읽어들이기
6. ↓
7. 커맨드라인 옵션을 읽어들인다. my.cnf에서 읽어들인 옵션값을 커맨드라인에서 부여한 값으로 overwrite한다.
8. ↓
9. 각종 변수 초기화
10. ↓
11. 표준 캐릭터셋 설정. 사용가능한 캐릭터셋 리스트를 얻는다. charsets/Index.xml파일을 읽어들인다.
12. ↓
13. 시그널 접수 준비
14. ↓
15. datadir 확인
16. ↓
17. mysqld실행 계정 체크와 세팅
18. ↓
19. Query Cache버퍼준비
20. ↓
21. .err파일 오픈
22. ↓
23. 각종 로그파일(update-log, bin_log등) 오픈
24. ↓
25. InnoDB등 각 스토리지엔진 초기화
26. ↓
27. 네트워크 준비
28. ↓
29. PID파일 작성
30. ↓
31. 권한 테이블 읽어들이기
32. ↓
33. UDF 읽어들이기
34. ↓
35. STATUS초기화
36. ↓
37. slave 서버 준비
38. ↓
39. 만약 --bootstrap옵션이 지정되었다면 표준입력으로부터 SQL문을 읽어들이고 실행하고 종료
40. ↓
41. 만약 --init-file=옵션이 지정되었다면 지정된 파일을 읽어들이고 query를 실행.
42. ↓
43. Shutdown 스레드 생성
44. ↓
45. Maintenance 스레드 생성(mysqladmin커맨드를 위한 스레드)
46. ↓
47. 서버 기동 메세지를 표준에러나 .err파일에 기록. 서버 버전이나 소켓파일이름, 포트 번호등을 출력
48. ↓
49. 클라이언트로의 접속대기. Waiting for connections 메세지 출력

MySQL 기동과 정지 2

Windows에서 mysqld기동과 정지

1.mysqld 기동

Windows환경에서 mysqld를 직접기동하는데에는 다음과 같이 조작한다.

mysqld 직접기동

c:¥mysql¥bin> mysqld-nt --standalone

또는

c:¥mysql¥bin>mysqld-nt

커맨드 프롬프트내에서 mysqld를 --standalone을 붙이지 않고 기동하면 mysqld가 계속 foreground에서 동작한다.

이 때 커맨드 프롬프트를 죽이면 mysqld가 강제적으로 정지되게 되어 버퍼에 남아있던 데이터가 사라지게 되어 파일이 맞지않는 경우가 발생할 가능성이 생긴다.

--standalone을 붙이게 되면 mysqld는 백그라운드에서 동작하게 된다.

또, SCM(Windows Service Control Manager)에 서비스를 등록하고 있는 경우는 SCM을 이용해서 기동한다.

예를 들어 MySQL서비스를 MySQL 이라는 이름으로 등록한 경우에 다음처럼 조작해서 기동한다.

SCM에서 기동

c:¥mysql¥bin> NET START MySQL

SCM에 mysql를 등록

SCM에 데몬을 등록할 때에는 다음과 같이 조작한다.

서비스추가

c:¥mysql¥bin> mysqld-nt --install [서비스명] [mysqld옵션]

[서비스명]을 생략하면 MySQL이라는 이름으로 SCM에 등록된다.

[mysqld옵션]은 한개만 지정가능하다.

대부분의 경우 --defaults-file=이나 --defaults-extra-file=이 지정된다.

MySQL Windows 인스톨러 버전에서 MySQL을 인스톨하게 되면 서비스에는 --defaults-file=옵션이 추가되어 등록되게 된다.

또, 서비스를 삭제할 때에는 다음과 같이 한다.

서비스의 삭제

c:¥mysql¥bin> mysqld-nt --remove [서비스명]

2.mysqld정지

mysqld를 직접기동한 경우는 다음과 같이 조작해서 정지한다.

mysqld정지

c:¥mysql¥bin>mysqladmin -uroot shutdown

또, SCM을 사용해서 서비스를 등록했을 경우는 다음과 같이 정지한다.

SCM을 사용한 경우의 정지

c:¥mysql¥bin>NET STOP MySQL

MySQL 기동과 정지 2

Unix계열에서 mysqld기동과 정지

1. mysqld를 쉘에서 직접기동

mysqld를 쉘에서 직접기동하는 방법은 다음과 같이 조작한다.

일반 계정에서 직접기동

shell$ mysqld &

그렇지만 mysqld는 root계정으로 기동되면 곧바로 종료하게 된다. 이것은 시큐리티 대책이다.

root계정으로 mysqld를 기동하는 경우에는 다음처럼 mysqld를 실행하는 계정을 지정해서 기동한다.

mysqld를 실행하는 계정을 지정한 기동

root@shell# mysqld --user=mysql &

--user옵션은 my.cnf의 [mysqld]그룹에서 기술가능하다.

2. mysqld_safe를 사용해서 기동

mysqld_safe스크립트는 내부에서 mysqld를 기동한다. 따라서 만약 root계정으로 mysqld_safe를 실행하는 경우는 myqld에 --user옵션을 지정하던지 mysqld_safe에 --user옵셥을 지정할 필요가 있다.

좀더 편하게 하려면 my.cnf의 [mysqld]그룹이던지 [mysqld_safe]그룹에 user옵션을 써넣는다.

mysqld_safe스크립트는 기동하면 상주하면서 mysqld프로세스를 감시한다.

무언가의 장해로 mysqld가 정지한 경우 다시 자동으로 mysqld를 기동한다.

mysqld_safe를 기동(root계정 사용시)

root@shell# mysqld_safe --user=mysql &

3. mysql.server를 사용해서 기동

mysql.server 스크립트는 내부에서 mysqld_safe를 기동한다. 다음처럼 조작한다.

mysql.server를 사용해서 기동

shell$ /user/local/mysql/support-files/mysql.server start

4. mysqld의 정지

기동과 마찬가지로 mysqld정지 방법도 몇개가 준비되어있다.

#mysql.server를 사용해서 정지

mysql.server스크립트를 사용해서 정지가능하다.

mysql.server를 사용해서 정지

shell$ /usr/local/mysql/support-files/mysql.server stop

#mysqladmin을 사용해서 정지

mysqladmin을 사용해서 정지하는 경우는 다음과 같이 조작한다.

mysqladmin을 사용해서 정지

shell$ mysqladmin -uroot shutdown

#kill을 사용해서 정지

kill명령어를 사용해서 정지하는 것이 가능하다. SIGTERM 시그널을 사용해서 MySQL은 안전하게 정지한다.

kill명령어를 사용해서 정지

shell$ kill `cat /usr/local/mysql/data/host.pid`

만약, mysql_safe를 이용해서 mysqld를 기동했을 경우에 최초에 mysqld_safe를 kill 명령어로 정지하고 그 다음에 mysqld를 정지한다.

그렇게 하지 않으면 mysqld_safe가 mysqld를 재기동해 버린다.

또 mysqlmanager로 mysqld를 기동했을 경우에 kill 명령어로 mysqld를 직접 정지시키면 mysqld가 재기동한다.

따라서 먼저 mysqldmanager를 정지시킬 필요가 있다.

kill 명령어를 사용하는 경우 kill -9나 kill -KILL은 절대 사용하지 않도록 해야한다.

이 조작으로 정지시키면 버퍼에 남아있던 데이터가 처리되지않은 상태로 mysqld가 정지하는 꼴이 되기 때문이다. 트랜잭션 버퍼나 INSERT DELAYED버퍼등이 영향을 받는다.

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의 장점이 발휘될 가능성이 높다고 말할 수 있겠다.

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