ndb_mgmd man page on NetBSD

Man page or keyword search:  
man Server   9087 pages
apropos Keyword Search (all sections)
Output format
NetBSD logo
[printable version]

NDB_MGMD(8)		     MySQL Database System		   NDB_MGMD(8)

NAME
       ndb_mgmd - the MySQL Cluster management server daemon

SYNOPSIS
       ndb_mgmd options

DESCRIPTION
       The management server is the process that reads the cluster
       configuration file and distributes this information to all nodes in the
       cluster that request it. It also maintains a log of cluster activities.
       Management clients can connect to the management server and check the
       cluster´s status.

       The following table includes options that are specific to the MySQL
       Cluster management server program ndb_mgmd. Additional descriptions
       follow the table. For options common to all MySQL Cluster programs, see
       Section 17.4.2, “Options Common to MySQL Cluster Programs”.

       ·   --bind-address=host[:port]

	   ┌────────────────────┬──────────────────┐
	   │Version Introduced	│ 5.1.22-ndb-6.3.2 │
	   ├────────────────────┼──────────────────┤
	   │Command-Line Format │ --bind-address   │
	   ├────────────────────┼──────────────────┤
	   │			│ Permitted Values │
	   │			├─────────┬────────┤
	   │			│ Type	  │ string │
	   │			├─────────┼────────┤
	   │			│ Default │ [none] │
	   └────────────────────┴─────────┴────────┘
	   When specified, this option limits management server connections by
	   management clients to clients at the specified host name or IP
	   address (and possibly port, if this is also specified). In such
	   cases, a management client attempting to connect to the management
	   server from any other address fails with the error Unable to setup
	   port: host:port!

	   If the port is not specified, the management client attempts to use
	   port 1186.

	   This option was added in MySQL Cluster NDB 6.2.5 and MySQL Cluster
	   NDB 6.3.2.

       ·   --configdir=directory

	   ┌────────────────────┬─────────────────────────────────────┐
	   │Version Introduced	│ 5.1.30-ndb-6.4.0		      │
	   ├────────────────────┼─────────────────────────────────────┤
	   │Command-Line Format │ --configdir=directory		      │
	   ├────────────────────┼─────────────────────────────────────┤
	   │			│ Permitted Values		      │
	   │			├─────────┬───────────────────────────┤
	   │			│ Type	  │ filename		      │
	   │			├─────────┼───────────────────────────┤
	   │			│ Default │ $INSTALLDIR/mysql-cluster │
	   └────────────────────┴─────────┴───────────────────────────┘
	   Beginning with MySQL Cluster NDB 6.4.0, configuration data is
	   cached internally rather than being read from the cluster global
	   configuration file each time the management server is started (see
	   Section 17.3.2, “MySQL Cluster Configuration Files”). This option
	   instructs the management server to its configuration cache in the
	   directory indicated. By default, this is a directory named
	   mysql-cluster in the MySQL installation directory — for example, if
	   you compile and install MySQL Cluster on a Unix system using the
	   default location, this is /usr/local/mysql-cluster.

	   This behavior can be overridden using the --initial or --reload
	   option for ndb_mgmd. Each of these options is described elsewhere
	   in this section.

	   This option is available beginning with MySQL Cluster NDB 6.4.0.

	   Beginning with MySQL Cluster NDB 7.0.8, --config-dir is accepted as
	   an alias for --configdir.

       ·   --config-file=filename, -f filename

	   ┌────────────────────┬────────────────────────┐
	   │Command-Line Format │ -c			 │
	   ├────────────────────┼────────────────────────┤
	   │			│ Permitted Values	 │
	   │			├─────────┬──────────────┤
	   │			│ Type	  │ filename	 │
	   │			├─────────┼──────────────┤
	   │			│ Default │ ./config.ini │
	   └────────────────────┴─────────┴──────────────┘
	   Instructs the management server as to which file it should use for
	   its configuration file. By default, the management server looks for
	   a file named config.ini in the same directory as the ndb_mgmd
	   executable; otherwise the file name and location must be specified
	   explicitly.

	   Beginning with MySQL Cluster NDB 6.4.0, this option is ignored
	   unless the management server is forced to read the configuration
	   file, either because ndb_mgmd was started with the --reload or
	   --initial option, or because the management server could not find
	   any configuration cache. See Section 17.3.2, “MySQL Cluster
	   Configuration Files”, for more information.

       ·   --daemon, -d

	   ┌────────────────────┬───────────────────┐
	   │Command-Line Format │ --daemon	    │
	   ├────────────────────┼───────────────────┤
	   │			│ Permitted Values  │
	   │			├─────────┬─────────┤
	   │			│ Type	  │ boolean │
	   │			├─────────┼─────────┤
	   │			│ Default │ TRUE    │
	   └────────────────────┴─────────┴─────────┘
	   Instructs ndb_mgmd to start as a daemon process. This is the
	   default behavior.

	   This option has no effect when running ndb_mgmd on Windows
	   platforms.

       ·   --initial

	   ┌────────────────────┬───────────────────┐
	   │Version Introduced	│ 5.1.30-ndb-6.4.0  │
	   ├────────────────────┼───────────────────┤
	   │Command-Line Format │ --initial	    │
	   ├────────────────────┼───────────────────┤
	   │			│ Permitted Values  │
	   │			├─────────┬─────────┤
	   │			│ Type	  │ boolean │
	   │			├─────────┼─────────┤
	   │			│ Default │ FALSE   │
	   └────────────────────┴─────────┴─────────┘
	   Beginning with MySQL Cluster NDB 6.4.0, configuration data is
	   cached internally rather than being read from the cluster global
	   configuration file each time the management server is started (see
	   Section 17.3.2, “MySQL Cluster Configuration Files”). Using this
	   option overrides this behavior, by forcing the management server to
	   delete any existing cache files, and then to re-read the
	   configuration data from the cluster configuration file and to build
	   a new cache.

	   This differs in two ways from the --reload option. First, --reload
	   forces the server to check the configuration file against the cache
	   and reload its data only if the contents of the file are different
	   from the cache. Second, --reload does not delete any existing cache
	   files.

	   If ndb_mgmd is invoked with --initial but cannot find a global
	   configuration file, the management server cannot start.

	   This option was introduced in MySQL Cluster NDB 6.4.0.

       ·   --log-name=name

	   ┌────────────────────┬────────────────────┐
	   │Version Introduced	│ 5.1.37-ndb-7.0.8   │
	   ├────────────────────┼────────────────────┤
	   │Command-Line Format │ --log-name=	     │
	   ├────────────────────┼────────────────────┤
	   │			│ Permitted Values   │
	   │			├─────────┬──────────┤
	   │			│ Type	  │ string   │
	   │			├─────────┼──────────┤
	   │			│ Default │ MgmtSrvr │
	   └────────────────────┴─────────┴──────────┘
	   Provides a name to be used for this node in the cluster log.

	   This option was added in MySQL Cluster NDB 7.0.8.

       ·   --nodaemon

	   ┌────────────────────┬──────────────────────────┐
	   │Command-Line Format │ --nodaemon		   │
	   ├────────────────────┼──────────────────────────┤
	   │			│ Permitted Values	   │
	   │			├────────────────┬─────────┤
	   │			│ Type		 │ boolean │
	   │			├────────────────┼─────────┤
	   │			│ Default	 │ FALSE   │
	   ├────────────────────┼────────────────┴─────────┤
	   │			│ Permitted Values	   │
	   │			├────────────────┬─────────┤
	   │			│ Type (windows) │ boolean │
	   │			├────────────────┼─────────┤
	   │			│ Default	 │ TRUE	   │
	   └────────────────────┴────────────────┴─────────┘
	   Instructs ndb_mgmd not to start as a daemon process.

	   As of MySQL Cluster NDB 7.0.8, the default behavior for ndb_mgmd on
	   Windows is to run in the foreground, making this option unnecessary
	   on Windows platforms. (Bug#45588[1])

       ·   --print-full-config, -P

	   ┌────────────────────┬─────────────────────┐
	   │Command-Line Format │ --print-full-config │
	   ├────────────────────┼─────────────────────┤
	   │			│ Permitted Values    │
	   │			├──────────┬──────────┤
	   │			│ Type	   │ boolean  │
	   │			├──────────┼──────────┤
	   │			│ Default  │ FALSE    │
	   └────────────────────┴──────────┴──────────┘
	   Shows extended information regarding the configuration of the
	   cluster. With this option on the command line the ndb_mgmd process
	   prints information about the cluster setup including an extensive
	   list of the cluster configuration sections as well as parameters
	   and their values. Normally used together with the --config-file
	   (-f) option.

       ·   --reload

	   ┌────────────────────┬───────────────────┐
	   │Version Introduced	│ 5.1.30-ndb-6.4.0  │
	   ├────────────────────┼───────────────────┤
	   │Command-Line Format │ --reload	    │
	   ├────────────────────┼───────────────────┤
	   │			│ Permitted Values  │
	   │			├─────────┬─────────┤
	   │			│ Type	  │ boolean │
	   │			├─────────┼─────────┤
	   │			│ Default │ FALSE   │
	   └────────────────────┴─────────┴─────────┘
	   Beginning with MySQL Cluster NDB 6.4.0, configuration data is
	   stored internally rather than being read from the cluster global
	   configuration file each time the management server is started (see
	   Section 17.3.2, “MySQL Cluster Configuration Files”). Using this
	   option forces the management server to check its internal data
	   store against the cluster configuration file and to reload the
	   configuration if it finds that the configuration file does not
	   match the cache. Existing configuration cache files are preserved,
	   but not used.

	   This differs in two ways from the --initial option. First,
	   --initial causes all cache files to be deleted. Second, --initial
	   forces the management server to re-read the global configuration
	   file and construct a new cache.

	   If the management server cannot find a global configuration file,
	   then the --reload option is ignored.

	   This option was introduced in MySQL Cluster NDB 6.4.0.

       ·   --nowait-nodes

	   ┌────────────────────┬─────────────────────┐
	   │Version Introduced	│ 5.1.39-ndb-7.1.0    │
	   ├────────────────────┼─────────────────────┤
	   │Command-Line Format │ --nowait-nodes=list │
	   ├────────────────────┼─────────────────────┤
	   │			│ Permitted Values    │
	   │			├──────────┬──────────┤
	   │			│ Type	   │ numeric  │
	   │			├──────────┼──────────┤
	   │			│ Default  │	      │
	   │			├──────────┼──────────┤
	   │			│ Range	   │ 1-255    │
	   └────────────────────┴──────────┴──────────┘
	   When starting a MySQL Cluster is configured with two management
	   nodes and running MySQL Cluster NDB 7.0 and later, each management
	   server normally checks to see whether the other ndb_mgmd is also
	   operational and whether the other management server´s configuration
	   is identical to its own. However, it is sometimes desirable to
	   start the cluster with only one management node (and perhaps to
	   allow the other ndb_mgmd to be started later). This option causes
	   the management node to bypass any checks for any other management
	   nodes whose node IDs are passed to this option, allowing the
	   cluster to start as though configured to use only the management
	   node that was started.

	   For purposes of illustration, consider the following portion of a
	   config.ini file (where we have omitted most of the configuration
	   parameters that are not relevant to this example):

	       [ndbd]
	       NodeId = 1
	       HostName = 192.168.0.101
	       [ndbd]
	       NodeId = 2
	       HostName = 192.168.0.102
	       [ndbd]
	       NodeId = 3
	       HostName = 192.168.0.103
	       [ndbd]
	       NodeId = 4
	       HostName = 192.168.0.104
	       [mgm]
	       NodeId = 10
	       HostName = 192.168.0.150
	       [mgm]
	       NodeId = 11
	       HostName = 192.168.0.151
	       [api]
	       NodeId = 20
	       HostName = 192.168.0.200
	       [api]
	       NodeId = 21
	       HostName = 192.168.0.201

	   Assume that you wish to start this cluster using only the
	   management server having node ID 10 and running on the host having
	   the IP address 192.168.0.150. (Suppose, for example, that the host
	   computer on which you intend to the other management server is
	   temporarily unavailable due to a hardware failure, and you are
	   waiting for it to be repaired.) To start the cluster in this way,
	   use a command line on the machine at 192.168.0.150 to enter the
	   following command:

	       shell> ndb_mgmd --ndb-nodeid=10 --nowait-nodes=11

	   As shown in the preceding example, when using --nowait-nodes, you
	   must also use the --ndb-nodeid option to specify the node ID of
	   this ndb_mgmd process.

	   You can then start each of the cluster´s data nodes in the usual
	   way. If you wish to start and use the second management server in
	   addition to the first management server at a later time without
	   restarting the data nodes, you must start each data node with a
	   connectstring that references both management servers, like this:

	       shell> ndbd -c 192.168.0.150,192.168.0.151

	   The same is true with regard to the connectstring used with any
	   mysqld processes that you wish to start as MySQL Cluster SQL nodes
	   connected to this cluster. See Section 17.3.2.3, “The MySQL Cluster
	   Connectstring”, for more information.

	   When used with ndb_mgmd, this option affects the behavior of the
	   management node with regard to other management nodes only. Do not
	   confuse it with the --nowait-nodes option used with ndbd (or ndbmtd
	   in MySQL Cluster NDB 7.0 and later) to allow a cluster to start
	   with fewer than its full complement of data nodes; when used with
	   data nodes, this option affects their behavior only with regard to
	   other data nodes.

	   Multiple management node IDs may be passed to this option as a
	   comma-separated list. Each node ID must be no less than 1 and no
	   greater than 255. In practice, it is quite rare to use more than
	   two management servers for the same MySQL Cluster (or to have any
	   need for doing so); in most cases you need to pass to this option
	   only the single node ID for the one management server that you do
	   not wish to use when starting the cluster.

	       Note
	       When you later start the “missing” management server, its
	       configuration must match that of the management server that is
	       already in use by the cluster. Otherwise, it fails the
	       configuration check performed by the existing management
	       server, and does not start.
	   This option was introduced in MySQL Cluster NDB 7.0.10.

       It is not strictly necessary to specify a connectstring when starting
       the management server. However, if you are using more than one
       management server, a connectstring should be provided and each node in
       the cluster should specify its node ID explicitly.

       See Section 17.3.2.3, “The MySQL Cluster Connectstring”, for
       information about using connectstrings.	ndb_mgmd(8), describes other
       options for ndb_mgmd.

       The following files are created or used by ndb_mgmd in its starting
       directory, and are placed in the DataDir as specified in the config.ini
       configuration file. In the list that follows, node_id is the unique
       node identifier.

       ·   config.ini is the configuration file for the cluster as a whole.
	   This file is created by the user and read by the management server.
	   Section 17.3, “MySQL Cluster Configuration”, discusses how to set
	   up this file.

       ·   ndb_node_id_cluster.log is the cluster events log file. Examples of
	   such events include checkpoint startup and completion, node startup
	   events, node failures, and levels of memory usage. A complete
	   listing of cluster events with descriptions may be found in
	   Section 17.5, “Management of MySQL Cluster”.

	   When the size of the cluster log reaches one million bytes, the
	   file is renamed to ndb_node_id_cluster.log.seq_id, where seq_id is
	   the sequence number of the cluster log file. (For example: If files
	   with the sequence numbers 1, 2, and 3 already exist, the next log
	   file is named using the number 4.)

       ·   ndb_node_id_out.log is the file used for stdout and stderr when
	   running the management server as a daemon.

       ·   ndb_node_id.pid is the process ID file used when running the
	   management server as a daemon.

COPYRIGHT
       Copyright © 2008, 2010, Oracle and/or its affiliates. All rights
       reserved.

       This documentation is free software; you can redistribute it and/or
       modify it only under the terms of the GNU General Public License as
       published by the Free Software Foundation; version 2 of the License.

       This documentation is distributed in the hope that it will be useful,
       but WITHOUT ANY WARRANTY; without even the implied warranty of
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
       General Public License for more details.

       You should have received a copy of the GNU General Public License along
       with the program; if not, write to the Free Software Foundation, Inc.,
       51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA or see
       http://www.gnu.org/licenses/.

NOTES
	1. Bug#45588
	   http://bugs.mysql.com/bug.php?id=45588

SEE ALSO
       For more information, please refer to the MySQL Reference Manual, which
       may already be installed locally and which is also available online at
       http://dev.mysql.com/doc/.

AUTHOR
       Oracle Corporation (http://dev.mysql.com/).

MySQL 5.1			  05/06/2010			   NDB_MGMD(8)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server NetBSD

List of man pages available for NetBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net