<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="mysql-cluster-limitations-multiple-nodes">
      </a>
      25.2.7.10 Limitations Relating to Multiple NDB Cluster Nodes
     </h4>
    </div>
   </div>
  </div>
  <p>
   <b>
    Multiple SQL nodes.
   </b>
   <a class="indexterm" name="idm46045123152960">
   </a>
   The following are issues relating to the use of multiple MySQL
          servers as NDB Cluster SQL nodes, and are specific to the
   <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
    <code class="literal">
     NDBCLUSTER
    </code>
   </a>
   storage engine:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      <b>
       Stored programs not distributed.
      </b>
      Stored procedures, stored functions, triggers, and
              scheduled events are all supported by tables using the
      <a class="link" href="mysql-cluster.html" title="Chapter 25 MySQL NDB Cluster 8.4">
       <code class="literal">
        NDB
       </code>
      </a>
      storage engine, but these
              do
      <span class="emphasis">
       <em>
        not
       </em>
      </span>
      propagate automatically
              between MySQL Servers acting as Cluster SQL nodes, and
              must be re-created separately on each SQL node. See
      <a class="xref" href="stored-program-restrictions.html#stored-routines-ndbcluster" title="Stored routines and triggers in NDB Cluster">
       Stored routines and triggers in NDB Cluster
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       No distributed table locks.
      </b>
      A
      <a class="link" href="lock-tables.html" title="15.3.6 LOCK TABLES and UNLOCK TABLES Statements">
       <code class="literal">
        LOCK TABLES
       </code>
      </a>
      statement or
      <a class="link" href="locking-functions.html#function_get-lock">
       <code class="literal">
        GET_LOCK()
       </code>
      </a>
      call works only
              for the SQL node on which the lock is issued; no other SQL
              node in the cluster
      <span class="quote">
       “
       <span class="quote">
        sees
       </span>
       ”
      </span>
      this lock. This is
              true for a lock issued by any statement that locks tables
              as part of its operations. (See next item for an example.)
     </p>
     <p>
      Implementing table locks in
      <code class="literal">
       NDBCLUSTER
      </code>
      can be done in an API application, and ensuring that all
            applications start by setting
      <a class="ulink" href="/doc/ndbapi/en/ndb-ndboperation.html#ndb-ndboperation-lockmode" target="_top">
       <code class="literal">
        LockMode
       </code>
      </a>
      to
      <code class="literal">
       LM_Read
      </code>
      or
      <code class="literal">
       LM_Exclusive
      </code>
      . For more information about
            how to do this, see the description of
      <a class="ulink" href="/doc/ndbapi/en/ndb-ndboperation.html#ndb-ndboperation-getlockhandle" target="_top">
       <code class="literal">
        NdbOperation::getLockHandle()
       </code>
      </a>
      in the
      <em class="citetitle">
       NDB Cluster API Guide
      </em>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      <b>
       ALTER TABLE operations.
      </b>
      <a class="link" href="alter-table.html" title="15.1.9 ALTER TABLE Statement">
       <code class="literal">
        ALTER TABLE
       </code>
      </a>
      is not fully
              locking when running multiple MySQL servers (SQL nodes).
              (As discussed in the previous item, NDB Cluster does not
              support distributed table locks.)
     </p>
    </li>
   </ul>
  </div>
  <p>
   <b>
    Multiple management nodes.
   </b>
   <a class="indexterm" name="idm46045123130560">
   </a>
   When using multiple management servers:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      If any of the management servers are running on the same
            host, you must give nodes explicit IDs in connection strings
            because automatic allocation of node IDs does not work
            across multiple management servers on the same host. This is
            not required if every management server resides on a
            different host.
     </p>
    </li>
    <li class="listitem">
     <p>
      When a management server starts, it first checks for any
            other management server in the same NDB Cluster, and upon
            successful connection to the other management server uses
            its configuration data. This means that the management
            server
      <a class="link" href="mysql-cluster-programs-ndb-mgmd.html#option_ndb_mgmd_reload">
       <code class="option">
        --reload
       </code>
      </a>
      and
      <a class="link" href="mysql-cluster-programs-ndb-mgmd.html#option_ndb_mgmd_initial">
       <code class="option">
        --initial
       </code>
      </a>
      startup options
            are ignored unless the management server is the only one
            running. It also means that, when performing a rolling
            restart of an NDB Cluster with multiple management nodes,
            the management server reads its own configuration file if
            (and only if) it is the only management server running in
            this NDB Cluster. See
      <a class="xref" href="mysql-cluster-rolling-restart.html" title="25.6.5 Performing a Rolling Restart of an NDB Cluster">
       Section 25.6.5, “Performing a Rolling Restart of an NDB Cluster”
      </a>
      , for more
            information.
     </p>
    </li>
   </ul>
  </div>
  <p>
   <b>
    Multiple network addresses.
   </b>
   Multiple network addresses per data node are not supported.
          Use of these is liable to cause problems: In the event of a
          data node failure, an SQL node waits for confirmation that the
          data node went down but never receives it because another
          route to that data node remains open. This can effectively
          make the cluster inoperable.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    It is possible to use multiple network hardware
    <span class="emphasis">
     <em>
      interfaces
     </em>
    </span>
    (such as Ethernet cards) for a
          single data node, but these must be bound to the same address.
          This also means that it not possible to use more than one
    <code class="literal">
     [tcp]
    </code>
    section per connection in the
    <code class="literal">
     config.ini
    </code>
    file. 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>
    , for more
          information.
   </p>
  </div>
 </div>
 <br/>
</div>
