Author: jstephens
Date: 2007-01-25 13:24:15 +0100 (Thu, 25 Jan 2007)
New Revision: 4632
Log:
Fixes Docs Bug #24466.
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-25 08:20:38 UTC (rev 4631)
+++ branches/telcos/refman-5.1/mysql-cluster.xml 2007-01-25 12:24:15 UTC (rev 4632)
Changed blocks: 2, Lines Added: 119, Lines Deleted: 64; 10907 bytes
@@ -12324,92 +12324,111 @@
</section>
<section id="mysql-cluster-backup-using-management-client">
-
+
<title>Using The Management Client to Create a Backup</title>
-
+
<indexterm>
<primary>MySQL Cluster</primary>
<secondary>backups</secondary>
</indexterm>
-
+
<indexterm>
<primary>backups</primary>
<secondary>in MySQL Cluster</secondary>
</indexterm>
-
+
<para>
Before starting a backup, make sure that the cluster is properly
configured for performing one. (See
<xref linkend="mysql-cluster-backup-configuration"/>.)
</para>
-
+
<para>
Creating a backup using the management client involves the
following steps:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client (<command>ndb_mgm</command>).
</para>
</listitem>
-
+
<listitem>
<indexterm>
<primary>MySQL Cluster</primary>
<secondary><literal>START BACKUP</literal> command</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>START BACKUP</literal> command (MySQL Cluster)</primary>
</indexterm>
-
+
<para>
Execute the command <literal>START BACKUP</literal>.
</para>
</listitem>
-
+
<listitem>
<para>
- The management client will reply with the message
- <literal>Start of backup ordered</literal>. This means that
- the management client has submitted the request to the
- cluster, but has not yet received any response.
+ The management client responds as shown here:
</para>
- </listitem>
-
- <listitem>
+
+ <programlisting>
+Waiting for completed, this may take several minutes
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable>
+</programlisting>
+
<para>
- The management client will reply <literal>Backup
- <replaceable>backup_id</replaceable> started</literal>,
- where <replaceable>backup_id</replaceable> is the unique
+ Here, <replaceable>backup_id</replaceable> is the unique
identifier for this particular backup. (This identifier will
also be saved in the cluster log, if it has not been
- configured otherwise.) This means that the cluster has
- received and processed the backup request. It does
- <emphasis>not</emphasis> mean that the backup has finished.
+ configured otherwise.)
+ <replaceable>management_node_id</replaceable> is the node ID
+ of the management to which the management client is
+ connected.
</para>
-
+
<para>
+ This means that the cluster has received and processed the
+ backup request. It does <emphasis>not</emphasis> mean that
+ the backup has been completed.
+ </para>
+
+ <para>
<emphasis role="bold">Note</emphasis>: Backup messages were
not recorded in the cluster log in MySQL 5.1.12 or 5.1.13.
The logging of backup operations was restored in MySQL
5.1.14 (see Bug #24544).
</para>
</listitem>
-
+
<listitem>
<para>
- The management client will signal that the backup is
- finished with the message <literal>Backup
- <replaceable>backup_id</replaceable> completed</literal>.
+ When the backup is completed, the management client will
+ indicate this as shown here:
</para>
+
+ <programlisting>
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable> completed
+ StartGCP: 417599 StopGCP: 417602
+ #Records: 105957 #LogRecords: 0
+ Data: 99719356 bytes Log: 0 bytes
+</programlisting>
+
+ <para>
+ The values shown for <literal>StartGCP</literal>,
+ <literal>StopGCP</literal>, <literal>#Records</literal>,
+ <literal>#LogRecords</literal>, <literal>Data</literal>, and
+ <literal>Log</literal> will vary according to the specifics
+ of your cluster.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
Cluster backups are created by default in the
<filename>BACKUP</filename> subdirectory of the
@@ -12419,77 +12438,113 @@
using the <literal>BackupDataDir</literal> configuration
parameter as discussed in
<link linkend="mysql-cluster-identifying-data-nodes">Identifying
- Data Nodes</link>. The backup files created for a backup with a
+ Data Nodes</link>. The backup files created for a backup with a
given <replaceable>backup_id</replaceable> are stored in a
subdirectory named
<filename>BACKUP-<replaceable>backup_id</replaceable></filename>
in the backup directory.
</para>
-
+
<para>
To abort a backup that is already in progress:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client.
</para>
</listitem>
-
+
<listitem>
<para>
- Execute the command <literal>ABORT BACKUP
- <replaceable>backup_id</replaceable></literal>. The number
- <replaceable>backup_id</replaceable> is the identifier of
- the backup that was included in the response of the
- management client when the backup was started (in the
+ Execute this command:
+ </para>
+
+ <programlisting>
+ndb_mgm> <userinput>ABORT BACKUP <replaceable>backup_id</replaceable></userinput>
+</programlisting>
+
+ <para>The number <replaceable>backup_id</replaceable> is the
+ identifier of the backup that was included in the response
+ of the management client when the backup was started (in the
message <literal>Backup <replaceable>backup_id</replaceable>
- started</literal>).
+ started from node
+ <replaceable>management_node_id</replaceable></literal>).
</para>
</listitem>
-
+
<listitem>
<para>
The management client will acknowledge the abort request
with <literal>Abort of backup
- <replaceable>backup_id</replaceable> ordered</literal>; note
- that it has received no actual response to this request yet.
+ <replaceable>backup_id</replaceable> ordered</literal>.
+ <emphasis role="bold">Note</emphasis>: At this point, the
+ management client has not yet received a response from the
+ cluster data nodes to this request, and the backup has not
+ yet actually been aborted.
</para>
</listitem>
-
+
<listitem>
<para>
After the backup has been aborted, the management client
- will report <literal>Backup
- <replaceable>backup_id</replaceable> has been aborted for
- reason <replaceable>XYZ</replaceable></literal>. This means
- that the cluster has terminated the backup and that all
- files related to this backup have been removed from the
- cluster filesystem.
+ will report this fact in a manner similar to what is shown
+ here:
</para>
+
+ <programlisting>
+Node 1: Backup 3 started from 5 has been aborted. Error: 1321 - Backup aborted by user request: Permanent error: User defined error
+Node 3: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 2: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 4: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+</programlisting>
+
+ <para>
+ In this example, we have shown sample output for a cluster
+ with 4 data nodes, where the sequence number of the backup
+ to be aborted is <literal>3</literal>, and the management
+ node to which the cluster management client is connected has
+ the node ID <literal>5</literal>. The first node to complete
+ its part in aborting the backup reports that the reason for
+ the abort was due to a request by the user. (The remaining
+ nodes report that the backup was aborted due to an
+ unspecified internal error.)
+ <emphasis role="bold">Note</emphasis>: There is no guarantee
+ that the cluster nodes will respond to an <literal>ABORT
+ BACKUP</literal> command in any particular order.
+ </para>
+
+ <para>
+ The <literal>Backup <replaceable>backup_id</replaceable>
+ started from node
+ <replaceable>management_node_id</replaceable> has been
+ aborted</literal> messages mean that the backup has been
+ terminated and that all files relating to this backup have
+ been removed from the cluster filesystem.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
- It is also possible to abort a backup in progress from the
- system shell using this command:
+ It is also possible to abort a backup in progress from a system
+ shell using this command:
</para>
-
-<programlisting>
+
+ <programlisting>
shell> <userinput>ndb_mgm -e "ABORT BACKUP <replaceable>backup_id</replaceable>"</userinput>
</programlisting>
-
+
<para>
<emphasis role="bold">Note</emphasis>: If there is no backup
- with ID <replaceable>backup_id</replaceable> running when it is
- aborted, the management client makes no explicit response.
- However, the fact that an invalid abort command was sent is
- indicated in the cluster log.
+ with ID <replaceable>backup_id</replaceable> running when an
+ <literal>ABORT BACKUP</literal> is issued, the management client
+ makes no response, nor is it indicated in the cluster log that
+ an invalid abort command was sent.
</para>
-
+
</section>
<section id="mysql-cluster-restore">
Modified: trunk/refman-4.1/mysql-cluster.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster.xml 2007-01-25 08:20:38 UTC (rev 4631)
+++ trunk/refman-4.1/mysql-cluster.xml 2007-01-25 12:24:15 UTC (rev 4632)
Changed blocks: 2, Lines Added: 125, Lines Deleted: 63; 10876 bytes
@@ -12105,85 +12105,111 @@
</section>
<section id="mysql-cluster-backup-using-management-client">
-
+
<title>Using The Management Client to Create a Backup</title>
-
+
<indexterm>
<primary>MySQL Cluster</primary>
<secondary>backups</secondary>
</indexterm>
-
+
<indexterm>
<primary>backups</primary>
<secondary>in MySQL Cluster</secondary>
</indexterm>
-
+
<para>
Before starting a backup, make sure that the cluster is properly
configured for performing one. (See
<xref linkend="mysql-cluster-backup-configuration"/>.)
</para>
-
+
<para>
Creating a backup using the management client involves the
following steps:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client (<command>ndb_mgm</command>).
</para>
</listitem>
-
+
<listitem>
<indexterm>
<primary>MySQL Cluster</primary>
<secondary><literal>START BACKUP</literal> command</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>START BACKUP</literal> command (MySQL Cluster)</primary>
</indexterm>
-
+
<para>
Execute the command <literal>START BACKUP</literal>.
</para>
</listitem>
-
+
<listitem>
<para>
- The management client will reply with the message
- <literal>Start of backup ordered</literal>. This means that
- the management client has submitted the request to the
- cluster, but has not yet received any response.
+ The management client responds as shown here:
</para>
- </listitem>
-
- <listitem>
+
+ <programlisting>
+Waiting for completed, this may take several minutes
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable>
+</programlisting>
+
<para>
- The management client will reply <literal>Backup
- <replaceable>backup_id</replaceable> started</literal>,
- where <replaceable>backup_id</replaceable> is the unique
+ Here, <replaceable>backup_id</replaceable> is the unique
identifier for this particular backup. (This identifier will
also be saved in the cluster log, if it has not been
- configured otherwise.) This means that the cluster has
- received and processed the backup request. It does
- <emphasis>not</emphasis> mean that the backup has finished.
+ configured otherwise.)
+ <replaceable>management_node_id</replaceable> is the node ID
+ of the management to which the management client is
+ connected.
</para>
+
+ <para>
+ This means that the cluster has received and processed the
+ backup request. It does <emphasis>not</emphasis> mean that
+ the backup has been completed.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Backup messages were
+ not recorded in the cluster log in MySQL 5.1.12 or 5.1.13.
+ The logging of backup operations was restored in MySQL
+ 5.1.14 (see Bug #24544).
+ </para>
</listitem>
-
+
<listitem>
<para>
- The management client will signal that the backup is
- finished with the message <literal>Backup
- <replaceable>backup_id</replaceable> completed</literal>.
+ When the backup is completed, the management client will
+ indicate this as shown here:
</para>
+
+ <programlisting>
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable> completed
+ StartGCP: 417599 StopGCP: 417602
+ #Records: 105957 #LogRecords: 0
+ Data: 99719356 bytes Log: 0 bytes
+</programlisting>
+
+ <para>
+ The values shown for <literal>StartGCP</literal>,
+ <literal>StopGCP</literal>, <literal>#Records</literal>,
+ <literal>#LogRecords</literal>, <literal>Data</literal>, and
+ <literal>Log</literal> will vary according to the specifics
+ of your cluster.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
Cluster backups are created by default in the
<filename>BACKUP</filename> subdirectory of the
@@ -12193,77 +12219,113 @@
using the <literal>BackupDataDir</literal> configuration
parameter as discussed in
<link linkend="mysql-cluster-identifying-data-nodes">Identifying
- Data Nodes</link>. The backup files created for a backup with a
+ Data Nodes</link>. The backup files created for a backup with a
given <replaceable>backup_id</replaceable> are stored in a
subdirectory named
<filename>BACKUP-<replaceable>backup_id</replaceable></filename>
in the backup directory.
</para>
-
+
<para>
To abort a backup that is already in progress:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client.
</para>
</listitem>
-
+
<listitem>
<para>
- Execute the command <literal>ABORT BACKUP
- <replaceable>backup_id</replaceable></literal>. The number
- <replaceable>backup_id</replaceable> is the identifier of
- the backup that was included in the response of the
- management client when the backup was started (in the
+ Execute this command:
+ </para>
+
+ <programlisting>
+ndb_mgm> <userinput>ABORT BACKUP <replaceable>backup_id</replaceable></userinput>
+</programlisting>
+
+ <para>The number <replaceable>backup_id</replaceable> is the
+ identifier of the backup that was included in the response
+ of the management client when the backup was started (in the
message <literal>Backup <replaceable>backup_id</replaceable>
- started</literal>).
+ started from node
+ <replaceable>management_node_id</replaceable></literal>).
</para>
</listitem>
-
+
<listitem>
<para>
The management client will acknowledge the abort request
with <literal>Abort of backup
- <replaceable>backup_id</replaceable> ordered</literal>; note
- that it has received no actual response to this request yet.
+ <replaceable>backup_id</replaceable> ordered</literal>.
+ <emphasis role="bold">Note</emphasis>: At this point, the
+ management client has not yet received a response from the
+ cluster data nodes to this request, and the backup has not
+ yet actually been aborted.
</para>
</listitem>
-
+
<listitem>
<para>
After the backup has been aborted, the management client
- will report <literal>Backup
- <replaceable>backup_id</replaceable> has been aborted for
- reason <replaceable>XYZ</replaceable></literal>. This means
- that the cluster has terminated the backup and that all
- files related to this backup have been removed from the
- cluster filesystem.
+ will report this fact in a manner similar to what is shown
+ here:
</para>
+
+ <programlisting>
+Node 1: Backup 3 started from 5 has been aborted. Error: 1321 - Backup aborted by user request: Permanent error: User defined error
+Node 3: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 2: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 4: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+</programlisting>
+
+ <para>
+ In this example, we have shown sample output for a cluster
+ with 4 data nodes, where the sequence number of the backup
+ to be aborted is <literal>3</literal>, and the management
+ node to which the cluster management client is connected has
+ the node ID <literal>5</literal>. The first node to complete
+ its part in aborting the backup reports that the reason for
+ the abort was due to a request by the user. (The remaining
+ nodes report that the backup was aborted due to an
+ unspecified internal error.)
+ <emphasis role="bold">Note</emphasis>: There is no guarantee
+ that the cluster nodes will respond to an <literal>ABORT
+ BACKUP</literal> command in any particular order.
+ </para>
+
+ <para>
+ The <literal>Backup <replaceable>backup_id</replaceable>
+ started from node
+ <replaceable>management_node_id</replaceable> has been
+ aborted</literal> messages mean that the backup has been
+ terminated and that all files relating to this backup have
+ been removed from the cluster filesystem.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
- It is also possible to abort a backup in progress from the
- system shell using this command:
+ It is also possible to abort a backup in progress from a system
+ shell using this command:
</para>
-
-<programlisting>
+
+ <programlisting>
shell> <userinput>ndb_mgm -e "ABORT BACKUP <replaceable>backup_id</replaceable>"</userinput>
</programlisting>
-
+
<para>
<emphasis role="bold">Note</emphasis>: If there is no backup
- with ID <replaceable>backup_id</replaceable> running when it is
- aborted, the management client makes no explicit response.
- However, the fact that an invalid abort command was sent is
- indicated in the cluster log.
+ with ID <replaceable>backup_id</replaceable> running when an
+ <literal>ABORT BACKUP</literal> is issued, the management client
+ makes no response, nor is it indicated in the cluster log that
+ an invalid abort command was sent.
</para>
-
+
</section>
<section id="mysql-cluster-restore">
Modified: trunk/refman-5.0/mysql-cluster.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster.xml 2007-01-25 08:20:38 UTC (rev 4631)
+++ trunk/refman-5.0/mysql-cluster.xml 2007-01-25 12:24:15 UTC (rev 4632)
Changed blocks: 2, Lines Added: 125, Lines Deleted: 63; 10876 bytes
@@ -12213,85 +12213,111 @@
</section>
<section id="mysql-cluster-backup-using-management-client">
-
+
<title>Using The Management Client to Create a Backup</title>
-
+
<indexterm>
<primary>MySQL Cluster</primary>
<secondary>backups</secondary>
</indexterm>
-
+
<indexterm>
<primary>backups</primary>
<secondary>in MySQL Cluster</secondary>
</indexterm>
-
+
<para>
Before starting a backup, make sure that the cluster is properly
configured for performing one. (See
<xref linkend="mysql-cluster-backup-configuration"/>.)
</para>
-
+
<para>
Creating a backup using the management client involves the
following steps:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client (<command>ndb_mgm</command>).
</para>
</listitem>
-
+
<listitem>
<indexterm>
<primary>MySQL Cluster</primary>
<secondary><literal>START BACKUP</literal> command</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>START BACKUP</literal> command (MySQL Cluster)</primary>
</indexterm>
-
+
<para>
Execute the command <literal>START BACKUP</literal>.
</para>
</listitem>
-
+
<listitem>
<para>
- The management client will reply with the message
- <literal>Start of backup ordered</literal>. This means that
- the management client has submitted the request to the
- cluster, but has not yet received any response.
+ The management client responds as shown here:
</para>
- </listitem>
-
- <listitem>
+
+ <programlisting>
+Waiting for completed, this may take several minutes
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable>
+</programlisting>
+
<para>
- The management client will reply <literal>Backup
- <replaceable>backup_id</replaceable> started</literal>,
- where <replaceable>backup_id</replaceable> is the unique
+ Here, <replaceable>backup_id</replaceable> is the unique
identifier for this particular backup. (This identifier will
also be saved in the cluster log, if it has not been
- configured otherwise.) This means that the cluster has
- received and processed the backup request. It does
- <emphasis>not</emphasis> mean that the backup has finished.
+ configured otherwise.)
+ <replaceable>management_node_id</replaceable> is the node ID
+ of the management to which the management client is
+ connected.
</para>
+
+ <para>
+ This means that the cluster has received and processed the
+ backup request. It does <emphasis>not</emphasis> mean that
+ the backup has been completed.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Backup messages were
+ not recorded in the cluster log in MySQL 5.1.12 or 5.1.13.
+ The logging of backup operations was restored in MySQL
+ 5.1.14 (see Bug #24544).
+ </para>
</listitem>
-
+
<listitem>
<para>
- The management client will signal that the backup is
- finished with the message <literal>Backup
- <replaceable>backup_id</replaceable> completed</literal>.
+ When the backup is completed, the management client will
+ indicate this as shown here:
</para>
+
+ <programlisting>
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable> completed
+ StartGCP: 417599 StopGCP: 417602
+ #Records: 105957 #LogRecords: 0
+ Data: 99719356 bytes Log: 0 bytes
+</programlisting>
+
+ <para>
+ The values shown for <literal>StartGCP</literal>,
+ <literal>StopGCP</literal>, <literal>#Records</literal>,
+ <literal>#LogRecords</literal>, <literal>Data</literal>, and
+ <literal>Log</literal> will vary according to the specifics
+ of your cluster.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
Cluster backups are created by default in the
<filename>BACKUP</filename> subdirectory of the
@@ -12301,77 +12327,113 @@
using the <literal>BackupDataDir</literal> configuration
parameter as discussed in
<link linkend="mysql-cluster-identifying-data-nodes">Identifying
- Data Nodes</link>. The backup files created for a backup with a
+ Data Nodes</link>. The backup files created for a backup with a
given <replaceable>backup_id</replaceable> are stored in a
subdirectory named
<filename>BACKUP-<replaceable>backup_id</replaceable></filename>
in the backup directory.
</para>
-
+
<para>
To abort a backup that is already in progress:
</para>
-
+
<orderedlist>
-
+
<listitem>
<para>
Start the management client.
</para>
</listitem>
-
+
<listitem>
<para>
- Execute the command <literal>ABORT BACKUP
- <replaceable>backup_id</replaceable></literal>. The number
- <replaceable>backup_id</replaceable> is the identifier of
- the backup that was included in the response of the
- management client when the backup was started (in the
+ Execute this command:
+ </para>
+
+ <programlisting>
+ndb_mgm> <userinput>ABORT BACKUP <replaceable>backup_id</replaceable></userinput>
+</programlisting>
+
+ <para>The number <replaceable>backup_id</replaceable> is the
+ identifier of the backup that was included in the response
+ of the management client when the backup was started (in the
message <literal>Backup <replaceable>backup_id</replaceable>
- started</literal>).
+ started from node
+ <replaceable>management_node_id</replaceable></literal>).
</para>
</listitem>
-
+
<listitem>
<para>
The management client will acknowledge the abort request
with <literal>Abort of backup
- <replaceable>backup_id</replaceable> ordered</literal>; note
- that it has received no actual response to this request yet.
+ <replaceable>backup_id</replaceable> ordered</literal>.
+ <emphasis role="bold">Note</emphasis>: At this point, the
+ management client has not yet received a response from the
+ cluster data nodes to this request, and the backup has not
+ yet actually been aborted.
</para>
</listitem>
-
+
<listitem>
<para>
After the backup has been aborted, the management client
- will report <literal>Backup
- <replaceable>backup_id</replaceable> has been aborted for
- reason <replaceable>XYZ</replaceable></literal>. This means
- that the cluster has terminated the backup and that all
- files related to this backup have been removed from the
- cluster filesystem.
+ will report this fact in a manner similar to what is shown
+ here:
</para>
+
+ <programlisting>
+Node 1: Backup 3 started from 5 has been aborted. Error: 1321 - Backup aborted by user request: Permanent error: User defined error
+Node 3: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 2: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 4: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+</programlisting>
+
+ <para>
+ In this example, we have shown sample output for a cluster
+ with 4 data nodes, where the sequence number of the backup
+ to be aborted is <literal>3</literal>, and the management
+ node to which the cluster management client is connected has
+ the node ID <literal>5</literal>. The first node to complete
+ its part in aborting the backup reports that the reason for
+ the abort was due to a request by the user. (The remaining
+ nodes report that the backup was aborted due to an
+ unspecified internal error.)
+ <emphasis role="bold">Note</emphasis>: There is no guarantee
+ that the cluster nodes will respond to an <literal>ABORT
+ BACKUP</literal> command in any particular order.
+ </para>
+
+ <para>
+ The <literal>Backup <replaceable>backup_id</replaceable>
+ started from node
+ <replaceable>management_node_id</replaceable> has been
+ aborted</literal> messages mean that the backup has been
+ terminated and that all files relating to this backup have
+ been removed from the cluster filesystem.
+ </para>
</listitem>
-
+
</orderedlist>
-
+
<para>
- It is also possible to abort a backup in progress from the
- system shell using this command:
+ It is also possible to abort a backup in progress from a system
+ shell using this command:
</para>
-
-<programlisting>
+
+ <programlisting>
shell> <userinput>ndb_mgm -e "ABORT BACKUP <replaceable>backup_id</replaceable>"</userinput>
</programlisting>
-
+
<para>
<emphasis role="bold">Note</emphasis>: If there is no backup
- with ID <replaceable>backup_id</replaceable> running when it is
- aborted, the management client makes no explicit response.
- However, the fact that an invalid abort command was sent is
- indicated in the cluster log.
+ with ID <replaceable>backup_id</replaceable> running when an
+ <literal>ABORT BACKUP</literal> is issued, the management client
+ makes no response, nor is it indicated in the cluster log that
+ an invalid abort command was sent.
</para>
-
+
</section>
<section id="mysql-cluster-restore">
Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml 2007-01-25 08:20:38 UTC (rev 4631)
+++ trunk/refman-5.1/mysql-cluster.xml 2007-01-25 12:24:15 UTC (rev 4632)
Changed blocks: 5, Lines Added: 91, Lines Deleted: 36; 8086 bytes
@@ -12315,24 +12315,29 @@
<listitem>
<para>
- The management client will reply with the message
- <literal>Start of backup ordered</literal>. This means that
- the management client has submitted the request to the
- cluster, but has not yet received any response.
+ The management client responds as shown here:
</para>
- </listitem>
-
- <listitem>
+
+<programlisting>
+Waiting for completed, this may take several minutes
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable>
+</programlisting>
+
<para>
- The management client will reply <literal>Backup
- <replaceable>backup_id</replaceable> started</literal>,
- where <replaceable>backup_id</replaceable> is the unique
+ Here, <replaceable>backup_id</replaceable> is the unique
identifier for this particular backup. (This identifier will
also be saved in the cluster log, if it has not been
- configured otherwise.) This means that the cluster has
- received and processed the backup request. It does
- <emphasis>not</emphasis> mean that the backup has finished.
+ configured otherwise.)
+ <replaceable>management_node_id</replaceable> is the node ID
+ of the management to which the management client is
+ connected.
</para>
+
+ <para>
+ This means that the cluster has received and processed the
+ backup request. It does <emphasis>not</emphasis> mean that
+ the backup has been completed.
+ </para>
<para>
<emphasis role="bold">Note</emphasis>: Backup messages were
@@ -12344,10 +12349,24 @@
<listitem>
<para>
- The management client will signal that the backup is
- finished with the message <literal>Backup
- <replaceable>backup_id</replaceable> completed</literal>.
+ When the backup is completed, the management client will
+ indicate this as shown here:
</para>
+
+<programlisting>
+Node 1: Backup <replaceable>backup_id</replaceable> started from node <replaceable>management_node_id</replaceable> completed
+ StartGCP: 417599 StopGCP: 417602
+ #Records: 105957 #LogRecords: 0
+ Data: 99719356 bytes Log: 0 bytes
+</programlisting>
+
+ <para>
+ The values shown for <literal>StartGCP</literal>,
+ <literal>StopGCP</literal>, <literal>#Records</literal>,
+ <literal>#LogRecords</literal>, <literal>Data</literal>, and
+ <literal>Log</literal> will vary according to the specifics
+ of your cluster.
+ </para>
</listitem>
</orderedlist>
@@ -12382,13 +12401,19 @@
<listitem>
<para>
- Execute the command <literal>ABORT BACKUP
- <replaceable>backup_id</replaceable></literal>. The number
- <replaceable>backup_id</replaceable> is the identifier of
- the backup that was included in the response of the
- management client when the backup was started (in the
+ Execute this command:
+ </para>
+
+<programlisting>
+ndb_mgm> <userinput>ABORT BACKUP <replaceable>backup_id</replaceable></userinput>
+</programlisting>
+
+ <para>The number <replaceable>backup_id</replaceable> is the
+ identifier of the backup that was included in the response
+ of the management client when the backup was started (in the
message <literal>Backup <replaceable>backup_id</replaceable>
- started</literal>).
+ started from node
+ <replaceable>management_node_id</replaceable></literal>).
</para>
</listitem>
@@ -12396,28 +12421,58 @@
<para>
The management client will acknowledge the abort request
with <literal>Abort of backup
- <replaceable>backup_id</replaceable> ordered</literal>; note
- that it has received no actual response to this request yet.
+ <replaceable>backup_id</replaceable> ordered</literal>.
+ <emphasis role="bold">Note</emphasis>: At this point, the
+ management client has not yet received a response from the
+ cluster data nodes to this request, and the backup has not
+ yet actually been aborted.
</para>
</listitem>
<listitem>
<para>
After the backup has been aborted, the management client
- will report <literal>Backup
- <replaceable>backup_id</replaceable> has been aborted for
- reason <replaceable>XYZ</replaceable></literal>. This means
- that the cluster has terminated the backup and that all
- files related to this backup have been removed from the
- cluster filesystem.
+ will report this fact in a manner similar to what is shown
+ here:
</para>
+
+<programlisting>
+Node 1: Backup 3 started from 5 has been aborted. Error: 1321 - Backup aborted by user request: Permanent error: User defined error
+Node 3: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 2: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+Node 4: Backup 3 started from 5 has been aborted. Error: 1323 - 1323: Permanent error: Internal error
+</programlisting>
+
+ <para>
+ In this example, we have shown sample output for a cluster
+ with 4 data nodes, where the sequence number of the backup
+ to be aborted is <literal>3</literal>, and the management
+ node to which the cluster management client is connected has
+ the node ID <literal>5</literal>. The first node to complete
+ its part in aborting the backup reports that the reason for
+ the abort was due to a request by the user. (The remaining
+ nodes report that the backup was aborted due to an
+ unspecified internal error.)
+ <emphasis role="bold">Note</emphasis>: There is no guarantee
+ that the cluster nodes will respond to an <literal>ABORT
+ BACKUP</literal> command in any particular order.
+ </para>
+
+ <para>
+ The <literal>Backup <replaceable>backup_id</replaceable>
+ started from node
+ <replaceable>management_node_id</replaceable> has been
+ aborted</literal> messages mean that the backup has been
+ terminated and that all files relating to this backup have
+ been removed from the cluster filesystem.
+ </para>
</listitem>
</orderedlist>
<para>
- It is also possible to abort a backup in progress from the
- system shell using this command:
+ It is also possible to abort a backup in progress from a system
+ shell using this command:
</para>
<programlisting>
@@ -12426,10 +12481,10 @@
<para>
<emphasis role="bold">Note</emphasis>: If there is no backup
- with ID <replaceable>backup_id</replaceable> running when it is
- aborted, the management client makes no explicit response.
- However, the fact that an invalid abort command was sent is
- indicated in the cluster log.
+ with ID <replaceable>backup_id</replaceable> running when an
+ <literal>ABORT BACKUP</literal> is issued, the management client
+ makes no response, nor is it indicated in the cluster log that
+ an invalid abort command was sent.
</para>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4632 - branches/telcos/refman-5.1 trunk/refman-4.1 trunk/refman-5.0 trunk/refman-5.1 | jon | 25 Jan |
