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구성 특유의 기능도 있지만 레코드데이터와 인덱스를 메모리 상에서 관리한다는 매우 큰

특징도 지니고 있다.

InnoDB 특징및 제한

InnoDB제한 및 그 특징은 다음과 같다.

• 테이블의 필드수는 1000개까지
• VARCHAR(), BLOB, TEXT필드를 제외하고 레코드크기의 최대는 1/2페이지사이즈
• 모든 VARCHAR()의 최대 사이즈의 합계는 65535까지
• FULLTEXT인덱스는 아직 지원하지 않음.
• SELECT COUNT(*)은 인덱스를 이용해서 계산
• SHOW TABLE STATUS는 InnoDB에 관해서는 정확한 값을 보여주지 못한다.
• 다음에 할당해야하는 AUTO INCREMENT값은 디스크에 기록되지 않는다. (MyISAM은 디스크에 기록)