Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb MySQL Cluster の推奨される初期構成

MySQL Cluster で最良のパフォーマンスを実現できるかどうかは、次を含むいくつかの要因に依存します。

  • MySQL Cluster ソフトウェアのバージョン

  • データノードおよび SQL ノードの数

  • ハードウェア

  • オペレーティングシステム

  • 格納されるデータの量

  • クラスタ稼働時の負荷のサイズとタイプ

このため、最適な構成を獲得するプロセスは反復的なものになる可能性が高く、その結果は個々の MySQL Cluster 配備によって大きく異なる可能性があります。クラスタが動作するプラットフォームや MySQL Cluster のデータを使用するアプリケーションに変更が加えられたときは、構成の変更も必要になる可能性があります。これらの理由により、すべての使用シナリオに適した単一の構成を提示することは不可能です。ただし、このセクションでは推奨されるベース構成を示します。

初期の config.ini ファイル  MySQL Cluster NDB 7.3 以降を実行するクラスタ構成の開始点として、次の config.ini ファイルを推奨します。


[tcp default]

# Increasing the sizes of these 2 buffers beyond the default values
# helps prevent bottlenecks due to slow disk I/O.


[ndb_mgmd default]

# It is possible to use a different data directory for each management
# server, but for ease of administration it is preferable to be
# consistent.

# NodeId=management-server-A-nodeid

# NodeId=management-server-B-nodeid

# Using 2 management servers helps guarantee that there is always an
# arbitrator in the event of network partitioning, and so is
# recommended for high availability. Each management server must be
# identified by a HostName. You may for the sake of convenience specify
# a NodeId for any management server, although one will be allocated
# for it automatically; if you do so, it must be in the range 1-255
# inclusive and must be unique among all IDs specified for cluster
# nodes.


[ndbd default]

# Using 2 replicas is recommended to guarantee availability of data; 
# using only 1 replica does not provide any redundancy, which means 
# that the failure of a single data node causes the entire cluster to 
# shut down. We do not recommend using more than 2 replicas, since 2 is 
# sufficient to provide high availability, and we do not currently test 
# with greater values for this parameter.


# On Linux and Solaris systems, setting this parameter locks data node
# processes into memory. Doing so prevents them from swapping to disk,
# which can severely degrade cluster performance.


# The values provided for DataMemory and IndexMemory assume 4 GB RAM
# per data node. However, for best results, you should first calculate
# the memory that would be used based on the data you actually plan to
# store (you may find the utility helpful in estimating
# this), then allow an extra 20% over the calculated values. Naturally,
# you should ensure that each data node host has at least as much
# physical memory as the sum of these two values.

# ODirect=1

# Enabling this parameter causes NDBCLUSTER to try using O_DIRECT
# writes for local checkpoints and redo logs; this can reduce load on
# CPUs. We recommend doing so when using MySQL Cluster on systems running 
# Linux kernel 2.6 or later.


# Setting these parameters allows you to take advantage of real-time scheduling
# of NDB threads to achieve increased throughput when using ndbd. They 
# are not needed when using ndbmtd; in particular, you should not set 
# RealTimeScheduler for ndbmtd data nodes.


# CompressedLCP=1
# CompressedBackup=1
# Enabling CompressedLCP and CompressedBackup causes, respectively, local
checkpoint files and backup files to be compressed, which can result in a space
savings of up to 50% over noncompressed LCPs and backups.

# MaxNoOfLocalScans=64

# NodeId=data-node-A-nodeid

# On systems with multiple CPUs, these parameters can be used to lock NDBCLUSTER
# threads to specific CPUs

# NodeId=data-node-B-nodeid


# You must have an [ndbd] section for every data node in the cluster;
# each of these sections must include a HostName. Each section may
# optionally include a NodeId for convenience, but in most cases, it is
# sufficient to allow the cluster to allocate node IDs dynamically. If
# you do specify the node ID for a data node, it must be in the range 1
# to 48 inclusive and must be unique among all IDs specified for
# cluster nodes.


# HostName=sql-node-A-hostname
# NodeId=sql-node-A-nodeid



# Each API or SQL node that connects to the cluster requires a [mysqld]
# or [api] section of its own. Each such section defines a connection
# 「slot」; you should have at least as many of these sections in the
# config.ini file as the total number of API nodes and SQL nodes that
# you wish to have connected to the cluster at any given time. There is
# no performance or other penalty for having extra slots available in
# case you find later that you want or need more API or SQL nodes to
# connect to the cluster at the same time.
# If no HostName is specified for a given [mysqld] or [api] section,
# then any API or SQL node may use that slot to connect to the
# cluster. You may wish to use an explicit HostName for one connection slot
# to guarantee that an API or SQL node from that host can always
# connect to the cluster. If you wish to prevent API or SQL nodes from
# connecting from other than a desired host or hosts, then use a
# HostName for every [mysqld] or [api] section in the config.ini file.
# You can if you wish define a node ID (NodeId parameter) for any API or
# SQL node, but this is not necessary; if you do so, it must be in the
# range 1 to 255 inclusive and must be unique among all IDs specified
# for cluster nodes.

推奨される SQL ノードの my.cnf オプション  MySQL Cluster SQL ノードとして機能する MySQL サーバーは、常にコマンド行または my.cnf--ndbcluster および --ndb-connectstring オプションを指定して起動する必要があります。さらに、セットアップでほかのオプションを必要とする場合を除き、クラスタ内のすべての mysqld プロセスに次のオプションを設定してください。

  • --ndb-use-exact-count=0

  • --ndb-index-stat-enable=0

  • --ndb-force-send=1

  • --engine-condition-pushdown=1

User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.