Skip navigation links
MySQL Cluster :: 3 MySQL Cluster Configuration :: 3.2 MySQL Cluster Configuration Files :: 3.2.11 SCI Transport Connections in MySQL Cluster
3.2.12 Configuring MySQL Cluster Parameters for Local Checkpoints »
Section Navigation      [Toggle]

3.2.11. SCI Transport Connections in MySQL Cluster

[sci] sections in the config.ini file explicitly define SCI (Scalable Coherent Interface) connections between cluster nodes. Using SCI transporters in MySQL Cluster is supported only when the MySQL binaries are built using --with-ndb-sci=/your/path/to/SCI. The path should point to a directory that contains at a minimum lib and include directories containing SISCI libraries and header files. (See Section 3.5, “Using High-Speed Interconnects with MySQL Cluster” for more information about SCI.)

In addition, SCI requires specialized hardware.

It is strongly recommended to use SCI Transporters only for communication between ndbd processes. Note also that using SCI Transporters means that the ndbd processes never sleep. For this reason, SCI Transporters should be used only on machines having at least two CPUs dedicated for use by ndbd processes. There should be at least one CPU per ndbd process, with at least one CPU left in reserve to handle operating system activities.

  • NodeId1, NodeId2

    To identify a connection between two nodes it is necessary to provide node identifiers for each of them, as NodeId1 and NodeId2.

  • Host1SciId0

    Restart Type node
      Permitted Values
    Type numeric
    Default
    Range 0-4G

    This identifies the SCI node ID on the first Cluster node (identified by NodeId1).

  • Host1SciId1

    Restart Type node
      Permitted Values
    Type numeric
    Default 0
    Range 0-4G

    It is possible to set up SCI Transporters for failover between two SCI cards which then should use separate networks between the nodes. This identifies the node ID and the second SCI card to be used on the first node.

  • Host2SciId0

    Restart Type node
      Permitted Values
    Type numeric
    Default
    Range 0-4G

    This identifies the SCI node ID on the second Cluster node (identified by NodeId2).

  • Host2SciId1

    Restart Type node
      Permitted Values
    Type numeric
    Default 0
    Range 0-4G

    When using two SCI cards to provide failover, this parameter identifies the second SCI card to be used on the second node.

  • SharedBufferSize

    Restart Type node
      Permitted Values
    Type numeric
    Default 10M
    Range 64K-4G

    Each SCI transporter has a shared memory segment used for communication between the two nodes. Setting the size of this segment to the default value of 1MB should be sufficient for most applications. Using a smaller value can lead to problems when performing many parallel inserts; if the shared buffer is too small, this can also result in a crash of the ndbd process.

  • SendLimit

    Restart Type node
      Permitted Values
    Type numeric
    Default 8K
    Range 128-32K

    A small buffer in front of the SCI media stores messages before transmitting them over the SCI network. By default, this is set to 8KB. Our benchmarks show that performance is best at 64KB but 16KB reaches within a few percent of this, and there was little if any advantage to increasing it beyond 8KB.

  • SendSignalId

    Restart Type node
      Permitted Values
    Type boolean
    Default true
    Range -

    To trace a distributed message it is necessary to identify each message uniquely. When this parameter is set to Y, message IDs are transported over the network. This feature is disabled by default in production builds, and enabled in -debug builds.

  • Checksum

    Restart Type node
      Permitted Values
    Type boolean
    Default false
    Range -

    This parameter is a boolean value, and is disabled by default. When Checksum is enabled, checksums are calculated for all messages before they are placed in the send buffer. This feature prevents messages from being corrupted while waiting in the send buffer. It also serves as a check against data being corrupted during transport.