Author: paul
Date: 2008-03-06 16:57:56 +0100 (Thu, 06 Mar 2008)
New Revision: 10144
Log:
r29764@frost: paul | 2008-03-06 09:55:46 -0600
Minor revisions to backup chapter intro/examples.
Modified:
trunk/it/refman-5.1/backup.xml
trunk/pt/refman-5.1/backup.xml
trunk/refman-4.1/backup.xml
trunk/refman-5.0/backup.xml
trunk/refman-5.1/backup.xml
trunk/refman-6.0/backup.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:29750
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:29889
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:29764
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:29889
Modified: trunk/it/refman-5.1/backup.xml
===================================================================
--- trunk/it/refman-5.1/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/it/refman-5.1/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16442 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> tables. See
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> tables. See
<xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -522,9 +525,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -539,7 +542,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -547,7 +550,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -563,11 +566,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -594,10 +597,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -624,11 +627,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -646,9 +651,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<formalpara role="mnmas">
@@ -709,8 +715,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
</listitem>
Modified: trunk/pt/refman-5.1/backup.xml
===================================================================
--- trunk/pt/refman-5.1/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/pt/refman-5.1/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16442 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> tables. See
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> tables. See
<xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -522,9 +525,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -539,7 +542,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -547,7 +550,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -563,11 +566,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -594,10 +597,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -624,11 +627,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -646,9 +651,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<formalpara role="mnmas">
@@ -709,8 +715,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
</listitem>
Modified: trunk/refman-4.1/backup.xml
===================================================================
--- trunk/refman-4.1/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/refman-4.1/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16463 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> and <literal>ISAM</literal> tables.
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.
See <xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -513,9 +516,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -530,7 +533,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -538,7 +541,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -554,11 +557,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -585,10 +588,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -615,11 +618,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -637,9 +642,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<para>
@@ -687,8 +693,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
<para>
Modified: trunk/refman-5.0/backup.xml
===================================================================
--- trunk/refman-5.0/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/refman-5.0/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16433 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> tables. See
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> tables. See
<xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -513,9 +516,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -530,7 +533,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -538,7 +541,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -554,11 +557,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -585,10 +588,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -615,11 +618,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -637,9 +642,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<formalpara role="mnmas">
@@ -700,8 +706,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
</listitem>
Modified: trunk/refman-5.1/backup.xml
===================================================================
--- trunk/refman-5.1/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/refman-5.1/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16433 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> tables. See
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> tables. See
<xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -522,9 +525,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -539,7 +542,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -547,7 +550,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -563,11 +566,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -594,10 +597,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -624,11 +627,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -646,9 +651,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<formalpara role="mnmas">
@@ -709,8 +715,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
</listitem>
Modified: trunk/refman-6.0/backup.xml
===================================================================
--- trunk/refman-6.0/backup.xml 2008-03-06 13:43:33 UTC (rev 10143)
+++ trunk/refman-6.0/backup.xml 2008-03-06 15:57:56 UTC (rev 10144)
Changed blocks: 26, Lines Added: 87, Lines Deleted: 82; 16433 bytes
@@ -33,19 +33,19 @@
<listitem>
<para>
- Logical or physical backups
+ Logical versus physical backups
</para>
</listitem>
<listitem>
<para>
- Online or offline backups
+ Online versus offline backups
</para>
</listitem>
<listitem>
<para>
- Local or remote backups
+ Local versus remote backups
</para>
</listitem>
@@ -57,7 +57,7 @@
<listitem>
<para>
- Full or incremental backups
+ Full versus incremental backups
</para>
</listitem>
@@ -93,7 +93,7 @@
<emphasis role="bold">Logical versus physical (raw)
backups.</emphasis> Logical backups save information represented
as logical database structure (<literal>CREATE
- DATABASE</literal>, <literal>CREATE TABLE</literal> statements
+ DATABASE</literal>, <literal>CREATE TABLE</literal> statements)
and content (<literal>INSERT</literal> statements or
delimited-text files). Physical backups consist of raw copies of
the directories and files that store database contents.
@@ -108,7 +108,7 @@
<listitem>
<para>
The backup is done by going through the MySQL server to
- obtain database structure and content.
+ obtain database structure and content information.
</para>
</listitem>
@@ -122,16 +122,17 @@
<listitem>
<para>
- Output is larger than for physical backup.
+ Output is larger than for physical backup, paticularly when
+ saved in text format.
</para>
</listitem>
<listitem>
<para>
- Backup and restore granularity is available at the level of
- the server (all databases), database (all tables in a
- particular database), or table. This is true regardless of
- storage engine.
+ Backup and restore granularity is available at the server
+ level (all databases), database level (all tables in a
+ particular database), or table level. This is true
+ regardless of storage engine.
</para>
</listitem>
@@ -144,7 +145,8 @@
<listitem>
<para>
- Backups stored in logical format are highly portable.
+ Backups stored in logical format are machine independent and
+ highly portable.
</para>
</listitem>
@@ -158,9 +160,9 @@
<listitem>
<para>
Logical backup tools include the
- <command>mysqldump</command> program and <literal>SELECT ...
- INTO OUTFILE</literal> statement. These work for any storage
- engine, even <literal>MEMORY</literal>.
+ <command>mysqldump</command> program and the <literal>SELECT
+ ... INTO OUTFILE</literal> statement. These work for any
+ storage engine, even <literal>MEMORY</literal>.
</para>
<para>
@@ -245,16 +247,16 @@
<command>mysqlhotcopy</command> for
<literal>MyISAM</literal> tables,
<command>ibbackup</command> for <literal>InnoDB</literal>
- tables or <literal>START BACKUP</literal> for
+ tables, or <literal>START BACKUP</literal> for
<literal>NDB</literal> tables.
</para>
<para>
For restore, files copied at the filesystem level or with
<command>mysqlhotcopy</command> can be copied back to their
- original locations; <command>ibback</command> restores
- <literal>InnoDB</literal> tables, and
- <command>ndb_restore</command> restores
+ original locations with filesystem commands;
+ <command>ibback</command> restores <literal>InnoDB</literal>
+ tables, and <command>ndb_restore</command> restores
<literal>NDB</literal> tables.
</para>
</listitem>
@@ -265,14 +267,13 @@
<listitem>
<para>
<emphasis role="bold">Online versus offline backups.</emphasis>
- Online backups take place while the MySQL server is running,
- typically so that the database information can be obtained from
- the server. Offline backups take place while the server is
- stopped. (This can also be described as <quote>hot</quote>
- versus <quote>cold</quote> backups, a <quote>warm</quote> backup
- can be described as one where the server remains running but
- locked against modifying data while you access database files
- externally.)
+ Online backups take place while the MySQL server is running so
+ that the database information can be obtained from the server.
+ Offline backups take place while the server is stopped. (This
+ distinction can also be described as <quote>hot</quote> versus
+ <quote>cold</quote> backups; a <quote>warm</quote> backup is one
+ where the server remains running but locked against modifying
+ data while you access database files externally.)
</para>
<para>
@@ -283,18 +284,17 @@
<listitem>
<para>
- Less intrusive to other clients, which are not prevented
- from connecting to the MySQL server and may be unaffected
- for data access depending on what operations they need to
- perform.
+ Less intrusive to other clients, which can connect to the
+ MySQL server during the backup and may be able to access
+ data depending on what operations they need to perform.
</para>
</listitem>
<listitem>
<para>
- Can be trickier to perform because of the need to impose
- appropriate locking so that modifications do not take place
- that compromise backup integrity.
+ Care must be taken to impose appropriate locking so that
+ data modifications do not take place that compromise backup
+ integrity.
</para>
</listitem>
@@ -327,8 +327,8 @@
<para>
<emphasis role="bold">Local versus remote backups.</emphasis> A
local backup is performed on the same host where the MySQL
- server runs, whereas a remote backup is performed somewhere
- else.
+ server runs, whereas a remote backup is initiated from a
+ different host.
</para>
<itemizedlist>
@@ -336,7 +336,7 @@
<listitem>
<para>
<command>mysqldump</command> can connect to local or remote
- servers. For SQL output (<literal>CREATE</literal>,
+ servers. For SQL output (<literal>CREATE</literal> and
<literal>INSERT</literal> statements), local or remote dumps
can be done and generate output on the client. For
delimited-text output (with the <option>--tab</option>
@@ -354,11 +354,13 @@
<listitem>
<para>
- <literal>SELECT ... INTO OUTFILE</literal> can be executed
- against a remote server, but the output file is created on
+ <literal>SELECT ... INTO OUTFILE</literal> can be initiated
+ from a remote client host, but the output file is created on
the server host.
</para>
+ </listitem>
+ <listitem>
<para>
Physical backup methods typically are initiated locally on
the MySQL server host so that the server can be taken
@@ -373,15 +375,15 @@
<listitem>
<para>
<emphasis role="bold">Snapshot backups.</emphasis> Some
- filesystem implementations enable a <quote>snapshot</quote> of a
- filesystem to be taken. This provides a logical copy of the
- filesystem at a given point in time, without having to
- physically copy the entire filesystem. (For example, the
- implementation may use copy-on-write techniques so that only
- parts of the filesystem modified after the snapshot need be
- copied.) MySQL itself does not provide the capability for taking
- filesystem snapshots. It is available through third-party
- solutions such as Veritas or LVM.
+ filesystem implementations enable <quote>snapshots</quote> to be
+ taken. These provide logical copies of the filesystem at a given
+ point in time, without having to physically copy the entire
+ filesystem. (For example, the implementation may use
+ copy-on-write techniques so that only parts of the filesystem
+ modified after the snapshot time need be copied.) MySQL itself
+ does not provide the capability for taking filesystem snapshots.
+ It is available through third-party solutions such as Veritas or
+ LVM.
</para>
</listitem>
@@ -393,8 +395,8 @@
consists of the changes made to the data since the full backup.
MySQL has different ways to perform full backups, such as those
described in previous items. Incremental backups are made
- possible by enabling the server's binary log, which is used to
- record data changes.
+ possible by enabling the server's binary log, which the server
+ uses to record data changes.
</para>
</listitem>
@@ -403,7 +405,7 @@
<emphasis role="bold">Point-in-time recovery.</emphasis> One use
for the binary log is to achieve point-in-time recovery. This is
done by recovering first from the backup files to restore the
- server to its state when the backup was made, and they by
+ server to its state when the backup was made, and then by
re-executing changes in subsequently written binary log files to
redo data modifications up to the desired point in time.
</para>
@@ -420,16 +422,17 @@
capabilities. <command>ibbackup</command> can compress
<literal>InnoDB</literal> backups, and compression or encryption
of backup output can be achieved using filesystem utilities.
+ Other third-party solutions may be available.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">Table maintenance.</emphasis> Data
- integrity can be compromised if tables become corrupt, so this
- chapter also covers techniques for checking tables and repairing
- them should problems be found. These techniques apply primarily
- to <literal>MyISAM</literal> tables. See
+ integrity can be compromised if tables become corrupt. MySQL
+ provides programs for checking tables and repairing them should
+ problems be found. These programs apply primarily to
+ <literal>MyISAM</literal> tables. See
<xref linkend="table-maintenance"/>.
</para>
</listitem>
@@ -463,9 +466,9 @@
<listitem>
<para>
- Details for the <command>mysqldump</command> and
- <literal>mysqlhotcopy</literal> backup programs can be found in
- <xref linkend="programs"/>.
+ Details for <command>mysqldump</command>,
+ <command>mysqlhotcopy</command>, and other MySQL backup programs
+ can be found in <xref linkend="programs"/>.
</para>
</listitem>
@@ -522,9 +525,9 @@
<para>
<literal>MyISAM</literal> tables are stored as files, so it is
- easy to do a backup. To get a consistent backup, do a
- <literal>LOCK TABLES</literal> on the relevant tables, followed by
- <literal>FLUSH TABLES</literal> for the tables. See
+ easy to do a backup by copying files. To get a consistent backup,
+ do a <literal>LOCK TABLES</literal> on the relevant tables,
+ followed by <literal>FLUSH TABLES</literal> for the tables. See
<xref linkend="lock-tables"/>, and <xref linkend="flush"/>. You
need only a read lock; this allows other clients to continue to
query the tables while you are making a copy of the files in the
@@ -539,7 +542,7 @@
</para>
<para>
- To make an SQL-level backup of a table's contents, you can use
+ To create a text file containing a table's data, you can use
<literal>SELECT * INTO OUTFILE
'<replaceable>file_name</replaceable>' FROM
<replaceable>tbl_name</replaceable></literal>. The file is created
@@ -547,7 +550,7 @@
the output file cannot already exist because allowing files to be
overwritten would constitute a security risk. See
<xref linkend="select"/>. This method works for any kind of data
- file, but save only table data, not the table structure.
+ file, but saves only table data, not the table structure.
</para>
<para>
@@ -563,11 +566,11 @@
<para>
Another technique for backing up a database is to use the
- <command>mysqldump</command> program or the <command>mysqlhotcopy
- script</command>. <command>mysqldump</command> is more general
- because it can back up all kinds of files.
- <command>mysqlhotcopy</command> works only with some storage
- engines. (See <xref linkend="mysqldump"/>, and
+ <command>mysqldump</command> program or the
+ <command>mysqlhotcopy</command> script.
+ <command>mysqldump</command> is more general because it can back
+ up all kinds of tables. <command>mysqlhotcopy</command> works only
+ with some storage engines. (See <xref linkend="mysqldump"/>, and
<xref linkend="mysqlhotcopy"/>.)
</para>
@@ -594,10 +597,10 @@
updating anything. The <command>mysqlhotcopy</command> script uses
this method. (But note that these methods do not work if your
database contains <literal>InnoDB</literal> tables.
- <literal>InnoDB</literal> does not store table contents in
- database directories, and <command>mysqlhotcopy</command> works
- only for <literal>MyISAM</literal> and <literal>ISAM</literal>
- tables.)
+ <literal>InnoDB</literal> does not necessarily store table
+ contents in database directories, and
+ <command>mysqlhotcopy</command> works only for
+ <literal>MyISAM</literal> and <literal>ISAM</literal> tables.)
</para>
<para>
@@ -624,11 +627,13 @@
backup location all binary logs which range from the one of the
moment of the last full or incremental backup to the last but one.
These binary logs are the incremental backup; at restore time, you
- apply them as explained further below. The next time you do a full
- backup, you should also rotate the binary log using <literal>FLUSH
- LOGS</literal>, <literal>mysqldump --flush-logs</literal>, or
- <literal>mysqlhotcopy --flushlog</literal>. See
- <xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
+ apply them as explained in
+ <xref linkend="point-in-time-recovery"/>. The next time you do a
+ full backup, you should also rotate the binary log using
+ <literal>FLUSH LOGS</literal>, <command>mysqldump
+ --flush-logs</command>, or <command>mysqlhotcopy
+ --flushlog</command>. See <xref linkend="mysqldump"/>, and
+ <xref linkend="mysqlhotcopy"/>.
</para>
<para>
@@ -646,9 +651,10 @@
should also back up any <filename>SQL_LOAD-*</filename> files that
may exist in the directory specified by the
<option>--slave-load-tmpdir</option> option. (This location
- defaults to the value of the <literal>tmpdir</literal> variable if
- not specified.) The slave needs these files to resume replication
- of any interrupted <literal>LOAD DATA INFILE</literal> operations.
+ defaults to the value of the <literal>tmpdir</literal> system
+ variable if not specified.) The slave needs these files to resume
+ replication of any interrupted <literal>LOAD DATA INFILE</literal>
+ operations.
</para>
<formalpara role="mnmas">
@@ -709,8 +715,7 @@
logs, from certain positions (usually you want to re-run all
binary logs from the date of the restored backup, excepting
possibly some incorrect statements). See
- <xref linkend="mysqlbinlog"/>, for more information on the
- <command>mysqlbinlog</command> utility and how to use it.
+ <xref linkend="point-in-time-recovery"/>.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10144 - in trunk: . it/refman-5.1 pt/refman-5.1 refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 6 Mar |
