From: jon Date: January 27 2007 3:43am Subject: svn commit - mysqldoc@docsrva: r4673 - branches/telcos/refman-5.1 trunk/refman-4.1 trunk/refman-5.0 trunk/refman-5.1 List-Archive: http://lists.mysql.com/commits/18896 Message-Id: <200701270343.l0R3hog1024977@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Author: jstephens Date: 2007-01-27 04:43:48 +0100 (Sat, 27 Jan 2007) New Revision: 4673 Log: Reformat. Modified: branches/telcos/refman-5.1/mysql-cluster.xml trunk/refman-4.1/mysql-cluster.xml trunk/refman-5.0/mysql-cluster.xml trunk/refman-5.1/mysql-cluster.xml Modified: branches/telcos/refman-5.1/mysql-cluster.xml =================================================================== --- branches/telcos/refman-5.1/mysql-cluster.xml 2007-01-27 03:42:39 UTC (rev 4672) +++ branches/telcos/refman-5.1/mysql-cluster.xml 2007-01-27 03:43:48 UTC (rev 4673) Changed blocks: 14, Lines Added: 44, Lines Deleted: 41; 9836 bytes @@ -7851,8 +7851,7 @@ DataDir string - ./ - (ndb_mgmd directory) + ./ (ndb_mgmd directory) N/A N/A IN @@ -7885,7 +7884,8 @@ LogDestination CONSOLE, SYSLOG, or FILE - FILE (see ) + FILE (see + ) N/A N/A N @@ -10813,8 +10813,9 @@ MySQL Cluster provides two types of event log: - + + The cluster log, which includes @@ -10823,7 +10824,7 @@ logging information for an entire cluster in a single location. - + By default, the cluster log is saved to a file named ndb_node_id_cluster.log, @@ -10831,38 +10832,39 @@ the management server) in the same directory where the ndb_mgm binary resides. - + Cluster logging information can also be sent to stdout or a syslog facility in addition to or instead of being saved to a file, as determined by the values set for the DataDir and - LogDestination configuration parameters. - See , for - more information about these parameters. + LogDestination configuration parameters. + See , for more + information about these parameters. - + Node logs are local to each node. - + Output generated by node event logging is written to the file ndb_node_id_out.log (where node_id is the node's node ID) in the node's DataDir. Node event - logs are generated for both management nodes and data nodes. + logs are generated for both management nodes and data nodes. - + Node logs are intended to be used only during application development, or for debugging application code. + @@ -10923,11 +10925,11 @@ Both the cluster log and the node log can be filtered on these properties. - + The format used in the cluster log is as shown here: - + 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Data usage is 2%(60 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Index usage is 1%(24 8K pages of total 2336) @@ -10952,52 +10954,53 @@ 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected - + Each line in the cluster log contains the following information: - + + A timestamp in YYYY-MM-DD - HH:MM:SS - format. + HH:MM:SS + format. - + The type of node which is performing the logging. In the - cluster log, this is always [MgmSrvr]. + cluster log, this is always [MgmSrvr]. - + The severity of the event. - + The ID of the node reporting the event. - + A description of the event. The most common types of events - to appear in the log are connections and disconnections + to appear in the log are connections and disconnections between different nodes in the cluster, and when checkpoints occur. In some cases, the description may contain status information. + - - +
Logging Management Commands @@ -11167,10 +11170,10 @@ - + The STATISTICS category can provide a great - deal of useful data. See + deal of useful data. See , for more information. @@ -12162,13 +12165,13 @@ To cause all cluster log statistics to be logged, you can use the following command in the NDB management - client: + client: ndb_mgm> ALL CLUSTERLOG STATISTICS=15 - + Note: Setting the threshold for STATISTICS to 15 causes the cluster log @@ -12201,7 +12204,7 @@ instance of ndb_restore. When entering single user mode, connections to all other API nodes are closed gracefully and all running transactions are aborted. No new - transactions are permitted to start. + transactions are permitted to start. @@ -12692,7 +12695,7 @@ ndb_restore - + The cluster restoration program is implemented as a separate command-line utility ndb_restore, which can @@ -12700,17 +12703,17 @@ directory. This program reads the files created as a result of the backup and inserts the stored information into the database. - + ndb_restore must be executed N + 1 times, where N is the number of backup files that were created by the START BACKUP command used - to create the backup (see + to create the backup (see ). This is equal to once for restoring cluster metadata (table - schemas), plus once for each data node in the cluster at - the time that the backup was created. + schemas), plus once for each data node in the cluster at the + time that the backup was created. @@ -12750,8 +12753,8 @@ that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty [API] or - [MYSQLD] section in - config.ini that is not being used for a + [MYSQLD] section in + config.ini that is not being used for a MySQL server or other application for this reason (see ). @@ -12823,11 +12826,11 @@ restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster connections available. That is, when restoring to multiple nodes in parallel, you must - have an [API] or [MYSQLD] + have an [API] or [MYSQLD] section in the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied before - the logs. + the logs. Modified: trunk/refman-4.1/mysql-cluster.xml =================================================================== --- trunk/refman-4.1/mysql-cluster.xml 2007-01-27 03:42:39 UTC (rev 4672) +++ trunk/refman-4.1/mysql-cluster.xml 2007-01-27 03:43:48 UTC (rev 4673) Changed blocks: 17, Lines Added: 74, Lines Deleted: 71; 14515 bytes @@ -7741,8 +7741,7 @@ DataDir string - ./ - (ndb_mgmd directory) + ./ (ndb_mgmd directory) N/A N/A IN @@ -7775,7 +7774,8 @@ LogDestination CONSOLE, SYSLOG, or FILE - FILE (see ) + FILE (see + ) N/A N/A N @@ -10582,17 +10582,18 @@ MySQL Cluster node logs - + In this section, we discuss the types of event logs provided by MySQL Cluster, and the types of events that are logged. - + MySQL Cluster provides two types of event log: - + + The cluster log, which includes @@ -10601,7 +10602,7 @@ logging information for an entire cluster in a single location. - + By default, the cluster log is saved to a file named ndb_node_id_cluster.log, @@ -10609,61 +10610,62 @@ the management server) in the same directory where the ndb_mgm binary resides. - + Cluster logging information can also be sent to stdout or a syslog facility in addition to or instead of being saved to a file, as determined by the values set for the DataDir and - LogDestination configuration parameters. - See , for - more information about these parameters. + LogDestination configuration parameters. + See , for more + information about these parameters. - + Node logs are local to each node. - + Output generated by node event logging is written to the file ndb_node_id_out.log (where node_id is the node's node ID) in the node's DataDir. Node event - logs are generated for both management nodes and data nodes. + logs are generated for both management nodes and data nodes. - + Node logs are intended to be used only during application development, or for debugging application code. + - + Both types of event logs can be set to log different subsets of events. - + Each reportable event can be distinguished according to three different criteria: - + MySQL Cluster event types - + event types (MySQL Cluster) - + - + Category: This can be any one of the @@ -10675,16 +10677,16 @@ INFO. - + Priority: This is represented by one of the numbers from 1 to 15 inclusive, where 1 indicates most important and 15 least - important. + important. - + Severity Level: This can be any one of @@ -10694,19 +10696,19 @@ DEBUG. - + - + Both the cluster log and the node log can be filtered on these properties. - + The format used in the cluster log is as shown here: - - + + 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Data usage is 2%(60 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Index usage is 1%(24 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Resource 0 min: 0 max: 639 curr: 0 @@ -10730,49 +10732,51 @@ 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected - + Each line in the cluster log contains the following information: - + + A timestamp in YYYY-MM-DD - HH:MM:SS - format. + HH:MM:SS + format. - + The type of node which is performing the logging. In the - cluster log, this is always [MgmSrvr]. + cluster log, this is always [MgmSrvr]. - + The severity of the event. - + The ID of the node reporting the event. - + A description of the event. The most common types of events - to appear in the log are connections and disconnections + to appear in the log are connections and disconnections between different nodes in the cluster, and when checkpoints occur. In some cases, the description may contain status information. +
@@ -10878,10 +10882,10 @@ - + The STATISTICS category can provide a great - deal of useful data. See + deal of useful data. See , for more information. @@ -11935,17 +11939,17 @@ These values are given in bytes. Higher values mean a lower cost per byte sent or received; the maximum is 64k. - + To cause all cluster log statistics to be logged, you can use the following command in the NDB management - client: + client: - + ndb_mgm> ALL CLUSTERLOG STATISTICS=15 - + Note: Setting the threshold for STATISTICS to 15 causes the cluster log @@ -11970,7 +11974,7 @@ single user mode (MySQL Cluster) - + Single user mode allows the database administrator to restrict access to the database system to a @@ -11978,45 +11982,45 @@ instance of ndb_restore. When entering single user mode, connections to all other API nodes are closed gracefully and all running transactions are aborted. No new - transactions are permitted to start. + transactions are permitted to start. - + Once the cluster has entered single user mode, only the designated API node is granted access to the database. - + You can use the ALL STATUS command to see when the cluster has entered single user mode. - + Example: - + ndb_mgm> ENTER SINGLE USER MODE 5 - + After this command has executed and the cluster has entered single user mode, the API node whose node ID is 5 becomes the cluster's only permitted user. - + The node specified in the preceding command must be an API node; attempting to specify any other type of node will be rejected. - + Note: When the preceding commmand is invoked, all transactions running on the designated node are aborted, the connection is closed, and the server must be restarted. - + The command EXIT SINGLE USER MODE changes the state of the cluster's data nodes from single user mode to @@ -12026,15 +12030,14 @@ API node denoted as the single-user node continues to run (if still connected) during and after the state change. - + Example: - + ndb_mgm> EXIT SINGLE USER MODE - MySQL Cluster @@ -12470,32 +12473,32 @@ ndb_restore - + The cluster restoration program is implemented as a separate command-line utility ndb_restore, which can normally be found in the MySQL bin directory. This program reads the files created as a result of the backup and inserts the stored information into the database. - - + + ndb_restore must be executed N + 1 times, where N is the number of backup files that were created by the START BACKUP command used - to create the backup (see + to create the backup (see ). This is equal to once for restoring cluster metadata (table - schemas), plus once for each data node in the cluster at - the time that the backup was created. + schemas), plus once for each data node in the cluster at the + time that the backup was created. single user mode (MySQL Cluster) and ndb_restore - + Note: Before using ndb_restore, it is recommended that the @@ -12512,7 +12515,7 @@ ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r /path/to/backup/files - + The option is used to specify a connectstring which tells ndb_restore where @@ -12528,8 +12531,8 @@ that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty [API] or - [MYSQLD] section in - config.ini that is not being used for a + [MYSQLD] section in + config.ini that is not being used for a MySQL server or other application for this reason (see ). @@ -12593,17 +12596,17 @@ , for more information. - + Note: For more rapid restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster connections available. That is, when restoring to multiple nodes in parallel, you must - have an [API] or [MYSQLD] + have an [API] or [MYSQLD] section in the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied before - the logs. + the logs. Modified: trunk/refman-5.0/mysql-cluster.xml =================================================================== --- trunk/refman-5.0/mysql-cluster.xml 2007-01-27 03:42:39 UTC (rev 4672) +++ trunk/refman-5.0/mysql-cluster.xml 2007-01-27 03:43:48 UTC (rev 4673) Changed blocks: 18, Lines Added: 73, Lines Deleted: 70; 14473 bytes @@ -7773,8 +7773,7 @@ DataDir string - ./ - (ndb_mgmd directory) + ./ (ndb_mgmd directory) N/A N/A IN @@ -7807,7 +7806,8 @@ LogDestination CONSOLE, SYSLOG, or FILE - FILE (see ) + FILE (see + ) N/A N/A N @@ -10695,17 +10695,18 @@ MySQL Cluster node logs - + In this section, we discuss the types of event logs provided by MySQL Cluster, and the types of events that are logged. - + MySQL Cluster provides two types of event log: - + + The cluster log, which includes @@ -10714,7 +10715,7 @@ logging information for an entire cluster in a single location. - + By default, the cluster log is saved to a file named ndb_node_id_cluster.log, @@ -10722,61 +10723,62 @@ the management server) in the same directory where the ndb_mgm binary resides. - + Cluster logging information can also be sent to stdout or a syslog facility in addition to or instead of being saved to a file, as determined by the values set for the DataDir and - LogDestination configuration parameters. - See , for - more information about these parameters. + LogDestination configuration parameters. + See , for more + information about these parameters. - + Node logs are local to each node. - + Output generated by node event logging is written to the file ndb_node_id_out.log (where node_id is the node's node ID) in the node's DataDir. Node event - logs are generated for both management nodes and data nodes. + logs are generated for both management nodes and data nodes. - + Node logs are intended to be used only during application development, or for debugging application code. + - + Both types of event logs can be set to log different subsets of events. - + Each reportable event can be distinguished according to three different criteria: - + MySQL Cluster event types - + event types (MySQL Cluster) - + - + Category: This can be any one of the @@ -10788,16 +10790,16 @@ INFO. - + Priority: This is represented by one of the numbers from 1 to 15 inclusive, where 1 indicates most important and 15 least - important. + important. - + Severity Level: This can be any one of @@ -10807,19 +10809,19 @@ DEBUG. - + - + Both the cluster log and the node log can be filtered on these properties. - + The format used in the cluster log is as shown here: - - + + 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Data usage is 2%(60 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Index usage is 1%(24 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Resource 0 min: 0 max: 639 curr: 0 @@ -10843,49 +10845,51 @@ 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected - + Each line in the cluster log contains the following information: - + + A timestamp in YYYY-MM-DD - HH:MM:SS - format. + HH:MM:SS + format. - + The type of node which is performing the logging. In the - cluster log, this is always [MgmSrvr]. + cluster log, this is always [MgmSrvr]. - + The severity of the event. - + The ID of the node reporting the event. - + A description of the event. The most common types of events - to appear in the log are connections and disconnections + to appear in the log are connections and disconnections between different nodes in the cluster, and when checkpoints occur. In some cases, the description may contain status information. +
@@ -11057,10 +11061,10 @@ - + The STATISTICS category can provide a great - deal of useful data. See + deal of useful data. See , for more information. @@ -12048,17 +12052,17 @@ These values are given in bytes. Higher values mean a lower cost per byte sent or received; the maximum is 64k. - + To cause all cluster log statistics to be logged, you can use the following command in the NDB management - client: + client: - + ndb_mgm> ALL CLUSTERLOG STATISTICS=15 - + Note: Setting the threshold for STATISTICS to 15 causes the cluster log @@ -12083,7 +12087,7 @@ single user mode (MySQL Cluster) - + Single user mode allows the database administrator to restrict access to the database system to a @@ -12091,45 +12095,45 @@ instance of ndb_restore. When entering single user mode, connections to all other API nodes are closed gracefully and all running transactions are aborted. No new - transactions are permitted to start. + transactions are permitted to start. - + Once the cluster has entered single user mode, only the designated API node is granted access to the database. - + You can use the ALL STATUS command to see when the cluster has entered single user mode. - + Example: - + ndb_mgm> ENTER SINGLE USER MODE 5 - + After this command has executed and the cluster has entered single user mode, the API node whose node ID is 5 becomes the cluster's only permitted user. - + The node specified in the preceding command must be an API node; attempting to specify any other type of node will be rejected. - + Note: When the preceding commmand is invoked, all transactions running on the designated node are aborted, the connection is closed, and the server must be restarted. - + The command EXIT SINGLE USER MODE changes the state of the cluster's data nodes from single user mode to @@ -12139,15 +12143,14 @@ API node denoted as the single-user node continues to run (if still connected) during and after the state change. - + Example: - + ndb_mgm> EXIT SINGLE USER MODE - MySQL Cluster @@ -12583,7 +12586,7 @@ ndb_restore - + The cluster restoration program is implemented as a separate command-line utility ndb_restore, which can @@ -12591,24 +12594,24 @@ directory. This program reads the files created as a result of the backup and inserts the stored information into the database. - + ndb_restore must be executed N + 1 times, where N is the number of backup files that were created by the START BACKUP command used - to create the backup (see + to create the backup (see ). This is equal to once for restoring cluster metadata (table - schemas), plus once for each data node in the cluster at - the time that the backup was created. + schemas), plus once for each data node in the cluster at the + time that the backup was created. single user mode (MySQL Cluster) and ndb_restore - + Note: Before using ndb_restore, it is recommended that the @@ -12625,7 +12628,7 @@ ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r /path/to/backup/files - + The option is used to specify a connectstring which tells ndb_restore where @@ -12641,8 +12644,8 @@ that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty [API] or - [MYSQLD] section in - config.ini that is not being used for a + [MYSQLD] section in + config.ini that is not being used for a MySQL server or other application for this reason (see ). @@ -12706,17 +12709,17 @@ , for more information. - + Note: For more rapid restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster connections available. That is, when restoring to multiple nodes in parallel, you must - have an [API] or [MYSQLD] + have an [API] or [MYSQLD] section in the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied before - the logs. + the logs. Modified: trunk/refman-5.1/mysql-cluster.xml =================================================================== --- trunk/refman-5.1/mysql-cluster.xml 2007-01-27 03:42:39 UTC (rev 4672) +++ trunk/refman-5.1/mysql-cluster.xml 2007-01-27 03:43:48 UTC (rev 4673) Changed blocks: 18, Lines Added: 74, Lines Deleted: 70; 14536 bytes @@ -7795,8 +7795,7 @@ DataDir string - ./ - (ndb_mgmd directory) + ./ (ndb_mgmd directory) N/A N/A IN @@ -7829,7 +7828,8 @@ LogDestination CONSOLE, SYSLOG, or FILE - FILE (see ) + FILE (see + ) N/A N/A N @@ -10748,17 +10748,18 @@ MySQL Cluster node logs - + In this section, we discuss the types of event logs provided by MySQL Cluster, and the types of events that are logged. - + MySQL Cluster provides two types of event log: - + + The cluster log, which includes @@ -10767,7 +10768,7 @@ logging information for an entire cluster in a single location. - + By default, the cluster log is saved to a file named ndb_node_id_cluster.log, @@ -10775,61 +10776,62 @@ the management server) in the same directory where the ndb_mgm binary resides. - + Cluster logging information can also be sent to stdout or a syslog facility in addition to or instead of being saved to a file, as determined by the values set for the DataDir and - LogDestination configuration parameters. - See , for - more information about these parameters. + LogDestination configuration parameters. + See , for more + information about these parameters. - + Node logs are local to each node. - + Output generated by node event logging is written to the file ndb_node_id_out.log (where node_id is the node's node ID) in the node's DataDir. Node event - logs are generated for both management nodes and data nodes. + logs are generated for both management nodes and data nodes. - + Node logs are intended to be used only during application development, or for debugging application code. + - + Both types of event logs can be set to log different subsets of events. - + Each reportable event can be distinguished according to three different criteria: - + MySQL Cluster event types - + event types (MySQL Cluster) - + - + Category: This can be any one of the @@ -10841,16 +10843,16 @@ INFO. - + Priority: This is represented by one of the numbers from 1 to 15 inclusive, where 1 indicates most important and 15 least - important. + important. - + Severity Level: This can be any one of @@ -10860,19 +10862,19 @@ DEBUG. - + - + Both the cluster log and the node log can be filtered on these properties. - + The format used in the cluster log is as shown here: - - + + 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Data usage is 2%(60 32K pages of total 2560) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Index usage is 1%(24 8K pages of total 2336) 2007-01-26 19:35:55 [MgmSrvr] INFO -- Node 1: Resource 0 min: 0 max: 639 curr: 0 @@ -10896,49 +10898,51 @@ 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected 2007-01-26 19:59:22 [MgmSrvr] ALERT -- Node 2: Node 7 Disconnected - + Each line in the cluster log contains the following information: - + + A timestamp in YYYY-MM-DD - HH:MM:SS - format. + HH:MM:SS + format. - + The type of node which is performing the logging. In the - cluster log, this is always [MgmSrvr]. + cluster log, this is always [MgmSrvr]. - + The severity of the event. - + The ID of the node reporting the event. - + A description of the event. The most common types of events - to appear in the log are connections and disconnections + to appear in the log are connections and disconnections between different nodes in the cluster, and when checkpoints occur. In some cases, the description may contain status information. +
@@ -11110,10 +11114,10 @@ - + The STATISTICS category can provide a great - deal of useful data. See + deal of useful data. See , for more information. @@ -12101,17 +12105,17 @@ These values are given in bytes. Higher values mean a lower cost per byte sent or received; the maximum is 64k. - + To cause all cluster log statistics to be logged, you can use the following command in the NDB management - client: + client: - + ndb_mgm> ALL CLUSTERLOG STATISTICS=15 - + Note: Setting the threshold for STATISTICS to 15 causes the cluster log @@ -12136,7 +12140,7 @@ single user mode (MySQL Cluster) - + Single user mode allows the database administrator to restrict access to the database system to a @@ -12144,45 +12148,45 @@ instance of ndb_restore. When entering single user mode, connections to all other API nodes are closed gracefully and all running transactions are aborted. No new - transactions are permitted to start. + transactions are permitted to start. - + Once the cluster has entered single user mode, only the designated API node is granted access to the database. - + You can use the ALL STATUS command to see when the cluster has entered single user mode. - + Example: - + ndb_mgm> ENTER SINGLE USER MODE 5 - + After this command has executed and the cluster has entered single user mode, the API node whose node ID is 5 becomes the cluster's only permitted user. - + The node specified in the preceding command must be an API node; attempting to specify any other type of node will be rejected. - + Note: When the preceding commmand is invoked, all transactions running on the designated node are aborted, the connection is closed, and the server must be restarted. - + The command EXIT SINGLE USER MODE changes the state of the cluster's data nodes from single user mode to @@ -12192,15 +12196,15 @@ API node denoted as the single-user node continues to run (if still connected) during and after the state change. - + Example: - + ndb_mgm> EXIT SINGLE USER MODE - + MySQL Cluster node failure (single user mode) @@ -12635,7 +12639,7 @@ ndb_restore - + The cluster restoration program is implemented as a separate command-line utility ndb_restore, which can @@ -12643,24 +12647,24 @@ directory. This program reads the files created as a result of the backup and inserts the stored information into the database. - + ndb_restore must be executed N + 1 times, where N is the number of backup files that were created by the START BACKUP command used - to create the backup (see + to create the backup (see ). This is equal to once for restoring cluster metadata (table - schemas), plus once for each data node in the cluster at - the time that the backup was created. + schemas), plus once for each data node in the cluster at the + time that the backup was created. single user mode (MySQL Cluster) and ndb_restore - + Note: Before using ndb_restore, it is recommended that the @@ -12677,7 +12681,7 @@ ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r /path/to/backup/files - + The option is used to specify a connectstring which tells ndb_restore where @@ -12693,8 +12697,8 @@ that can be used by it in the cluster config.ini file. It is a good idea to keep at least one empty [API] or - [MYSQLD] section in - config.ini that is not being used for a + [MYSQLD] section in + config.ini that is not being used for a MySQL server or other application for this reason (see ). @@ -12760,17 +12764,17 @@ , for more information. - + Note: For more rapid restoration, the data may be restored in parallel, provided that there is a sufficient number of cluster connections available. That is, when restoring to multiple nodes in parallel, you must - have an [API] or [MYSQLD] + have an [API] or [MYSQLD] section in the cluster config.ini file available for each concurrent ndb_restore process. However, the data files must always be applied before - the logs. + the logs.