Movatterモバイル変換

このページは機械翻訳したものです。

NDB Cluster から最高のパフォーマンスを得るには、次のような多くの要因があります:

したがって、最適な構成の取得は反復プロセスである可能性が高く、その結果は NDB Cluster デプロイメントごとに大きく異なる可能性があります。 構成の変更は、クラスタが実行されているプラットフォーム、または NDB Cluster のデータを使用するアプリケーションで変更が行われたときにも示される可能性があります。 これらの理由により、すべての使用シナリオに適した単一の構成を提示することは不可能です。 ただし、このセクションでは推奨されるベース構成を示します。

初期の config.ini ファイル.  NDB Cluster 8.0 を実行しているクラスタを構成するには、次のconfig.ini ファイルを開始することをお勧めします:

# TCP PARAMETERS[tcp default]SendBufferMemory=2MReceiveBufferMemory=2M# Increasing the sizes of these 2 buffers beyond the default values# helps prevent bottlenecks due to slow disk I/O.# MANAGEMENT NODE PARAMETERS[ndb_mgmd default]DataDir=path/to/management/server/data/directory# It is possible to use a different data directory for each management# server, but for ease of administration it is preferable to be# consistent.[ndb_mgmd]HostName=management-server-A-hostname# NodeId=management-server-A-nodeid[ndb_mgmd]HostName=management-server-B-hostname# 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 is 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.# DATA NODE PARAMETERS[ndbd default]NoOfReplicas=2# Using two fragment replicas is recommended to guarantee availability of data;# using only one fragment replica does not provide any redundancy, which means# that the failure of a single data node causes the entire cluster to# shut down. As of NDB 8.0.19, it is also possible (but not required) to# use more than two fragment replicas, although two fragment replicas are# sufficient to provide high availability.LockPagesInMainMemory=1# 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.DataMemory=3456M# The value provided for DataMemory assumes 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 ndb_size.pl 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 NDB Cluster on systems running# Linux kernel 2.6 or later.NoOfFragmentLogFiles=300DataDir=path/to/data/node/data/directoryMaxNoOfConcurrentOperations=100000SchedulerSpinTimer=400SchedulerExecutionTimer=100RealTimeScheduler=1# 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.TimeBetweenGlobalCheckpoints=1000TimeBetweenEpochs=200RedoBuffer=32M# CompressedLCP=1# CompressedBackup=1# Enabling CompressedLCP and CompressedBackup causes, respectively, localcheckpoint files and backup files to be compressed, which can result in a spacesavings of up to 50% over noncompressed LCPs and backups.# MaxNoOfLocalScans=64MaxNoOfTables=1024MaxNoOfOrderedIndexes=256[ndbd]HostName=data-node-A-hostname# NodeId=data-node-A-nodeidLockExecuteThreadToCPU=1LockMaintThreadsToCPU=0# On systems with multiple CPUs, these parameters can be used to lock NDBCLUSTER# threads to specific CPUs[ndbd]HostName=data-node-B-hostname# NodeId=data-node-B-nodeidLockExecuteThreadToCPU=1LockMaintThreadsToCPU=0# 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 144 inclusive and must be unique among all IDs specified for# cluster nodes. (Previous to NDB 8.0.18, this range was 1 to 48 inclusive.)# SQL NODE / API NODE PARAMETERS[mysqld]# HostName=sql-node-A-hostname# NodeId=sql-node-A-nodeid[mysqld][mysqld]# 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,# thenany 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 オプション.  NDB Cluster SQL ノードとして機能する MySQL Servers は、常に--ndbcluster および--ndb-connectstring オプションを使用して、コマンド行またはmy.cnf で起動する必要があります。 さらに、セットアップでほかのオプションを必要とする場合を除き、クラスタ内のすべてのmysqld プロセスに次のオプションを設定してください。