<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="mysql-cluster-basics">
      </a>
      25.2.1 NDB Cluster Core Concepts
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045124342032">
  </a>
  <a class="indexterm" name="idm46045124340576">
  </a>
  <a class="indexterm" name="idm46045124339088">
  </a>
  <a class="indexterm" name="idm46045124337600">
  </a>
  <a class="indexterm" name="idm46045124336096">
  </a>
  <a class="indexterm" name="idm46045124334608">
  </a>
  <a class="indexterm" name="idm46045124333120">
  </a>
  <a class="indexterm" name="idm46045124331216">
  </a>
  <a class="indexterm" name="idm46045124329296">
  </a>
  <a class="indexterm" name="idm46045124327376">
  </a>
  <a class="indexterm" name="idm46045124325472">
  </a>
  <a class="indexterm" name="idm46045124323984">
  </a>
  <a class="indexterm" name="idm46045124322496">
  </a>
  <a class="indexterm" name="idm46045124321008">
  </a>
  <a class="indexterm" name="idm46045124319520">
  </a>
  <p>
   <span class="firstterm">
    <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
     <code class="literal">
      NDBCLUSTER
     </code>
    </a>
   </span>
   (also known as
   <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
    <code class="literal">
     NDB
    </code>
   </a>
   ) is an in-memory
      storage engine offering high-availability and data-persistence
      features.
  </p>
  <p>
   The
   <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
    <code class="literal">
     NDBCLUSTER
    </code>
   </a>
   storage engine can be
      configured with a range of failover and load-balancing options,
      but it is easiest to start with the storage engine at the cluster
      level. NDB Cluster's
   <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
    <code class="literal">
     NDB
    </code>
   </a>
   storage
      engine contains a complete set of data, dependent only on other
      data within the cluster itself.
  </p>
  <p>
   The
   <span class="quote">
    “
    <span class="quote">
     Cluster
    </span>
    ”
   </span>
   portion of NDB Cluster is configured
      independently of the MySQL servers. In an NDB Cluster, each part
      of the cluster is considered to be a
   <span class="firstterm">
    node
   </span>
   .
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    In many contexts, the term
    <span class="quote">
     “
     <span class="quote">
      node
     </span>
     ”
    </span>
    is used to
        indicate a computer, but when discussing NDB Cluster it means a
    <span class="emphasis">
     <em>
      process
     </em>
    </span>
    . It is possible to run multiple
        nodes on a single computer; for a computer on which one or more
        cluster nodes are being run we use the term
    <span class="firstterm">
     cluster host
    </span>
    .
   </p>
  </div>
  <p>
   There are three types of cluster nodes, and in a minimal NDB
      Cluster configuration, there are at least three nodes, one of each
      of these types:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <span class="firstterm">
       Management node
      </span>
      : The
          role of this type of node is to manage the other nodes within
          the NDB Cluster, performing such functions as providing
          configuration data, starting and stopping nodes, and running
          backups. Because this node type manages the configuration of
          the other nodes, a node of this type should be started first,
          before any other node. A management node is started with the
          command
      <a class="link" href="mysql-cluster-programs-ndb-mgmd.html" title="25.5.4 ndb_mgmd — The NDB Cluster Management Server Daemon">
       <span class="command">
        <strong>
         ndb_mgmd
        </strong>
       </span>
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="firstterm">
       Data node
      </span>
      : This type of
          node stores cluster data. There are as many data nodes as
          there are fragment replicas, times the number of fragments
          (see
      <a class="xref" href="mysql-cluster-nodes-groups.html" title="25.2.2 NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions">
       Section 25.2.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions”
      </a>
      ). For
          example, with two fragment replicas, each having two
          fragments, you need four data nodes. One fragment replica is
          sufficient for data storage, but provides no redundancy;
          therefore, it is recommended to have two (or more) fragment
          replicas to provide redundancy, and thus high availability. A
          data node is started with the command
      <a class="link" href="mysql-cluster-programs-ndbd.html" title="25.5.1 ndbd — The NDB Cluster Data Node Daemon">
       <span class="command">
        <strong>
         ndbd
        </strong>
       </span>
      </a>
      (see
      <a class="xref" href="mysql-cluster-programs-ndbd.html" title="25.5.1 ndbd — The NDB Cluster Data Node Daemon">
       Section 25.5.1, “ndbd — The NDB Cluster Data Node Daemon”
      </a>
      ) or
      <a class="link" href="mysql-cluster-programs-ndbmtd.html" title="25.5.3 ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)">
       <span class="command">
        <strong>
         ndbmtd
        </strong>
       </span>
      </a>
      (see
      <a class="xref" href="mysql-cluster-programs-ndbmtd.html" title="25.5.3 ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)">
       Section 25.5.3, “ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)”
      </a>
      ).
     </p>
     <p>
      NDB Cluster tables are normally stored completely in memory
          rather than on disk (this is why we refer to NDB Cluster as an
      <span class="firstterm">
       in-memory
      </span>
      database).
          However, some NDB Cluster data can be stored on disk; see
      <a class="xref" href="mysql-cluster-disk-data.html" title="25.6.11 NDB Cluster Disk Data Tables">
       Section 25.6.11, “NDB Cluster Disk Data Tables”
      </a>
      , for more
          information.
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="firstterm">
       SQL node
      </span>
      : This is a node
          that accesses the cluster data. In the case of NDB Cluster, an
          SQL node is a traditional MySQL server that uses the
      <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
       <code class="literal">
        NDBCLUSTER
       </code>
      </a>
      storage engine. An SQL
          node is a
      <a class="link" href="mysqld.html" title="6.3.1 mysqld — The MySQL Server">
       <span class="command">
        <strong>
         mysqld
        </strong>
       </span>
      </a>
      process started with the
      <a class="link" href="mysql-cluster-options-variables.html#option_mysqld_ndbcluster">
       <code class="option">
        --ndbcluster
       </code>
      </a>
      and
      <code class="option">
       --ndb-connectstring
      </code>
      options, which are
          explained elsewhere in this chapter, possibly with additional
          MySQL server options as well.
     </p>
     <p>
      An SQL node is actually just a specialized type of
      <span class="firstterm">
       API node
      </span>
      , which
          designates any application which accesses NDB Cluster data.
          Another example of an API node is the
      <a class="link" href="mysql-cluster-programs-ndb-restore.html" title="25.5.23 ndb_restore — Restore an NDB Cluster Backup">
       <span class="command">
        <strong>
         ndb_restore
        </strong>
       </span>
      </a>
      utility that is used to restore
          a cluster backup. It is possible to write such applications
          using the NDB API. For basic information about the NDB API,
          see
      <a class="ulink" href="/doc/ndbapi/en/ndb-getting-started.html" target="_top">
       Getting Started with the NDB API
      </a>
      .
     </p>
    </li>
   </ul>
  </div>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    It is not realistic to expect to employ a three-node setup in a
        production environment. Such a configuration provides no
        redundancy; to benefit from NDB Cluster's high-availability
        features, you must use multiple data and SQL nodes. The use of
        multiple management nodes is also highly recommended.
   </p>
  </div>
  <p>
   For a brief introduction to the relationships between nodes, node
      groups, fragment replicas, and partitions in NDB Cluster, see
   <a class="xref" href="mysql-cluster-nodes-groups.html" title="25.2.2 NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions">
    Section 25.2.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions”
   </a>
   .
  </p>
  <p>
   Configuration of a cluster involves configuring each individual
      node in the cluster and setting up individual communication links
      between nodes. NDB Cluster is currently designed with the
      intention that data nodes are homogeneous in terms of processor
      power, memory space, and bandwidth. In addition, to provide a
      single point of configuration, all configuration data for the
      cluster as a whole is located in one configuration file.
  </p>
  <p>
   The management server manages the cluster configuration file and
      the cluster log. Each node in the cluster retrieves the
      configuration data from the management server, and so requires a
      way to determine where the management server resides. When
      interesting events occur in the data nodes, the nodes transfer
      information about these events to the management server, which
      then writes the information to the cluster log.
  </p>
  <p>
   In addition, there can be any number of cluster client processes
      or applications. These include standard MySQL clients,
   <code class="literal">
    NDB
   </code>
   -specific API programs, and management
      clients. These are described in the next few paragraphs.
  </p>
  <p>
   <b>
    Standard MySQL clients.
   </b>
   NDB Cluster can be used with existing MySQL applications written
        in PHP, Perl, C, C++, Java, Python, and so on. Such client
        applications send SQL statements to and receive responses from
        MySQL servers acting as NDB Cluster SQL nodes in much the same
        way that they interact with standalone MySQL servers.
  </p>
  <a class="indexterm" name="idm46045124278320">
  </a>
  <a class="indexterm" name="idm46045124276832">
  </a>
  <a class="indexterm" name="idm46045124275344">
  </a>
  <p>
   MySQL clients using an NDB Cluster as a data source can be
      modified to take advantage of the ability to connect with multiple
      MySQL servers to achieve load balancing and failover. For example,
      Java clients using Connector/J 5.0.6 and later can use
   <code class="literal">
    jdbc:mysql:loadbalance://
   </code>
   URLs (improved in
      Connector/J 5.1.7) to achieve load balancing transparently; for
      more information about using Connector/J with NDB Cluster, see
   <a class="ulink" href="/doc/ndbapi/en/mccj-using-connectorj.html" target="_top">
    Using Connector/J with NDB Cluster
   </a>
   .
  </p>
  <p>
   <b>
    NDB client programs.
   </b>
   Client programs can be written that access NDB Cluster data
        directly from the
   <code class="literal">
    NDBCLUSTER
   </code>
   storage engine,
        bypassing any MySQL Servers that may be connected to the
        cluster, using the
   <span class="firstterm">
    NDB
        API
   </span>
   , a high-level C++ API. Such applications may be
        useful for specialized purposes where an SQL interface to the
        data is not needed. For more information, see
   <a class="ulink" href="/doc/ndbapi/en/ndbapi.html" target="_top">
    The NDB API
   </a>
   .
  </p>
  <p>
   <code class="literal">
    NDB
   </code>
   -specific Java applications can also be
      written for NDB Cluster using the
   <span class="firstterm">
    NDB
      Cluster Connector for Java
   </span>
   . This NDB Cluster Connector
      includes
   <span class="firstterm">
    ClusterJ
   </span>
   , a
      high-level database API similar to object-relational mapping
      persistence frameworks such as Hibernate and JPA that connect
      directly to
   <code class="literal">
    NDBCLUSTER
   </code>
   , and so does not require
      access to a MySQL Server. See
   <a class="ulink" href="/doc/ndbapi/en/mccj-overview-java.html" target="_top">
    Java and NDB Cluster
   </a>
   , and
   <a class="ulink" href="/doc/ndbapi/en/mccj-overview-clusterj-object-models.html" target="_top">
    The ClusterJ API and Data Object Model
   </a>
   , for more
      information.
  </p>
  <p>
   NDB Cluster also supports applications written in JavaScript using
      Node.js. The MySQL Connector for JavaScript includes adapters for
      direct access to the
   <code class="literal">
    NDB
   </code>
   storage engine and as
      well as for the MySQL Server. Applications using this Connector
      are typically event-driven and use a domain object model similar
      in many ways to that employed by ClusterJ. For more information,
      see
   <a class="ulink" href="/doc/ndbapi/en/ndb-nodejs.html" target="_top">
    MySQL NoSQL Connector for JavaScript
   </a>
   .
  </p>
  <p>
   <b>
    Management clients.
   </b>
   These clients connect to the management server and provide
        commands for starting and stopping nodes gracefully, starting
        and stopping message tracing (debug versions only), showing node
        versions and status, starting and stopping backups, and so on.
        An example of this type of program is the
   <a class="link" href="mysql-cluster-programs-ndb-mgm.html" title="25.5.5 ndb_mgm — The NDB Cluster Management Client">
    <span class="command">
     <strong>
      ndb_mgm
     </strong>
    </span>
   </a>
   management client supplied with NDB
        Cluster (see
   <a class="xref" href="mysql-cluster-programs-ndb-mgm.html" title="25.5.5 ndb_mgm — The NDB Cluster Management Client">
    Section 25.5.5, “ndb_mgm — The NDB Cluster Management Client”
   </a>
   ).
        Such applications can be written using the
   <span class="firstterm">
    MGM API
   </span>
   , a C-language API
        that communicates directly with one or more NDB Cluster
        management servers. For more information, see
   <a class="ulink" href="/doc/ndbapi/en/mgm-api.html" target="_top">
    The MGM API
   </a>
   .
  </p>
  <p>
   Oracle also makes available MySQL Cluster Manager, which provides an advanced
      command-line interface simplifying many complex NDB Cluster
      management tasks, such restarting an NDB Cluster with a large
      number of nodes. The MySQL Cluster Manager client also supports commands for
      getting and setting the values of most node configuration
      parameters as well as
   <a class="link" href="mysqld.html" title="6.3.1 mysqld — The MySQL Server">
    <span class="command">
     <strong>
      mysqld
     </strong>
    </span>
   </a>
   server options and
      variables relating to NDB Cluster. See
   <a class="ulink" href="/doc/mysql-cluster-manager/8.4/en/" target="_top">
    MySQL Cluster Manager 8.4.3 User Manual
   </a>
   , for
      more information.
  </p>
  <p>
   <b>
    Event logs.
   </b>
   NDB Cluster logs events by category (startup, shutdown, errors,
        checkpoints, and so on), priority, and severity. A complete
        listing of all reportable events may be found in
   <a class="xref" href="mysql-cluster-event-reports.html" title="25.6.3 Event Reports Generated in NDB Cluster">
    Section 25.6.3, “Event Reports Generated in NDB Cluster”
   </a>
   . Event logs are of
        the two types listed here:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <span class="firstterm">
       Cluster log
      </span>
      : Keeps a
          record of all desired reportable events for the cluster as a
          whole.
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="firstterm">
       Node log
      </span>
      : A separate log
          which is also kept for each individual node.
     </p>
    </li>
   </ul>
  </div>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    Under normal circumstances, it is necessary and sufficient to
        keep and examine only the cluster log. The node logs need be
        consulted only for application development and debugging
        purposes.
   </p>
  </div>
  <p>
   <b>
    Checkpoint.
   </b>
   Generally speaking, when data is saved to disk, it is said that
        a
   <span class="firstterm">
    checkpoint
   </span>
   has been
        reached. More specific to NDB Cluster, a checkpoint is a point
        in time where all committed transactions are stored on disk.
        With regard to the
   <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
    <code class="literal">
     NDB
    </code>
   </a>
   storage
        engine, there are two types of checkpoints which work together
        to ensure that a consistent view of the cluster's data is
        maintained. These are shown in the following list:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <span class="firstterm">
       Local Checkpoint (LCP)
      </span>
      :
          This is a checkpoint that is specific to a single node;
          however, LCPs take place for all nodes in the cluster more or
          less concurrently. An LCP usually occurs every few minutes;
          the precise interval varies, and depends upon the amount of
          data stored by the node, the level of cluster activity, and
          other factors.
     </p>
     <p>
      NDB 8.4 supports partial LCPs, which can
          significantly improve performance under some conditions. See
          the descriptions of the
      <a class="link" href="mysql-cluster-ndbd-definition.html#ndbparam-ndbd-enablepartiallcp">
       <code class="literal">
        EnablePartialLcp
       </code>
      </a>
      and
      <a class="link" href="mysql-cluster-ndbd-definition.html#ndbparam-ndbd-recoverywork">
       <code class="literal">
        RecoveryWork
       </code>
      </a>
      configuration parameters which enable partial LCPs and control
          the amount of storage they use.
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="firstterm">
       Global Checkpoint (GCP)
      </span>
      :
          A GCP occurs every few seconds, when transactions for all
          nodes are synchronized and the redo-log is flushed to disk.
     </p>
    </li>
   </ul>
  </div>
  <p>
   For more information about the files and directories created by
      local checkpoints and global checkpoints, see
   <a class="ulink" href="/doc/ndb-internals/en/ndb-internals-ndbd-filesystemdir-files.html" target="_top">
    NDB Cluster Data Node File System Directory
   </a>
   .
  </p>
  <a class="indexterm" name="idm46045124233760">
  </a>
  <a class="indexterm" name="idm46045124232272">
  </a>
  <p>
   <b>
    Transporter.
   </b>
   We use the term
   <span class="firstterm">
    transporter
   </span>
   for the data
        transport mechanism employed between data nodes. MySQL NDB
        Cluster 8.4 supports three of these, which are
        listed here:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <span class="emphasis">
       <em>
        TCP/IP over Ethernet
       </em>
      </span>
      . See
      <a class="xref" href="mysql-cluster-tcp-definition.html" title="25.4.3.10 NDB Cluster TCP/IP Connections">
       Section 25.4.3.10, “NDB Cluster TCP/IP Connections”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="emphasis">
       <em>
        Direct TCP/IP
       </em>
      </span>
      . Uses machine-to-machine
          connections. See
      <a class="xref" href="mysql-cluster-tcp-definition-direct.html" title="25.4.3.11 NDB Cluster TCP/IP Connections Using Direct Connections">
       Section 25.4.3.11, “NDB Cluster TCP/IP Connections Using Direct Connections”
      </a>
      .
     </p>
     <p>
      Although this transporter uses the same TCP/IP protocol as
          mentioned in the previous item, it requires setting up the
          hardware differently and is configured differently as well.
          For this reason, it is considered a separate transport
          mechanism for NDB Cluster.
     </p>
    </li>
    <li class="listitem">
     <p>
      <span class="emphasis">
       <em>
        Shared memory (SHM)
       </em>
      </span>
      . See
      <a class="xref" href="mysql-cluster-shm-definition.html" title="25.4.3.12 NDB Cluster Shared-Memory Connections">
       Section 25.4.3.12, “NDB Cluster Shared-Memory Connections”
      </a>
      .
     </p>
    </li>
   </ul>
  </div>
  <p>
   Because it is ubiquitous, most users employ TCP/IP over Ethernet
      for NDB Cluster.
  </p>
  <p>
   Regardless of the transporter used,
   <code class="literal">
    NDB
   </code>
   attempts to make sure that communication between data node
      processes is performed using chunks that are as large as possible
      since this benefits all types of data transmission.
  </p>
 </div>
 <br/>
</div>
