NDB Operator relies on a custom resource definition (CRD) named
NdbCluster
to obtain the MySQL Cluster
configuration data that it needs to start. Whenever a user
creates, modifies, or deletes a Kubernetes object of type
NdbCluster
, NDB Operator receives a change
event, and updates the NDB Cluster running in Kubernetes Cluster
accordingly. (See Chapter 1, Introduction to NDB Operator, for a
description of this mechanism.)
The NdbCluster
CRD defines a Kubernetes
resource type which can be used to specify the configuration of an
NDB Cluster. See Section 5.1, “NdbCluster Resource”, for more
information.
The docs/examples
directory in the NDB
Operator source tree contains several examples, including
example-ndb.yaml
. This file contains an
NdbCluster
specification having the
characteristics shown here, specified using YAML format:
apiVersion: mysql.oracle.com/v1
kind: NdbCluster
metadata:
name: example-ndb
spec:
redundancyLevel: 2
dataNode:
nodeCount: 2
mysqlNode:
nodeCount: 2
spec.dataNode.nodeCount
sets the number of data
nodes.
spec.redundancyLevel
specifies the number of
replicas as well as the number of management nodes
(ndb_mgmd processes). Since this is greater
than 1, the NDB Cluster is created with two management nodes.
The number of management nodes is not directly configurable; it
is determined solely by the value of
redundancyLevel
.
spec.dataNode.nodeCount
determines the number
of data nodes in the NDB Cluster.
spec.mysqld.nodeCount
determines the number of
MySQL Servers attached to the NDB Cluster as SQL nodes, providing
an SQL front end to the NDB Cluster data nodes.