MySQL Cluster도입시의 포인트2

데이터형의 선정

정수형, 부동소수점형, 날짜시각형에 대해서는 큰 문제는 없다.

문자열형에 대해서는 5.0까지는 VARCHAR형이어도 고정형으로 사이즈가 확보되어버리는 문제도 있었다. (예를 들어 VARCHAR(30)인 경우 30문자분)

5.1에서부터는 실제로 사용한 만큼만 확보되기 때문에 메모리 사용효율은 크게 개선되었다.

TEXT형이나 BLOB형은 내부적으로 테이블을 만드는 특징이 있다. 테이블관리를 위해 메모리영역을 상당히 사용하기 때문에 메모리 사용효과를 크게 악화시킨다.

그 때문에 피하는 것이 좋다. 정수/수치형, 날짜/시각형, VARCHAR형의 범위내에서 사용하는 것이 좋지 않나 싶다.

MySQL Cluster도입시의 포인트1

ndb_size.pl를 이용한 메모리 사이즈 견적

실제로 MySQL Cluster환경을 셋업할 때에는 메모리사이즈를 어느정도하면 좋을까하는 의문이 반드시 생기게 될 것이다.

메모리는 고가이므로 디스크처럼 충분한 여유를 가지고 미리 준비해 둘 수도 없다.

메모리사이즈 견적에는 테이블수, 인덱스수, 컬럼의 데이터형, 레코드수를 기준으로 산출하게 된다.

계산식도 있기때문에 수작업으로 산출하는 것도 가능하지만 복잡하므로 매우 피곤할 것이다.

이를 위해 MySQL Cluster에서는 사이즈 견적 툴로서 ndb_size.pl이라는 Perl스크립트를 제공하고 있다.

이것을 사용하면 간단히 사이즈를 견적내는 것이 가능하다.

ndb_size.pl 의 실행에는 DBI와 HTML::Template모듈이 필요하다.

또, MySQL인스톨 디렉토리밑/share/mysql/ndb_size.tmpl이라는 파일을 현재 디렉토리에 복사해둘 필요가 있다.

ndb_size.pl은 다음과 같이 실행한다.

ndb_size.pl의 실행

shell>perl ndb_size.pl db_name hostname username password > file_name.html

ndb_size.pl에서는 MySQL 서버에 접속해서 지정된 데이터베이스안의 테이블과 레코드수를 보고 NDB 스토리지 엔진으로 이행했을 때 필요한 메모리 사이즈를 계산해준다.

Data Node(ndbd)가 기동되어 있을 필요는 없다. NDB스토리지엔진으로 만들고 싶은 테이블을 MyISAM등으로 작성해놓고 ndb_size.pl을 실행해서 NDB이행시의 메모리양을 견적내보는 것이 전형적인 방법이다.

예를 들어 다음과 같이 MyISAM 테이블이 있는 상태에서 ndb_size.pl명령을 실행해보자.

ndb_size.pl의 실행예

mysql> create table tbl1(col1 integer primary key, col2 varchar(30) ) engine=myisam;

mysql> insert into tbl1 values(1, 'abc'),(2,'def');

mysql> select * from tbl1;

shell> cp share/mysql/ndb_size.tmpl ./

shell>./bin/ndb_size.pl db1 192.168.0.3:3306 user1 pass1 > size1.html

size1.html이라는 파일이 생성된다.

이것은 테이블 tbl1에 대해서 데이터형과 인덱스(INTEGER형의 primary key와 varchar(30)의 컬럼)을 계산에 넣어서 데이터부분(DataMemory), 인덱스부분(IndexMemory)의 값을 견적해준다.

현재는 레코드 수가 2개밖에 없으므로 Total DataMemory와 Total IndexMemory값은 작게 된다.

중요한 것은 Total DataMemory/Row 하고 IndexMemory/Row이다.

각각 한개의 레코드에 대한 DataMemory양과 IndexMemory양에 해당된다.

실제로 어플리케이션에서 100만레코드를 다룬다고 한다면 이 값을 100만배한 값이 대충 그 DataMemory, IndexMemory가 된다고 생각하면 된다.

물론 테이블수가 여러개 있다면 그것도 고려해야하지만 말이다.

한가지 더, 현재 ndb_size.pl에서는 DECIMAL형을 0바이트로 봐버리는 문제가 있으니 주의하길 바란다.

※NDB인덱스에는 2종류가 있다.

NDB인덱스에는 해쉬인덱스와 T-Tree인덱스(Ordered Index) 2종류가 있다.

전자는 키워드 검색에 사용되는 것으로 primary key제약과 unique key제약을 정의할 때 자동적으로 작성된다.

후자는 범위 검색 에 사용되는 것으로 primary key제약, unique key제약, 보통 인덱스를 정의할 때 자동적으로 작성된다.

다시말해 primary key제약과 unique key제약을 정의하면 해쉬 인덱스와 T-Tree인덱스 양쪽이 정의되게 된다.

T-Tree인덱스를 작성하지 않고 해쉬인덱스만을 정의하는 것은 가능한데 다음과 같이 USING HASH 문을 사용한다.

해쉬 인덱스만을 정의

mysql> CREATE TABLE tbl1(col1 INTEGER PRIMARY KEY USING HASH(col1) ENGINE=NDBCLUSTER;

해쉬인덱스와 T-Tree인데스는 구문만이 아니라 메모리 사용방법도 틀리다.

해쉬 인덱스는 IndexMemory에 들어가지만 T-Tree인덱스는 DataMemory에 들어간다.

T-Tree인덱스1개에 대해서 1레코드당 10바이트 정도이다.

해쉬인덱스는 인덱스1개에 대해서 25바이트정도 이다.

ndb_size.pl에서는 인덱스 차이를 자동적으로 고려해서 견적을 내준다.

덧붙여서, unique key제약등으로 해쉬 인덱스를 추가하는 경우는 1개의 해쉬 인덱스가 1개의 테이블에 대응하기때문에 생각외의 메모리를 사용하게 됨으로 주의가 필요하다.

MySQL Cluster - SQL문의 실행

db1이라는 데이터베이스를 준비해서 그곳에 테이블을 작성하는 조작을 해보자.

우선 SQL Node의 어딘가에서 데이터베이스 작성을 수행한다.

5.0까지는 작성한 데이터베이스 정보가 다른 SQL Node에 전달되지 않기 때문에 모든 SQL Node에서 각각 CREATE DATABASE명령어를 실행할 필요가 있었다.

5.1부터는 다른 SQL Node가 기동되어 있으면 그 SQL Node에서 데이터베이스가 자동적으로 작성되기 때문에 수고를 덜 수 있게 되었다.

데이터베이스 db1의 작성

mysql>CREATE DATABAE db1;

mysql>USE db1;

다음으로 어딘가 한 군데의 SQL Node에서 테이블을 작성한다. 다른 SQL Node에는 자동적으로 그 메세지가 전달되어 테이블이 만들어진다. 이것은 5.1이후 버전만이 아니라 5.0이전에서도 같다.

테이블의 작성

mysql> CREATE TABLE tbl1(col1 INT PRIMARY KEY, col2 VARCHAR(10)) ENGINE=NDBCLUSTER;

테이블을 작성했으면 그 다음은 보통 SELECT/INSERT/UPDATE/DELETE문등을 실행한다.

실행결과는 다른 SQL Node에서도 곧바로 볼 수 있다.

이것은 어느 SQL Node도 Data Node에 접근함으로 레코드를 조작/취득하고 있고 Data Node는 동기 replication에 의해서 언제나 일관된 값을 되돌려주는 것이 보증되어있기 때문이다.

예를 들어 , Node id=4의 SQL Node에서 다음과 같이 INSERT문을 실행한다.

레코드의 삽입

mysql> INSERT INTO tbl1 values(100, 'abc');

tbl1의 내용을 Node id=5의 SQL Node에서 보면 커밋후의 값이 보인다.

tbl1 내용을 확인

mysql> SELECT * FROM tbl1;

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

| col1 | col2 |

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

|100 | abc |

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

일부 클러스터형 RDBMS에서는 어느 노드에서의 커밋 결과가 다른 노드에는 곧바로 반영되지 않는 문제가 있지만 MySQL Cluster에서는 이런 문제는 발생하지 않는다.

MySQL Cluster 노드 기동/정지

Management Node, Data Node, SQL Node의 각 노드의 기동과 정지 방법에 대해서 알아보자.

Management Node의 기동

MySQL 인스톨디렉토리/bin의 아래 (mysqld, mysqld_safe등과 같은 디렉토리)에 ndb_mgmd라고 불리우는 프로그램이 있다.

이것이 Management Node 실체로 이것을 실행하면 Management Node를 기동할 수 있다.

인수 -f로 설정파일 config.ini를 지정할 수 있다.

Management Node의 기동

shell> ndb_mgmd -f /path/to/config.ini

Management Node로의 접속은 bin아래에 있는 ndb_mgm이라는 프로그램을 이용한다.

Management Node하고 같은 호스트에서 인수 없이 ndb_mgm명령어를 실행하면 Management Node에 접속가능하다.

여기에서 일련의 관리조작을 수행하는 것이 가능하다.

Management Node로의 접속

shell> ndb_mgm

SHOW 명령어를 실행하면 설정한 노드로의 접속 상황을 확인할 수 있다.

SHOW명령어에 의한 접속상황을 확인

ndb_mgm>SHOW

Connected to Management Server at: localhost:1186

Cluster Configuration

------------------------

[ndbd(NDB)] 2 node(s)

id=2 .....

id는 config.ini에서 설정한 Id의 값이 된다.

Data Node의 기동

Data Node의 기동의 흐름은 다음과 같다.

①Management Node에 접속해 자신의 Data Node의설정정보를 취득한다.

②읽어들인 설정정보를 기초로 Data Node를 기동한다.

따라서 Data Node기동시에는 Management Node를 특정할 수 있는 정보(호스트명, 포트번호)를 지정한다.

Data Node의 기동

shell>ndbd --ndb-connectstring="192.168.0.1" --initial <--처음 기동할 때

shell>ndbd --ndb-connectstring="192.168.0.1"

--ndb-connectstring에서는 Management Node의 호스트명, 포트 번호를 지정한다.

Management Node의 포트 번호의 디폴트값은 1186으로 config.ini에 명시적으로 설정하지 않은 경우에는 디폴트값이 쓰여지기 때문에 여기에서 지정할 필요는 없다.

또 처음 기동할 때에는 --initial을 지정한다. 그 다음의 기동시에는 --initial을 지정하지 않고 기동한다.

Data Node는 테이블 데이터라든지 REDO로그 등의 기동/복구에 필요한 데이터를 정기적으로 디스크에 써낸다.

--initial을 지정하면 이것들의 데이터 파일을 재 작성한 다음에 기동할 때 수정한다.

그렇기 때문에 어플리케이션 가동후에 정상운용으로 정지나 기동을 하는 경우에는 --initial을 지정해서는 안된다.

초기 상태에서는 기동후 조금 시간이 걸린다. 지금 어느 단계에 있는지에 대해서 알아보고 싶으면 ndb_mgm 콘솔에서 노드 ID STATUS라는 명령어를 사용하면 된다.

노드 ID STATUS명령어로 상태확인

ndb_mgm> 3 STATUS

Node 3: starting (Phase 4) (Version 5.1.14)

starting은 현재 기동중이라는 것을 나타낸다. 또 Management Node의 ndb_1_cluster.log라는 파일에는 기동상태의 변화가 상세하게 기술되어 있다.

마지막으로 기동이 완료된 시점에서 ndb_mgm콘솔에 Node 2: Started (version 5.1.14)등의 메세지가 자동적으로 출력된다.

또 SHOW명령어를 실행했을 때에 [ndbd(NDB)] 엔트리의 출력이 다음과 같이 되어있으면 기동이 완료되었다는 것을 의미한다.

SHOW명령어의 실행

ndb_mgm> SHOW

Connected to Mangement Server at: localhost:1186

Cluster Configuration

-------------------------------------------

[ndbd(NDB)] 2 node(s)

id=2 @192.168.0.2 (Version: 5.1.14, Nodegroup: 0, Master)

id=3 @192.168.0.3 (Version: 5.1.14, Nodegroup: 0)

SQL Node의 기동

SQL Node는 mysqld에 해당하는 것으로 통상의 흐름처럼 my.cnf의 설정항목을 기술하고 mysqld_safe를 이용해서 mysqld프로세스를 기동한다.

다만 my.cnf에는 MySQL Cluster특유의 설정파라미터가 있어 다음과 같이 추가할 필요가 있다.

[mysqld]에 다음의 엔트리를 추가

ndbcluster

ndb-connectstring=

ndbcluster에 의해서 MySQL Cluster를 사용하는 것을 선언하고 ndb-connectstring에 의해서 Management Node에 접속하기 위한 정보를 지정한다.

config.ini에서 사전에 할당해놓은 SQL Node의 번호가 적당하게 할당된다.

ndb_mgm콘솔에서 [mysqld(API)] 엔트리 출력이 바뀐 것을 확인할 수 있다.

SHOW 명령어로 확인

ndb_mgm> SHOW

Connected to Mangement Server at: localhost:1186

Cluster Configuration

-------------------------------------------

[ndbd(NDB)] 2 node(s)

id=2 @192.168.0.2 (Version: 5.1.14, Nodegroup: 0, Master)

id=3 @192.168.0.3 (Version: 5.1.14, Nodegroup: 0)

[ndb_mgmd(NDB)] 1 node(s)

id=1 @192.168.0.1 (Version: 5.1.14)

[mysqld(API)] 4 node(s)

id=4 @192.168.0.4 (Version: 5.1.14)

id=5 (not connected, accepting connect from any host)

남은 SQL Node를 기동하면 SHOW명령어 실행결과로 id=5부분이 id=4하고 같게 된다.

노드의 정지

노드 전체를 정지시킬려면 ndb_mgm콘솔에서 다음과 같이 SHUTDOWN명령을 실행한다.

Node의 정지

ndb_mgm> SHUTDOWN

이것에 의해서 Management Node하고 Data Node가 정지한다. SQL Node는 기동된 상태이지만 Data Node가 멈춰있기 때문에 NDB스토리지엔진을 작성하는지는 못한다.

Data Node를 개별로 정지하는 것은 ndb_mgm콘솔에서 다음처럼 실행한다.

Data Node의 정지

ndb_mgm> node_id STOP

node_id에는 Data Node 노드 번호를 지정한다. 이번 예의 경우에 nodeid=2로 기동했으므로 2 STOP이라고 실행하게 되면 Data Node를 정지시킬 수 있다.

MySQL Cluster의 환경구축 2

○MySQL Cluster용 설정파일 config.ini의 작성

MySQL Cluster에서는 설정파일 my.cnf이외에 MySQL Cluster용의 설정파일을 별도 작성할 필요가 있다.

설정파일의 기술 예는 다음과 같다. Management Node, Data Node, SQL/API Node 전 노드의 설정을 한다.

>MySQL Cluster설정 파일 config.ini

[NDBD DEFAULT]

NoOfReplicas=2

[NDB_MGMD]

HostName=192.168.0.1

[NDBD]

Id=2

HostName=192.168.0.2

[NDBD]

Id=3

HostName=192.168.0.3

[MYSQLD]

Id=4

[MySQLD]

Id=5

Management Node의 설정항목은 [NDB_MGMD], Data Node의 설정항목은 [NDBD], SQL Node의 설정항목은 [MYSQLD]에 기술한다.

Data Node나 SQL Node는 거의 예외없이 2대이상 셋업하기 때문에 설정항목에 따라서 중복하는 부분도 나오게 된다.

그런 항목은 [NDBD DEFAULT]처럼 [노드타입 DEFAULT]라는 엔트리를 준비하고 그곳에 기술하는 것으로

해당하는 모든 노드의 설정항목이 맞추어지게 된다.

MaxNoOfReplicas에서는 replication수를 나타내고 1~4범위에서 설정가능하다.

NoOfReplicas가 1이면 replication은 수행되지 않게 된다.

2이면 2대, 3이면 3대의 Data Node로 동일한 레코드가 복제된다.

갯수가 많을 수록 가용성은 높아지지만 replication 오버헤드는 증가한다.

2또는 3으로 설정하는 것이 일반적이다.

NoOfReplicas의 값은 어느 Data Node에서도 같은 설정을 필요로 하기 때문에 [NDBB DEFAULT]란에 기술하고 있다.

이 란에 기술하는 것으로 각 [NDBD]엔트리에 기술하지 않아도 디폴트값으로 반영된다.

Data Node의 파라미터 종류는 이외에도 많이 있다.

데이터 영역의 메모리크기를 결정하는 DataMemory, 인덱스의 메모리크기를 결정하는 IndexMemory, REDO로그 파일의 크기를 결정하는 MaxNoOfFragmentLogFiles등 다방면에 걸쳐져 있다.

설정파일 config.ini는 Management Node의 기동시에 읽어들일 필요가 있다.

이렇게 함으로 Management Node는 전부 몇개의 노드가 있는지등의 정보를 파악할 수 있게 된다.

파일명은 뭐든지 괜찮지만 config.ini라는 이름이 관례적으로 쓰인다.

my.cnf에 따른 mysqld의 파라미터 지정은 별도 설정할 필요가 있다.

my.cnf에서는 MySQL특유의 파라미터로서 다음의 2개가 있어 이것들을 지정할 필요가 있다.

>MySQL Cluster특유 파라미터

ndbcluster

ndb_connectstring="Management Node의 호스트명과 포트 번호"

MySQL Cluster의 환경구축

MySQL Cluster의 특징에 대해서 개념 레벨정도 이해한 수준에서 다음은 실제로 MySQL Cluster환경을 셋업해보자.

○서버의 구성 결정

여기에서는 Management Node 1대, SQL Node 2대, Data Node 2대 구성을 해보는 걸로 하자.

실제로 어플리케이션은 노드에 걸리는 부하와 성능을 감안해서 SQL Node의 수를 Data Node 수배정보(Data Node수가 2대이면 4~8대정도)로 하는 것이 일반적이라고 한다.

이것은 어디까지나 대충짐작의 이야기 임으로 실제로 대수를 결정할 때에는 사전에 벤치마킹을 해보는 것이 좋을 것이다.

또 Data Node는 체크포인트에 의한 디스크 저장이 있음으로 디스크 저장성능이 나쁜 RAID5는 피하는 게 좋을 듯 싶다.

RAID1이던지 RAID1+0가 무난하다.

○MySQL Cluster 인스톨

MySQL 다운로드 사이트에서 MySQL본체의 소스코드, 또는 max edition 바이너리를 다운로드 한다.

max edition 바이너리의 경우 인스톨 방법은 standard edition하고 다르지 않기 때문에 생략한다.

소스코드의 경우는 configure옵션에 --with-ndbcluster를 추가지정하는 것으로 MySQL Cluster가 설치된다.

디폴트 설정만으로는 설치되지 않으므로 조심해야한다.

MySQL Cluster 라이센스를 구입한 경우에는 전용사이트에서 안정버전을 다운 받을 수 있다.

인스톨이 끝나면 bin디렉토리 밑(소스코드에서 컴파일 한 경우에는 디폴트로 libexec밑)에

Management Node용 프로그램인 ndb_mgmd, Data Node용 프로그램인 ndbd, NDB API탑재 MySQL 본체 프로세스인 mysqld을 확인할 수 있을 것이다.

MySQL Cluster의 특징 7

◆Data Node의 fail over의 구조를 스스로 가지고 있다.

Data Node는 가동감시를 위해 서로 heart beat를 송수신한다.

어느 한 부분의 Data Node가 다운된 경우에는 다른 Data Node가 그것을 검지해 fail over를 수행한다.

이 때문에 Data Node에 heart beat등의 클러스터링 소프트웨어를 넣어 가동감시, fail over처리를 수행할 필요성이 반드시 있는 것은 아니다.

SQL Node에는 이 fail over 구조는 없다.

MySQL Cluster 말고도 MySQL의 고가용성을 위한 구성으로서 mysqld가 가동되는 서버에 클러스터링 소프트웨어를 넣어서 fail over처리를 구성하던지 mysqld의 앞단의 load balancer를 두고 배분하는( mysqld장해시에는 load balancer기능에의해 배분대상에서 제외시킴)것이 일반적이다.

MySQL Cluster의 특징 6

◆shared nothing형

일반적인 클러스터 구성으로서 복수의 노드가 한개의 디스크를 공유하는 공유디스크형(shared everying) 과 각 노드가 각각 각자의 디스크에 저장, 서로 공유하지 않는 비공유디스크형(shared nothing)이 있다.

MySQL Cluster는 후자를 채용하고 동기 replication에 의한 가용성을 높이고 있다.

shared everyting형은 노드의 추가가 용이한 반면, 고가의 공유 디스크가 필요하거나 Lock경합에 따른 성능저하가 우려되는 등의 과제가 있다.

한편 shared nothing형인 MySQL Cluster의 장점, 단점은 shared everything형의 정반대라고 말할 수 있다.

다만, Data Node 추가에는 시스템 전체의 정지와 노드 재구축이 필요로 하는 한다는 과제가 있다.

그 때문에 관리해야만 하는 데이터양이 급격히 증가하거나 하는 경우, 그것을 전부 NDB스토리지엔진에서 관리하는 것은 문제가 있다.

MySQL은 InnoDB와 MyISAM등 그 이외의 스토리지엔진도 선택가능하고 이것을 병용하는 것도 가능함으로 오래된 데이터를 별도의 스토리지 엔진에 이행해서 NDB스토리지 엔진에서 사용하는 레코드를 일정 이하로 유지하는 운용방침도 검토하면 좋을 것이다.

이러한 유연한 대처가 가능한 것도 MySQL의 매력중에 하나라고 말할 수 있다.

MySQL Cluster의 특징 5

◆복수의 replication단위

replication수(NoOfReplicas)가 1~4라는 것은 Data Node의 수는 4대가 최대라고 생각하는 사람도

있겠지만 그건 아니다. replication을 상호 수행하는 Data Node의 구성은 복수구성 가능하다.

이 1개의 구성을 노드그룹이라고 부른다. MySQL Cluster에서는 이 노드 그룹을 복수 구성하는 것이

가능하다. 각각의 노드 그룹의 각 Data Node는 상호 replication이 이루어진다.

가용성이라는 관점에서는 노드 그룹내의 어딘가 1개의 Data Node가 생존해 있으면 서비스 정지까지는 다다르지 않는다.

한편 노드그룹내의 전 Data Node가 정지한 경우에는 서비스는 정지하게 된다.

replication수, 노드 그룹수, Data Node 수 사이에는 다음과 같은 관계가 있다.

• Data Node수 = replication수 X 노드 그룹수

머신 대수가 정해져 있는 경우, replication수를 늘려서 가용성을 추구하던지 노드 그룹수를 늘릴 까 SQL Node를 잘 이용해서 성능을 추구할까 하는 제어를 하는 것도 가능하다.

그치만 어플리케이션 가동후에 Data Node의 수를 변경하는 것에는 매우 귀찮은 작업이 필요하기 때문에

미리 견적을 내두는 것이 필요하다.

MySQL Cluster의 특징 4

◆동기 replication

한개의 레코드를 한개의 Data Node로만 관리하면 그 Data Node가 다운했을 경우에 레코드에

접근할 수 없게 되기 때문에 가용성 향상이 되지 않는다.

그 때문에 MySQL Cluster에서는 한개의 레코드를 여러개의 Data Node에서 관리한다.

각 레코드당 레코드를 주관리하는 Primary Replica가 되는 Data Node가 존재하지만

replication이 되는 Secondary Replica가되는 Data Node가 존재하게 된다.

이런 구조는 동기 replication에 의해서 실현되고 있다.

각 레코드는 한개의 Primary Replica 노드하고 0개 이상의 Secondary Replica 노드에

동기 replication되는 것이 된다.

replication수는 MySQL Cluster의 설정 파라미터 NoOfReplicas로 1~4의 범위로 설정가능하다.

1이면 Secondary Replica가 존재하지 않기 때문에 replication도 작동하지 않고 가용성 향상도

되지 않는다. 4로 설정했을 경우에는 4대의 Data Node로 replication되기 때문에 가장 가용성이

높게 되지만 반대로 replication의 오버헤드가 커지게 되어 성능은 떨어지게 된다.

그 밸런스를 잘 맞추어서 2또는 3으로 하는 것이 일반적이다. 2로 하는 케이스가 많지만

한개의 노드가 여하의 이유(계획정지 또는 긴급정지)에 의해 다운된 경우에도 reaplication에 의한

여유를 유지하고자 하는 경우에는 3을 지정한다.

MySQL Cluster의 특징 3

◆테이블 데이터를 분산배치

MySQL Cluster에서는 복수의 데이터 노드를 기동한다. 이 때 NDB스토리지 엔진의 테이블 데이터는 각 Data Node에 분산배치된다.

MySQL Cluster에서는 Primary Replica라고 불리우는 개념이 있다.

이것은 레코드 단위로 그것을 주관리하는 Data Node가 한개할당된다라는 것이다.

행1은 Node1, 행3은 Node2처럼 된다. 실제로 할당알고리즘으로써 기본적으로 hash partitioning라는 알로리즘이 사용된다.

이것은 주키 값에 대해서 md5 hash을 수행하여 그 결과에 따라 주관리하는 Data Node를 결정하는 것이다.

이에 따라서 한개의 테이블에 대한 처리가 한개의 Data Node에 집중하지 않기 때문에 리소스를 효율있게 이용가능하다.

full table scan등도 각 노드가 각각 담당가능하기 때문에 특히 레코드 수가 많은 경우에는 한개의 노드에 전부 맡기는 것보다

빨라질 가능성이 높아진다.

MySQL Cluster의 특징 2

◆레코드 데이터와 인덱스를 메모리 상에서 관리

NDB 스토리지 엔진의 행 데이터는 , 데이터 영역, 인덱스 영역을 포함해서 전부 메모리상에서 관리된다.

그 때문에 데이터 액세스는 매우 빠르다.

무엇보다도 메모리는 디스크에 비교해 꽤 비싸기 때문에 수백기가급의 대량 데이터를

다룰 필요가 있다면 MySQL Cluster로 전부 관리하는 것은 현실적이지 않을 수 있다.

다만, MySQL에서는 테이블단위로 스토리지 엔진을 선택가능하기 때문에 고속화가

필요한 테이블은 NDB로 하고 그 이외에는 InnoDB이나 MyISAM으로 하는 구성도 가능하다.

또 5.1에서부터는 테이블데이터(인덱스영역은 빼고)를 디스크상에서 관리할까 메모리상에서

관리할까 하는 선택이 가능하게 된다.

데이터양이 많은 시스템이라서 MySQL Cluster를 사용할 수 없는 것은 아니다.

◆트랜잭션에 대응

InnoDB와 마찬가지로 트랜잭션의 커밋, 롤백이 가능하다.

다만, 분리 레벨은 Read Committed만이 지원된다.

읽고 있는 중에는 Lock을 걸지 않는 것도 InnoDB하고 같다.

◆체크포인트와 그룹 커밋에 따른 영속화

메모리상에서 관리한다라고 하면 머신을 멈추면 모든 데이터가 날라가버린다고 생각할 지도 모른다.

그러나 MySQL Cluster(Data Node)에서는 정기적으로 체크포인트처리가 수행되어

메모리상에 있는 데이터가 디스크에 저장된다. 정상정지나 이상정지등의 이유로 Data Node가

멈추어 재기동이 필요하게 된 경우에는 디스크로부터 테이블 데이터를 읽어들여 메모리에서

전개하게 된다. 그 때문에 Data Node의 프로세스를 멈추어도 테이블 데이터를 잃어버릴 염려는 없다.

이 처럼 Data Node의 모든 메모리데이터를 디스크에 쓰는 처리를 Local Checkpoint라고 부르고 있다.

Local Checkpoint는 기본적으로 수분 간격으로 수행되어진다. (TimeBetweenLocalCheckpoint라는 파라미터로 제어 가능하다. )

그렇지만 이 외에도 트랜잭션의 커밋결과를 디스크에 저장하는 처리도 이루어진다.

이 처리는 Global Checkpoint라고 불리운다.

그러나 InnoDB하고 달리, 커밋 동시에 저장은 하지 않고 일정시간(TimeBetweenGlobalCheckpoint에서 지정한 밀리세컨드)간격으로 그때까지의 커밋정보가

같이 디스크에 쓰여지게 되어있다.

이것은 성능을 높이기 위한 조치이다.

커밋시 동시 저장의 목적은 정전등의 노드 장해가 발생하더라도 직전 커밋정보까지 복원가능케 하는 것이 지만

MySQL Cluster에서는 같은 데이터를 여러개의 노드가 가지고 있기 때문에 1개의 노드에 장해가

발생하더라도 시스템정지으로 되지는 않는다. 그 때문에 엄밀한 커밋시 동시 저장을 하지 않아도

문제는 없다라는 것이다. SQL문등 어플리케이션레벨에서의 튜닝이 필요한 환경에서는 REDO로그 파일에 동기 저장이 bottle neck이 되는 경우가 많지만

MySQL Cluster에서는 그런 걱정이 없다. 이것도 성능 향상에 큰 공헌을 하고 있다.

MySQL Cluster의 특징

MySQL Cluster는 다음과 같은 특징을 가지고 있다.

• 레코드 데이터와 인덱스를 메모리 상에서 관리
• 트랜잭션대응
• 체크포인트와 그룹커밋에 따른 영속화
• 테이블데이터를 분산배치
• 동기 replication
• 복수의 replication 단위
• shared nothing형
• Data Node의 fail over 구조를 스스로 갖고 있다.

cluster구성 특유의 기능도 있지만 레코드데이터와 인덱스를 메모리 상에서 관리한다는 매우 큰

특징도 지니고 있다.

MySQL 개요2

◆Data Node(ndbd)

Data Node는 MySQL Cluster의 중핵에 해당되는 것으로 테이블 데이터의 분산관리, 동기 replication, 분산 트랜잭션 제어, failover/recovery등을 담당한다. 

실제로는 ndbd라는 프로세스가 처리를 수행한다. 

다른 말로 말하면 Data Node를 기동하기(MySQL Cluster를 이용하기)위해서는 ndbd프로세스를 

새롭게 기동할 필요가 있다는 말이다. 

◆SQL Node(mysqld) 

SQL Node는 Data Node에 대해서 테이블 데이터의 취득, 트랜잭션제어등을 지시하기 위한 노드이다. 

MySQL Cluster에서는 NDB API 라는 인터페이스가 있어서 SQL Node에서 NDB API를 이용해서

Data Node에 접근함으로써 테이블데이터 취득, 트랜잭션 제어등을 수행할 수 있다. 

mysqld는 이 NDB API를 호출하는 코드를 가지고 있어 (sql/ha_ndbcluster.cc), mysqld에서부터 이용자가 NDB스토리지엔진에 접근했을 경우에는 

mysqld가 내부적으로 NDB API경유로 Data Node에 접근하고 결과를 되돌리는 처리를 수행하고 있다. 

이때문에  기본적으로 NDB API를 이용자가 의식할 필요는 없다. 

NDB API를  이용한 프로그램을 스스로가 작성해서 직접 Data Node에 접근하는 것도 가능하다.

이 경우에는 mysqld를 필요로 하지 않는다. 

NDB API는 C++로 만들어져 있기 때문에 C++의 지식이 있으면 그다지 곤란없이 프로그램을 작성할 수 있다. 

◆Management Node(ndb_mgmd)

Management Node는 Data Node와 SQL Node관리를 수행하기 위한 노드이다. 

MySQL Cluster에서는 각 노드에  특별한 노드 번호를 할당해서 식별하고 있다. 

또 Data Node에는 특유의 설정파라미터가 다수 있다.  이것의 정보는 Management Node가 일괄 관리한다. 

Data Node와 SQL Node는 기동시에 우선 Management Node에 접속해서 자기 자신의 설정정보를 얻거나  노드 번호에 

관한 정보(예를 들면 노드 번호3은 SQL Node인가 Data Node인가 Management Node인가하는 정보)를 취득하거나 한다. 

MySQL Cluster가 기동한 뒤에는 큰 부하가 되는 처리는 Management Server에 할당되지 않기때문에  장비의 스펙으로서  고성능의 것이 요구되어지지 않는다. 

 

MySQL Cluster개요

MySQL Cluster에 따라서 성능및 가용성을 향상가능하다.  특히 성능의 향상은 극적이 부분이 있어 초간 10만건을 넘는 검색/갱신을 처리했던 사례도 있다.

여기에서는 이 MySQL Cluster의 개요와 이용방법에 대해서 기초적인 부분을 해설해 본다.

MySQL Cluster 를 구성하는 프로세스

MyISAM과 InnoDB등 보통 스토리지엔진만을 사용하는 경우, 데이터베이스 서버 구성으로서는 MySQL본체 프로세스(mysqld) 한개만 쓰이는 것이 기본형이 된다. 

이 응용으로써 replication에 따른 마스터의 mysqld에 대해서 복수의 슬레이브 mysqld를 구성하는 것도 가능하지만 어쨌든 MySQL의 본체 프로세스 mysqld를 1개, 또는 복수 사용하는 구성이 된다. 

한편 MySQL Cluster의 경우 조금 복잡한 구성이 된다.  

다음의 3종류의 노드로부터 구성되고 이 노드를 전부 준비해 둘 필요가 있다. 

• Data Node(ndbd)
• SQL Node(mysqld)
• Management Node(ndb_mgmd)