25.2.1 NDB Cluster Core Concepts

25.2.1 NDB Cluster 핵심 개념

NDBCLUSTER (또는 NDB라고도 함)는 고가용성과 데이터 지속성 기능을 제공하는 인메모리 스토리지 엔진입니다.

NDBCLUSTER 스토리지 엔진은 여러 가지 장애 조치 및 부하 분산 옵션과 함께 구성될 수 있지만, 스토리지 엔진을 클러스터 레벨에서부터 살펴보는 것이 가장 이해하기 쉽습니다. NDB Cluster의 NDB 스토리지 엔진은 클러스터 자체 내의 다른 데이터에만 의존하는 완전한 데이터 집합을 포함합니다.

NDB Cluster의 “Cluster” 부분은 MySQL 서버와는 독립적으로 구성됩니다. NDB Cluster에서 클러스터의 각 부분은 노드로 간주됩니다.

참고

많은 문맥에서 “node”라는 용어는 컴퓨터를 가리키는 데 사용되지만, NDB Cluster를 논의할 때는 프로세스를 의미합니다. 하나의 컴퓨터에서 여러 개의 노드를 실행하는 것이 가능하며, 하나 이상의 클러스터 노드가 실행되는 컴퓨터를 클러스터 호스트라고 부릅니다.

클러스터 노드에는 세 가지 유형이 있으며, 최소 NDB Cluster 구성에서는 이 세 가지 유형 각각에 대해 최소 하나씩, 즉 최소 세 개의 노드가 존재합니다:

• Management node: 이 유형의 노드는 NDB Cluster 내의 다른 노드를 관리하는 역할을 하며, 구성 데이터를 제공하고, 노드를 시작 및 중지하며, 백업을 실행하는 등의 기능을 수행합니다. 이 노드 유형은 다른 노드의 구성을 관리하므로, 다른 어떤 노드보다 먼저 시작해야 합니다. management node는 ndb_mgmd 명령으로 시작합니다.

• Data node: 이 유형의 노드는 클러스터 데이터를 저장합니다. data node의 수는 프래그먼트 복제본 수에 프래그먼트 수를 곱한 값과 같습니다(자세한 내용은 Section 25.2.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions”를 참조하십시오). 예를 들어, 두 개의 프래그먼트 복제본이 있고 각 복제본에 두 개의 프래그먼트가 있는 경우, 네 개의 data node가 필요합니다. 하나의 프래그먼트 복제본만으로도 데이터 저장은 가능하지만 중복성은 제공하지 않습니다. 따라서 중복성과 그에 따른 고가용성을 제공하기 위해서는 두 개(또는 그 이상)의 프래그먼트 복제본을 사용하는 것이 권장됩니다. data node는 ndbd 명령(자세한 내용은 Section 25.5.1, “ndbd — The NDB Cluster Data Node Daemon” 참조) 또는 ndbmtd 명령(자세한 내용은 Section 25.5.3, “ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)” 참조)으로 시작합니다.

NDB Cluster 테이블은 일반적으로 디스크가 아니라 완전히 메모리에 저장됩니다(이 때문에 NDB Cluster를 인메모리 데이터베이스라고 부릅니다). 그러나 일부 NDB Cluster 데이터는 디스크에 저장될 수 있습니다. 자세한 내용은 Section 25.6.11, “NDB Cluster Disk Data Tables”를 참조하십시오.

• SQL node: 이 노드는 클러스터 데이터에 접근하는 노드입니다. NDB Cluster의 경우 SQL node는 NDBCLUSTER 스토리지 엔진을 사용하는 기존 MySQL 서버입니다. SQL node는 --ndbcluster 및 --ndb-connectstring 옵션(이 챕터의 다른 곳에서 설명됨), 그리고 필요에 따라 추가적인 MySQL 서버 옵션과 함께 mysqld 프로세스로 시작됩니다.

SQL node는 실제로는 API 노드의 특수한 유형일 뿐이며, API 노드는 NDB Cluster 데이터에 접근하는 어떠한 애플리케이션이라도 가리킵니다. API 노드의 또 다른 예로는 클러스터 백업을 복원하는 데 사용되는 ndb_restore 유틸리티가 있습니다. 이러한 애플리케이션은 NDB API를 사용하여 작성할 수 있습니다. NDB API에 대한 기본 정보는 Getting Started with the NDB API를 참조하십시오.

주의

운영 환경에서 세 개의 노드만 사용하는 구성을 사용할 수 있을 것이라고 기대하는 것은 비현실적입니다. 이러한 구성은 어떠한 중복성도 제공하지 않으며, NDB Cluster의 고가용성 기능을 활용하려면 여러 개의 data node와 SQL node를 사용해야 합니다. 여러 개의 management node를 사용하는 것도 강력히 권장됩니다.

NDB Cluster에서 노드, 노드 그룹, 프래그먼트 복제본, 파티션 간의 관계에 대한 간단한 소개는 Section 25.2.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions”를 참조하십시오.

클러스터의 구성은 클러스터 내 각 개별 노드를 구성하고 노드 간의 개별 통신 연결을 설정하는 작업을 포함합니다. NDB Cluster는 현재, data node가 프로세서 성능, 메모리 공간, 대역폭 측면에서 동질적이라는 가정을 바탕으로 설계되어 있습니다. 또한 단일 구성 포인트를 제공하기 위해, 클러스터 전체에 대한 모든 구성 데이터는 하나의 구성 파일에 위치합니다.

management server는 클러스터 구성 파일과 클러스터 로그를 관리합니다. 클러스터 내 각 노드는 management server로부터 구성 데이터를 가져오며, 이를 위해 management server가 어디에 있는지 알 수 있는 방법이 필요합니다. data node에서 중요한 이벤트가 발생하면, 해당 노드는 이러한 이벤트에 대한 정보를 management server로 전송하고, management server는 해당 정보를 클러스터 로그에 기록합니다.

또한, 임의의 수의 클러스터 클라이언트 프로세스나 애플리케이션이 존재할 수 있습니다. 여기에는 표준 MySQL 클라이언트, NDB 전용 API 프로그램, management 클라이언트가 포함됩니다. 이들에 대해서는 다음 몇 개의 단락에서 설명합니다.

Standard MySQL clients.

NDB Cluster는 PHP, Perl, C, C++, Java, Python 등으로 작성된 기존 MySQL 애플리케이션과 함께 사용할 수 있습니다. 이러한 클라이언트 애플리케이션은 독립형 MySQL 서버와 상호 작용할 때와 거의 동일한 방식으로, SQL 문을 전송하고 그에 대한 응답을 NDB Cluster SQL node로 동작하는 MySQL 서버로부터 수신합니다.

NDB Cluster를 데이터 소스로 사용하는 MySQL 클라이언트는 여러 MySQL 서버에 연결할 수 있는 기능을 활용하도록 수정하여 부하 분산과 장애 조치를 구현할 수 있습니다. 예를 들어, Connector/J 5.0.6 이상을 사용하는 Java 클라이언트는 jdbc:mysql:loadbalance:// URL(Connector/J 5.1.7에서 개선됨)을 사용하여 부하 분산을 투명하게 달성할 수 있습니다. NDB Cluster와 함께 Connector/J를 사용하는 방법에 대한 자세한 내용은 Using Connector/J with NDB Cluster를 참조하십시오.

NDB client programs.

클라이언트 프로그램은 클러스터에 연결된 MySQL Server를 우회하고, NDB API라는 하이 레벨 C++ API를 사용하여 NDBCLUSTER 스토리지 엔진으로부터 직접 NDB Cluster 데이터에 접근하도록 작성될 수 있습니다. 이러한 애플리케이션은 데이터에 대한 SQL 인터페이스가 필요하지 않은 특수한 목적에 유용할 수 있습니다. 자세한 내용은 The NDB API를 참조하십시오.

NDB 전용 Java 애플리케이션도 NDB Cluster Connector for Java를 사용하여 NDB Cluster용으로 작성할 수 있습니다. 이 NDB Cluster Connector에는 ClusterJ가 포함되며, 이는 Hibernate 및 JPA와 같은 객체 관계 매핑 영속성 프레임워크와 유사한 하이 레벨 데이터베이스 API로, NDBCLUSTER에 직접 연결하므로 MySQL Server에 대한 접근이 필요 없습니다. 자세한 내용은 Java and NDB Cluster 및 The ClusterJ API and Data Object Model을 참조하십시오.

Management clients.

이들 클라이언트는 management server에 연결하여 노드를 정상적으로 시작 및 중지하고, 메시지 추적을 시작 및 중지하며(디버그 버전에서만), 노드 버전 및 상태를 표시하고, 백업을 시작 및 중지하는 등의 명령을 제공합니다. 이러한 유형의 프로그램 예로는 NDB Cluster와 함께 제공되는 ndb_mgm management 클라이언트가 있습니다(자세한 내용은 Section 25.5.5, “ndb_mgm — The NDB Cluster Management Client” 참조). 이러한 애플리케이션은 MGM API라는 C 언어 API를 사용하여 하나 이상의 NDB Cluster management server와 직접 통신하도록 작성할 수 있습니다. 자세한 내용은 The MGM API를 참조하십시오.

Oracle은 또한 고급 명령줄 인터페이스를 제공하여 다수의 노드를 가진 NDB Cluster 재시작과 같은 많은 복잡한 NDB Cluster 관리 작업을 단순화하는 MySQL Cluster Manager도 제공합니다. MySQL Cluster Manager 클라이언트는 또한 대부분의 노드 구성 파라미터 값과 NDB Cluster와 관련된 mysqld 서버 옵션 및 변수를 조회하고 설정하는 명령도 지원합니다. 자세한 내용은 MySQL Cluster Manager 9.5.0 User Manual을 참조하십시오.

Event logs.

NDB Cluster는 이벤트를 카테고리(시작, 종료, 오류, 체크포인트 등), 우선순위, 심각도 별로 로그합니다. 보고 가능한 모든 이벤트의 전체 목록은 Section 25.6.3, “Event Reports Generated in NDB Cluster”에서 찾을 수 있습니다. Event log에는 다음에 나열된 두 가지 유형이 있습니다:

• Cluster log: 클러스터 전체에 대해 원하는 보고 가능한 모든 이벤트의 기록을 유지합니다.

• Node log: 각 개별 노드마다 유지되는 별도의 로그입니다.

참고

일반적인 상황에서는 클러스터 로그만 유지하고 검토하면 충분합니다. 노드 로그는 애플리케이션 개발 및 디버깅 목적에 대해서만 확인하면 됩니다.

Checkpoint.

일반적으로 데이터가 디스크에 저장되면 체크포인트에 도달했다고 말합니다. NDB Cluster에 좀 더 구체적으로 말하면, 체크포인트는 커밋된 모든 트랜잭션이 디스크에 저장된 시점을 의미합니다. NDB 스토리지 엔진과 관련하여, 클러스터 데이터에 대한 일관된 뷰가 유지되도록 함께 동작하는 두 가지 유형의 체크포인트가 있습니다. 이들은 다음 목록과 같습니다:

• Local Checkpoint (LCP): 단일 노드에 특화된 체크포인트입니다. 그러나 LCP는 클러스터 내 모든 노드에 대해 대체로 동시에 발생합니다. LCP는 보통 몇 분마다 발생하며, 정확한 간격은 노드가 저장하는 데이터의 양, 클러스터 활동 수준 및 기타 요인에 따라 달라집니다.

NDB 9.5는 partial LCP를 지원하며, 이는 일부 조건에서 성능을 크게 향상시킬 수 있습니다. partial LCP를 활성화하고 사용되는 스토리지 양을 제어하는 구성 파라미터에 대한 설명은 EnablePartialLcp 및 RecoveryWork을 참조하십시오.

• Global Checkpoint (GCP): GCP는 모든 노드에 대한 트랜잭션이 동기화되고 리두 로그가 디스크에 플러시될 때마다 수초마다 발생합니다.

local checkpoint 및 global checkpoint에 의해 생성되는 파일과 디렉터리에 대한 자세한 내용은 NDB Cluster Data Node File System Directory를 참조하십시오.

Transporter.

우리는 data node 간에 사용되는 데이터 전송 메커니즘을 transporter라고 부릅니다. MySQL NDB Cluster 9.5는 다음에 나열된 세 가지 transporter를 지원합니다:

• TCP/IP over Ethernet. 자세한 내용은 Section 25.4.3.10, “NDB Cluster TCP/IP Connections”를 참조하십시오.

• Direct TCP/IP. machine-to-machine connection을 사용합니다. 자세한 내용은 Section 25.4.3.11, “NDB Cluster TCP/IP Connections Using Direct Connections”를 참조하십시오.

이 transporter는 이전 항목에서 언급한 것과 동일한 TCP/IP 프로토콜을 사용하지만, 하드웨어를 다르게 설정해야 하며 구성 방법도 다릅니다. 이러한 이유로, NDB Cluster에 대해 별도의 전송 메커니즘으로 간주됩니다.

• Shared memory (SHM). 자세한 내용은 Section 25.4.3.12, “NDB Cluster Shared-Memory Connections”를 참조하십시오.

이식성이 뛰어나기 때문에, 대부분의 사용자는 NDB Cluster에서 TCP/IP over Ethernet을 사용합니다.

사용되는 transporter 유형과 관계없이, NDB는 data node 프로세스 간의 통신이 가능한 한 큰 크기의 청크를 사용하여 수행되도록 보장하려고 합니다. 이것은 모든 유형의 데이터 전송에 이점을 제공합니다.