Author: paul
Date: 2006-01-29 06:00:13 +0100 (Sun, 29 Jan 2006)
New Revision: 1096
Log:
r6844@frost: paul | 2006-01-28 20:07:18 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/apis.xml
trunk/refman-4.1/charset.xml
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/functions.xml
trunk/refman-4.1/innodb.xml
trunk/refman-4.1/introduction.xml
trunk/refman-4.1/ndbcluster.xml
trunk/refman-4.1/renamed-nodes.txt
trunk/refman-5.0/apis.xml
trunk/refman-5.0/charset.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/functions.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/introduction.xml
trunk/refman-5.0/ndbcluster.xml
trunk/refman-5.0/precision-math.xml
trunk/refman-5.0/renamed-nodes.txt
trunk/refman-5.1/apis.xml
trunk/refman-5.1/charset.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/functions.xml
trunk/refman-5.1/innodb.xml
trunk/refman-5.1/ndbcluster.xml
trunk/refman-5.1/partitioning.xml
trunk/refman-5.1/precision-math.xml
trunk/refman-5.1/renamed-nodes.txt
trunk/refman-common/titles.en.ent
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6841
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6844
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
Modified: trunk/refman-4.1/apis.xml
===================================================================
--- trunk/refman-4.1/apis.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/apis.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8022,8 +8022,8 @@
<para>
This structure represents a prepared statement. A statement
is created by calling <literal>mysql_stmt_init()</literal>,
- which returns a statement handle, that is, a pointer to a
- <literal>MYSQL_STMT</literal>. The handle is used for all
+ which returns a statement handle (that is, a pointer to a
+ <literal>MYSQL_STMT</literal>). The handle is used for all
subsequent statement-related functions until you close it
with <literal>mysql_stmt_close()</literal>.
</para>
@@ -10076,7 +10076,7 @@
<para>
<literal>mysql_stmt_fetch()</literal> returns the next row in
the result set. It can be called only while the result set
- exists, that is, after a call to
+ exists; that is, after a call to
<literal>mysql_stmt_execute()</literal> that creates a result
set or after <literal>mysql_stmt_store_result()</literal>,
which is called after <literal>mysql_stmt_execute()</literal>
Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/charset.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -3253,7 +3253,7 @@
<para>
The most significant feature in
<literal>utf8_unicode_ci</literal> is that it supports
- expansions, that is, when one character compares as equal to
+ expansions; that is, when one character compares as equal to
combinations of other characters. For example, in German and
some other languages ‘<literal>ß</literal>’ is
equal to ‘<literal>ss</literal>’.
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/database-administration.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -16218,10 +16218,10 @@
This section discusses how to make database backups (full and
incremental) and how to perform table maintenance. The syntax of
the SQL statements described here is given in
- <xref linkend="database-administration"/>. Much of the information
- here pertains primarily to <literal>MyISAM</literal> tables.
- <literal>InnoDB</literal> backup procedures are given in
- <xref linkend="backing-up"/>.
+ <xref linkend="sql-syntax"/>. Much of the information here
+ pertains primarily to <literal>MyISAM</literal> tables. Additional
+ information about <literal>InnoDB</literal> backup procedures is
+ given in <xref linkend="innodb-backup"/>.
</para>
<section id="backup">
@@ -16251,13 +16251,11 @@
</para>
<para>
- If you want to make an SQL-level backup of a table, you can use
- <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
- TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
- the output file cannot previously exist. For <literal>BACKUP
- TABLE</literal>, the same is true as of MySQL 3.23.56 and
- 4.0.12, because this would be a security risk. See
- <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+ To make an SQL-level backup of a table, you can use
+ <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+ the output file cannot previously exist because allowing extant
+ files to be overwritten would constitute a security risk. See
+ <xref linkend="select"/>.
</para>
<para>
@@ -16287,17 +16285,17 @@
</programlisting>
<para>
- You can also simply copy all table files
- (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
- <filename>*.MYI</filename> files) as long as the server is
- not 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.)
+ You can also create a binary backup simply by copying all
+ table files (<filename>*.frm</filename>,
+ <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+ files), as long as the server isn't 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.)
</para>
</listitem>
@@ -16309,9 +16307,10 @@
</indexterm>
Stop <command>mysqld</command> if it is running, then start
- it with the <option>--log-bin[=file_name]</option> option.
- See <xref linkend="binary-log"/>. The binary log files
- provide you with the information you need to replicate
+ it with the
+ <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+ option. See <xref linkend="binary-log"/>. The binary log
+ files provide you with the information you need to replicate
changes to the database that are made subsequent to the
point at which you executed <command>mysqldump</command>.
</para>
@@ -16339,7 +16338,7 @@
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 --flushlogs</literal>. See
+ <literal>mysqlhotcopy --flushlog</literal>. See
<xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
</para>
@@ -16367,8 +16366,7 @@
of all cases. If <command>myisamchk</command> fails, try the
following procedure. Note that it works only if you have enabled
binary logging by starting MySQL with the
- <option>--log-bin</option> option; see
- <xref linkend="binary-log"/>.
+ <option>--log-bin</option> option.
</para>
<orderedlist>
@@ -16432,8 +16430,8 @@
<listitem>
<para>
- To reload the table, use and restore with <literal>LOAD DATA
- INFILE '<replaceable>file_name</replaceable>' REPLACE
+ To reload the table, use <literal>LOAD DATA INFILE
+ '<replaceable>file_name</replaceable>' REPLACE
...</literal>. To avoid duplicate rows, the table must have
a <literal>PRIMARY KEY</literal> or a
<literal>UNIQUE</literal> index. The
@@ -16610,13 +16608,14 @@
<title>&title-backup-policy;</title>
<para>
- We all know that backups must be scheduled periodically. Full
- backups (a snapshot of the data at a point in time) can be
- done in MySQL with several tools. For example, <literal>InnoDB
- Hot Backup</literal> provides online non-blocking physical
- backup of the <literal>InnoDB</literal> data files, and
- <command>mysqldump</command> provides online logical backup.
- This discussion uses <command>mysqldump</command>.
+ We all know that backups must be scheduled periodically. A
+ full backups (a snapshot of the data at a point in time) can
+ be done in MySQL with several tools. For example,
+ <literal>InnoDB Hot Backup</literal> provides online
+ non-blocking physical backup of the <literal>InnoDB</literal>
+ data files, and <command>mysqldump</command> provides online
+ logical backup. This discussion uses
+ <command>mysqldump</command>.
</para>
<para>
@@ -16704,25 +16703,26 @@
</para>
<para>
- The MySQL binary logs are important for recovery, because they
- are incremental backups. If you make sure to flush the logs
- when you make your full backup, then any binary log files
- created afterward contain all the data changes made since the
- backup. Let's modify the previous <command>mysqldump</command>
- command a bit so that it flushes the MySQL binary logs at the
- moment of the full backup, and so that the dump file contains
- the name of the new current binary log:
+ The MySQL binary logs are important for recovery because they
+ form the set of incremental backups. If you make sure to flush
+ the logs when you make your full backup, then any binary log
+ files created afterward contain all the data changes made
+ since the backup. Let's modify the previous
+ <command>mysqldump</command> command a bit so that it flushes
+ the MySQL binary logs at the moment of the full backup, and so
+ that the dump file contains the name of the new current binary
+ log:
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
After executing this command, the data directory contains a
new binary log file, <filename>gbichot2-bin.000007</filename>.
- The resulting <filename>.sql</filename> file contains these
+ The resulting <filename>.sql</filename> file includes these
lines:
</para>
@@ -16733,7 +16733,7 @@
<para>
Because the <command>mysqldump</command> command made a full
- backup, these lines mean two things:
+ backup, those lines mean two things:
</para>
<itemizedlist>
@@ -16763,15 +16763,15 @@
flushing the logs to begin a new binary log file. For example,
executing a <command>mysqladmin flush-logs</command> command
creates <filename>gbichot2-bin.000008</filename>. All changes
- between the Sunday 1 PM full backup and Monday 1 PM are the
- file <filename>gbichot2-bin.000007</filename>. This
- incremental backup is important, so it is a good idea to copy
+ between the Sunday 1 PM full backup and Monday 1 PM will be in
+ the <filename>gbichot2-bin.000007</filename> file. This
+ incremental backup is important, so it's a good idea to copy
it to a safe place. (For example, back it up on tape or DVD,
- or copy it to another machine.) On Tuesday 1 PM, execute
+ or copy it to another machine.) On Tuesday at 1 PM, execute
another <command>mysqladmin flush-logs</command> command. All
- changes between Monday 1 PM and Tuesday 1 PM are the file
- <filename>gbichot2-bin.000008</filename> (which also should be
- copied somewhere safe).
+ changes between Monday 1 PM and Tuesday 1 PM will be in the
+ <filename>gbichot2-bin.000008</filename> file (which also
+ should be copied somewhere safe).
</para>
<para>
@@ -16782,8 +16782,8 @@
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
@@ -16792,9 +16792,6 @@
--delete-master-logs</command> can be dangerous if your server
is a replication master server, because slave servers might
not yet fully have processed the contents of the binary log.
- </para>
-
- <para>
The description for the <literal>PURGE MASTER LOGS</literal>
statement explains what should be verified before deleting the
MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -16807,7 +16804,7 @@
<title>&title-backup-recovery;</title>
<para>
- Now suppose that we have a catastrophic crash on Wednesday at
+ Now, suppose that we have a catastrophic crash on Wednesday at
8 AM that requires recovery from backups. To recover, first we
restore the last full backup we have (the one from Sunday 1
PM). The full backup file is just a set of SQL statements, so
@@ -16821,7 +16818,7 @@
<para>
At this point, the data is restored to its state as of Sunday
1 PM. To restore the changes made since then, we must use the
- incremental backups, that is, the
+ incremental backups; that is, the
<filename>gbichot2-bin.000007</filename> and
<filename>gbichot2-bin.000008</filename> binary log files.
Fetch them if necessary from where they were backed up, and
Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/functions.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -5037,7 +5037,7 @@
<para>
Returns the natural logarithm of
- <replaceable>X</replaceable>, that is, the
+ <replaceable>X</replaceable>; that is, the
base-<emphasis>e</emphasis> logarithm of
<replaceable>X</replaceable>.
</para>
@@ -9119,7 +9119,7 @@
columns included in a <literal>FULLTEXT</literal> index. The
search string is given as the argument to
<literal>AGAINST()</literal>. For each row in the table,
- <literal>MATCH()</literal> returns a relevance value, that is, a
+ <literal>MATCH()</literal> returns a relevance value; that is, a
similarity measure between the search string and the text in that
row in the columns named in the <literal>MATCH()</literal> list.
</para>
@@ -10686,7 +10686,7 @@
</para>
<para>
- The stopword list is free-form, that is, you may use any
+ The stopword list is free-form. That is, you may use any
non-alphanumeric character such as newline, space, or comma
to separate stopwords. Exceptions are the underscore
character (<literal>_</literal>) and a single apostrophe
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/innodb.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -2469,7 +2469,7 @@
deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
constraints row-by-row. According to the SQL standard, the
- default behavior should be deferred checking, that is,
+ default behavior should be deferred checking. That is,
constraints are only checked after the
<emphasis role="bold">whole SQL statement</emphasis> has been
processed. Until <literal>InnoDB</literal> implements deferred
@@ -2752,7 +2752,7 @@
slave. If the <literal>innodb_file_per_table</literal> variable
is enabled, you must also copy the <filename>.ibd</filename>
files as well. For the proper procedure to do this, see
- <xref linkend="backing-up"/>.
+ <xref linkend="innodb-backup"/>.
</para>
<para>
@@ -2982,9 +2982,9 @@
</section>
- <section id="backing-up">
+ <section id="innodb-backup">
- <title>&title-backing-up;</title>
+ <title>&title-innodb-backup;</title>
<para>
The key to safe database management is making regular backups.
@@ -3370,8 +3370,8 @@
<literal>InnoDB</literal> data and log files are binary-compatible
on all platforms having the same floating-point number format. You
can move an <literal>InnoDB</literal> database simply by copying
- all the relevant files listed in <xref linkend="backing-up"/>. If
- the floating-point formats differ but you have not used
+ all the relevant files listed in <xref linkend="innodb-backup"/>.
+ If the floating-point formats differ but you have not used
<literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
in your tables, then the procedure is the same: simply copy the
relevant files. If the formats differ and your tables contain
@@ -4148,8 +4148,8 @@
<para>
Suppose that you are running in the default <literal>REPEATABLE
- READ</literal> isolation level. When you issue a consistent
- read, that is, an ordinary <literal>SELECT</literal> statement,
+ READ</literal> isolation level. When you issue a consistent read
+ (that is, an ordinary <literal>SELECT</literal> statement),
<literal>InnoDB</literal> gives your transaction a timepoint
according to which your query sees the database. If another
transaction deletes a row and commits after your timepoint was
Modified: trunk/refman-4.1/introduction.xml
===================================================================
--- trunk/refman-4.1/introduction.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/introduction.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -1011,7 +1011,7 @@
Schema)</emphasis>: The introduction of the
<literal>INFORMATION_SCHEMA</literal> database in MySQL 5.0
provided a standards-compliant means for accessing the MySQL
- Server's metadata, that is, data about the databases
+ Server's metadata; that is, data about the databases
(schemas) on the server and the objects which they contain.
</para>
</listitem>
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/ndbcluster.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8116,7 +8116,7 @@
command-line utility <command>ndb_restore</command>, which
reads the files created by the backup and inserts the stored
information into the database. The restore program must be
- executed once for each set of backup files, that is, as many
+ executed once for each set of backup files; that is, as many
times as there were database nodes running when the backup was
created.
</para>
Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-4.1/renamed-nodes.txt 2006-01-29 05:00:13 UTC (rev 1096)
@@ -111,3 +111,4 @@
upgrading-grant-tables mysql-fix-privilege-tables
secure-grant grant
secure-requirements secure-using-openssl
+backing-up innodb-backup
Modified: trunk/refman-5.0/apis.xml
===================================================================
--- trunk/refman-5.0/apis.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/apis.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8056,8 +8056,8 @@
<para>
This structure represents a prepared statement. A statement
is created by calling <literal>mysql_stmt_init()</literal>,
- which returns a statement handle, that is, a pointer to a
- <literal>MYSQL_STMT</literal>. The handle is used for all
+ which returns a statement handle (that is, a pointer to a
+ <literal>MYSQL_STMT</literal>). The handle is used for all
subsequent statement-related functions until you close it
with <literal>mysql_stmt_close()</literal>.
</para>
@@ -10120,7 +10120,7 @@
<para>
<literal>mysql_stmt_fetch()</literal> returns the next row in
the result set. It can be called only while the result set
- exists, that is, after a call to
+ exists; that is, after a call to
<literal>mysql_stmt_execute()</literal> that creates a result
set or after <literal>mysql_stmt_store_result()</literal>,
which is called after <literal>mysql_stmt_execute()</literal>
Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/charset.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -2773,7 +2773,7 @@
<para>
The most significant feature in
<literal>utf8_unicode_ci</literal> is that it supports
- expansions, that is, when one character compares as equal to
+ expansions; that is, when one character compares as equal to
combinations of other characters. For example, in German and
some other languages ‘<literal>ß</literal>’ is
equal to ‘<literal>ss</literal>’.
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/database-administration.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -18487,10 +18487,10 @@
This section discusses how to make database backups (full and
incremental) and how to perform table maintenance. The syntax of
the SQL statements described here is given in
- <xref linkend="database-administration"/>. Much of the information
- here pertains primarily to <literal>MyISAM</literal> tables.
- <literal>InnoDB</literal> backup procedures are given in
- <xref linkend="backing-up"/>.
+ <xref linkend="sql-syntax"/>. Much of the information here
+ pertains primarily to <literal>MyISAM</literal> tables. Additional
+ information about <literal>InnoDB</literal> backup procedures is
+ given in <xref linkend="innodb-backup"/>.
</para>
<section id="backup">
@@ -18520,13 +18520,11 @@
</para>
<para>
- If you want to make an SQL-level backup of a table, you can use
- <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
- TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
- the output file cannot previously exist. This is also true of
- <literal>BACKUP TABLE</literal> because allowing extant files to
- be overwritten would constitute a security risk. See
- <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+ To make an SQL-level backup of a table, you can use
+ <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+ the output file cannot previously exist because allowing extant
+ files to be overwritten would constitute a security risk. See
+ <xref linkend="select"/>.
</para>
<para>
@@ -18556,16 +18554,16 @@
</programlisting>
<para>
- You can also simply copy all table files
- (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
- <filename>*.MYI</filename> files) as long as the server
- isn't 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> tables.)
+ You can also create a binary backup simply by copying all
+ table files (<filename>*.frm</filename>,
+ <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+ files), as long as the server isn't 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> tables.)
</para>
</listitem>
@@ -18577,9 +18575,10 @@
</indexterm>
Stop <command>mysqld</command> if it's running, then start
- it with the <option>--log-bin[=file_name]</option> option.
- See <xref linkend="binary-log"/>. The binary log files
- provide you with the information you need to replicate
+ it with the
+ <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+ option. See <xref linkend="binary-log"/>. The binary log
+ files provide you with the information you need to replicate
changes to the database that are made subsequent to the
point at which you executed <command>mysqldump</command>.
</para>
@@ -18607,7 +18606,7 @@
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 --flushlogs</literal>. See
+ <literal>mysqlhotcopy --flushlog</literal>. See
<xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
</para>
@@ -18635,8 +18634,7 @@
of all cases. If <command>myisamchk</command> fails, try the
following procedure. Note that it works only if you have enabled
binary logging by starting MySQL with the
- <option>--log-bin</option> option; see
- <xref linkend="binary-log"/>.
+ <option>--log-bin</option> option.
</para>
<orderedlist>
@@ -18686,10 +18684,11 @@
<listitem>
<para>
- To reload the table, use and restore with <literal>LOAD DATA
- INFILE 'file_name' REPLACE ...</literal> To avoid duplicate
- rows, the table must have a <literal>PRIMARY KEY</literal>
- or a <literal>UNIQUE</literal> index. The
+ To reload the table, use <literal>LOAD DATA INFILE
+ '<replaceable>file_name</replaceable>' REPLACE ...</literal>
+ To avoid duplicate rows, the table must have a
+ <literal>PRIMARY KEY</literal> or a
+ <literal>UNIQUE</literal> index. The
<literal>REPLACE</literal> keyword causes old rows to be
replaced with new ones when a new row duplicates an old row
on a unique key value.
@@ -18858,13 +18857,14 @@
<title>&title-backup-policy;</title>
<para>
- We all know that backups must be scheduled periodically. Full
- backups (a snapshot of the data at a point in time) can be
- done in MySQL with several tools. For example, <literal>InnoDB
- Hot Backup</literal> provides online non-blocking physical
- backup of the <literal>InnoDB</literal> data files, and
- <command>mysqldump</command> provides online logical backup.
- This discussion uses <command>mysqldump</command>.
+ We all know that backups must be scheduled periodically. A
+ full backups (a snapshot of the data at a point in time) can
+ be done in MySQL with several tools. For example,
+ <literal>InnoDB Hot Backup</literal> provides online
+ non-blocking physical backup of the <literal>InnoDB</literal>
+ data files, and <command>mysqldump</command> provides online
+ logical backup. This discussion uses
+ <command>mysqldump</command>.
</para>
<para>
@@ -18951,25 +18951,26 @@
</para>
<para>
- The MySQL binary logs are important for recovery, because they
- are incremental backups. If you make sure to flush the logs
- when you make your full backup, then any binary log files
- created afterward contain all the data changes made since the
- backup. Let's modify the previous <command>mysqldump</command>
- command a bit so that it flushes the MySQL binary logs at the
- moment of the full backup, and so that the dump file contains
- the name of the new current binary log:
+ The MySQL binary logs are important for recovery because they
+ form the set of incremental backups. If you make sure to flush
+ the logs when you make your full backup, then any binary log
+ files created afterward contain all the data changes made
+ since the backup. Let's modify the previous
+ <command>mysqldump</command> command a bit so that it flushes
+ the MySQL binary logs at the moment of the full backup, and so
+ that the dump file contains the name of the new current binary
+ log:
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
After executing this command, the data directory contains a
new binary log file, <filename>gbichot2-bin.000007</filename>.
- The resulting <filename>.sql</filename> file contains these
+ The resulting <filename>.sql</filename> file includes these
lines:
</para>
@@ -18980,7 +18981,7 @@
<para>
Because the <command>mysqldump</command> command made a full
- backup, these lines mean two things:
+ backup, those lines mean two things:
</para>
<itemizedlist>
@@ -19010,15 +19011,15 @@
flushing the logs to begin a new binary log file. For example,
executing a <command>mysqladmin flush-logs</command> command
creates <filename>gbichot2-bin.000008</filename>. All changes
- between the Sunday 1 PM full backup and Monday 1 PM are the
- file <filename>gbichot2-bin.000007</filename>. This
+ between the Sunday 1 PM full backup and Monday 1 PM will be in
+ the <filename>gbichot2-bin.000007</filename> file. This
incremental backup is important, so it's a good idea to copy
it to a safe place. (For example, back it up on tape or DVD,
- or copy it to another machine.) On Tuesday 1 PM, execute
+ or copy it to another machine.) On Tuesday at 1 PM, execute
another <command>mysqladmin flush-logs</command> command. All
- changes between Monday 1 PM and Tuesday 1 PM are the file
- <filename>gbichot2-bin.000008</filename> (which also should be
- copied somewhere safe).
+ changes between Monday 1 PM and Tuesday 1 PM will be in the
+ <filename>gbichot2-bin.000008</filename> file (which also
+ should be copied somewhere safe).
</para>
<para>
@@ -19029,8 +19030,8 @@
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
@@ -19039,9 +19040,6 @@
--delete-master-logs</command> can be dangerous if your server
is a replication master server, because slave servers might
not yet fully have processed the contents of the binary log.
- </para>
-
- <para>
The description for the <literal>PURGE MASTER LOGS</literal>
statement explains what should be verified before deleting the
MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -19054,7 +19052,7 @@
<title>&title-backup-recovery;</title>
<para>
- Now suppose that we have a catastrophic crash on Wednesday at
+ Now, suppose that we have a catastrophic crash on Wednesday at
8 AM that requires recovery from backups. To recover, first we
restore the last full backup we have (the one from Sunday 1
PM). The full backup file is just a set of SQL statements, so
@@ -19068,7 +19066,7 @@
<para>
At this point, the data is restored to its state as of Sunday
1 PM. To restore the changes made since then, we must use the
- incremental backups, that is, the
+ incremental backups; that is, the
<filename>gbichot2-bin.000007</filename> and
<filename>gbichot2-bin.000008</filename> binary log files.
Fetch them if necessary from where they were backed up, and
Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/functions.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -5124,7 +5124,7 @@
<para>
Returns the natural logarithm of
- <replaceable>X</replaceable>, that is, the
+ <replaceable>X</replaceable>; that is, the
base-<emphasis>e</emphasis> logarithm of
<replaceable>X</replaceable>.
</para>
@@ -9218,7 +9218,7 @@
columns included in a <literal>FULLTEXT</literal> index. The
search string is given as the argument to
<literal>AGAINST()</literal>. For each row in the table,
- <literal>MATCH()</literal> returns a relevance value, that is, a
+ <literal>MATCH()</literal> returns a relevance value; that is, a
similarity measure between the search string and the text in that
row in the columns named in the <literal>MATCH()</literal> list.
</para>
@@ -10786,7 +10786,7 @@
</para>
<para>
- The stopword list is free-form, that is, you may use any
+ The stopword list is free-form. That is, you may use any
non-alphanumeric character such as newline, space, or comma
to separate stopwords. Exceptions are the underscore
character (<literal>_</literal>) and a single apostrophe
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/innodb.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -2509,7 +2509,7 @@
deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
constraints row-by-row. According to the SQL standard, the
- default behavior should be deferred checking, that is,
+ default behavior should be deferred checking. That is,
constraints are only checked after the <emphasis>entire SQL
statement</emphasis> has been processed. Until
<literal>InnoDB</literal> implements deferred constraint
@@ -2767,7 +2767,7 @@
slave. If the <literal>innodb_file_per_table</literal> variable
is enabled, you must also copy the <filename>.ibd</filename>
files as well. For the proper procedure to do this, see
- <xref linkend="backing-up"/>.
+ <xref linkend="innodb-backup"/>.
</para>
<para>
@@ -2959,9 +2959,9 @@
</section>
- <section id="backing-up">
+ <section id="innodb-backup">
- <title>&title-backing-up;</title>
+ <title>&title-innodb-backup;</title>
<para>
The key to safe database management is making regular backups.
@@ -3336,8 +3336,8 @@
<literal>InnoDB</literal> data and log files are binary-compatible
on all platforms having the same floating-point number format. You
can move an <literal>InnoDB</literal> database simply by copying
- all the relevant files listed in <xref linkend="backing-up"/>. If
- the floating-point formats differ but you have not used
+ all the relevant files listed in <xref linkend="innodb-backup"/>.
+ If the floating-point formats differ but you have not used
<literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
in your tables, then the procedure is the same: simply copy the
relevant files. If the formats differ and your tables contain
@@ -4106,8 +4106,8 @@
<para>
Suppose that you are running in the default <literal>REPEATABLE
- READ</literal> isolation level. When you issue a consistent
- read, that is, an ordinary <literal>SELECT</literal> statement,
+ READ</literal> isolation level. When you issue a consistent read
+ (that is, an ordinary <literal>SELECT</literal> statement),
<literal>InnoDB</literal> gives your transaction a timepoint
according to which your query sees the database. If another
transaction deletes a row and commits after your timepoint was
Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/introduction.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -404,7 +404,7 @@
<emphasis role="bold">Information Schema</emphasis>: The
introduction of the <literal>INFORMATION_SCHEMA</literal>
database in MySQL 5.0 provided a standards-compliant means
- for accessing the MySQL Server's metadata, that is, data
+ for accessing the MySQL Server's metadata; that is, data
about the databases (schemas) on the server and the objects
which they contain. See
<xref linkend="information-schema"/>.
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/ndbcluster.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8090,7 +8090,7 @@
command-line utility <command>ndb_restore</command>, which
reads the files created by the backup and inserts the stored
information into the database. The restore program must be
- executed once for each set of backup files, that is, as many
+ executed once for each set of backup files; that is, as many
times as there were database nodes running when the backup was
created.
</para>
Modified: trunk/refman-5.0/precision-math.xml
===================================================================
--- trunk/refman-5.0/precision-math.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/precision-math.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -69,8 +69,8 @@
</indexterm>
<para>
- MySQL 5.0 introduces precision math, that is, numeric value handling
- that results in more accurate results and more control over invalid
+ MySQL 5.0 introduces precision math: numeric value handling that
+ results in more accurate results and more control over invalid
values than in earlier versions of MySQL. Precision math is based on
two implementation changes:
</para>
Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.0/renamed-nodes.txt 2006-01-29 05:00:13 UTC (rev 1096)
@@ -411,3 +411,4 @@
secure-grant grant
secure-requirements secure-using-openssl
information-schema-tables information-schema
+backing-up innodb-backup
Modified: trunk/refman-5.1/apis.xml
===================================================================
--- trunk/refman-5.1/apis.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/apis.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8062,8 +8062,8 @@
<para>
This structure represents a prepared statement. A statement
is created by calling <literal>mysql_stmt_init()</literal>,
- which returns a statement handle, that is, a pointer to a
- <literal>MYSQL_STMT</literal>. The handle is used for all
+ which returns a statement handle (that is, a pointer to a
+ <literal>MYSQL_STMT</literal>). The handle is used for all
subsequent statement-related functions until you close it
with <literal>mysql_stmt_close()</literal>.
</para>
@@ -10125,7 +10125,7 @@
<para>
<literal>mysql_stmt_fetch()</literal> returns the next row in
the result set. It can be called only while the result set
- exists, that is, after a call to
+ exists; that is, after a call to
<literal>mysql_stmt_execute()</literal> that creates a result
set or after <literal>mysql_stmt_store_result()</literal>,
which is called after <literal>mysql_stmt_execute()</literal>
Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/charset.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -2763,7 +2763,7 @@
<para>
The most significant feature in
<literal>utf8_unicode_ci</literal> is that it supports
- expansions, that is, when one character compares as equal to
+ expansions; that is, when one character compares as equal to
combinations of other characters. For example, in German and
some other languages ‘<literal>ß</literal>’ is
equal to ‘<literal>ss</literal>’.
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/database-administration.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -18496,10 +18496,10 @@
This section discusses how to make database backups (full and
incremental) and how to perform table maintenance. The syntax of
the SQL statements described here is given in
- <xref linkend="database-administration"/>. Much of the information
- here pertains primarily to <literal>MyISAM</literal> tables.
- <literal>InnoDB</literal> backup procedures are given in
- <xref linkend="backing-up"/>.
+ <xref linkend="sql-syntax"/>. Much of the information here
+ pertains primarily to <literal>MyISAM</literal> tables. Additional
+ information about <literal>InnoDB</literal> backup procedures is
+ given in <xref linkend="innodb-backup"/>.
</para>
<section id="backup">
@@ -18529,13 +18529,11 @@
</para>
<para>
- If you want to make an SQL-level backup of a table, you can use
- <literal>SELECT INTO ... OUTFILE</literal> or <literal>BACKUP
- TABLE</literal>. For <literal>SELECT INTO ... OUTFILE</literal>,
- the output file cannot previously exist. This is also true of
- <literal>BACKUP TABLE</literal> because allowing extant files to
- be overwritten would constitute a security risk. See
- <xref linkend="select"/>, and <xref linkend="backup-table"/>.
+ To make an SQL-level backup of a table, you can use
+ <literal>SELECT INTO ... OUTFILE</literal>. For this statement,
+ the output file cannot previously exist because allowing extant
+ files to be overwritten would constitute a security risk. See
+ <xref linkend="select"/>.
</para>
<para>
@@ -18565,16 +18563,16 @@
</programlisting>
<para>
- You can also simply copy all table files
- (<filename>*.frm</filename>, <filename>*.MYD</filename>, and
- <filename>*.MYI</filename> files) as long as the server
- isn't 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> tables.)
+ You can also create a binary backup simply by copying all
+ table files (<filename>*.frm</filename>,
+ <filename>*.MYD</filename>, and <filename>*.MYI</filename>
+ files), as long as the server isn't 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> tables.)
</para>
</listitem>
@@ -18586,9 +18584,10 @@
</indexterm>
Stop <command>mysqld</command> if it's running, then start
- it with the <option>--log-bin[=file_name]</option> option.
- See <xref linkend="binary-log"/>. The binary log files
- provide you with the information you need to replicate
+ it with the
+ <option>--log-bin[=<replaceable>file_name</replaceable>]</option>
+ option. See <xref linkend="binary-log"/>. The binary log
+ files provide you with the information you need to replicate
changes to the database that are made subsequent to the
point at which you executed <command>mysqldump</command>.
</para>
@@ -18616,7 +18615,7 @@
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 --flushlogs</literal>. See
+ <literal>mysqlhotcopy --flushlog</literal>. See
<xref linkend="mysqldump"/>, and <xref linkend="mysqlhotcopy"/>.
</para>
@@ -18644,8 +18643,7 @@
of all cases. If <command>myisamchk</command> fails, try the
following procedure. Note that it works only if you have enabled
binary logging by starting MySQL with the
- <option>--log-bin</option> option; see
- <xref linkend="binary-log"/>.
+ <option>--log-bin</option> option.
</para>
<orderedlist>
@@ -18695,10 +18693,11 @@
<listitem>
<para>
- To reload the table, use and restore with <literal>LOAD DATA
- INFILE 'file_name' REPLACE ...</literal> To avoid duplicate
- rows, the table must have a <literal>PRIMARY KEY</literal>
- or a <literal>UNIQUE</literal> index. The
+ To reload the table, use <literal>LOAD DATA INFILE
+ '<replaceable>file_name</replaceable>' REPLACE ...</literal>
+ To avoid duplicate rows, the table must have a
+ <literal>PRIMARY KEY</literal> or a
+ <literal>UNIQUE</literal> index. The
<literal>REPLACE</literal> keyword causes old rows to be
replaced with new ones when a new row duplicates an old row
on a unique key value.
@@ -18867,13 +18866,14 @@
<title>&title-backup-policy;</title>
<para>
- We all know that backups must be scheduled periodically. Full
- backups (a snapshot of the data at a point in time) can be
- done in MySQL with several tools. For example, <literal>InnoDB
- Hot Backup</literal> provides online non-blocking physical
- backup of the <literal>InnoDB</literal> data files, and
- <command>mysqldump</command> provides online logical backup.
- This discussion uses <command>mysqldump</command>.
+ We all know that backups must be scheduled periodically. A
+ full backups (a snapshot of the data at a point in time) can
+ be done in MySQL with several tools. For example,
+ <literal>InnoDB Hot Backup</literal> provides online
+ non-blocking physical backup of the <literal>InnoDB</literal>
+ data files, and <command>mysqldump</command> provides online
+ logical backup. This discussion uses
+ <command>mysqldump</command>.
</para>
<para>
@@ -18960,25 +18960,26 @@
</para>
<para>
- The MySQL binary logs are important for recovery, because they
- are incremental backups. If you make sure to flush the logs
- when you make your full backup, then any binary log files
- created afterward contain all the data changes made since the
- backup. Let's modify the previous <command>mysqldump</command>
- command a bit so that it flushes the MySQL binary logs at the
- moment of the full backup, and so that the dump file contains
- the name of the new current binary log:
+ The MySQL binary logs are important for recovery because they
+ form the set of incremental backups. If you make sure to flush
+ the logs when you make your full backup, then any binary log
+ files created afterward contain all the data changes made
+ since the backup. Let's modify the previous
+ <command>mysqldump</command> command a bit so that it flushes
+ the MySQL binary logs at the moment of the full backup, and so
+ that the dump file contains the name of the new current binary
+ log:
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
After executing this command, the data directory contains a
new binary log file, <filename>gbichot2-bin.000007</filename>.
- The resulting <filename>.sql</filename> file contains these
+ The resulting <filename>.sql</filename> file includes these
lines:
</para>
@@ -18989,7 +18990,7 @@
<para>
Because the <command>mysqldump</command> command made a full
- backup, these lines mean two things:
+ backup, those lines mean two things:
</para>
<itemizedlist>
@@ -19019,15 +19020,15 @@
flushing the logs to begin a new binary log file. For example,
executing a <command>mysqladmin flush-logs</command> command
creates <filename>gbichot2-bin.000008</filename>. All changes
- between the Sunday 1 PM full backup and Monday 1 PM are the
- file <filename>gbichot2-bin.000007</filename>. This
+ between the Sunday 1 PM full backup and Monday 1 PM will be in
+ the <filename>gbichot2-bin.000007</filename> file. This
incremental backup is important, so it's a good idea to copy
it to a safe place. (For example, back it up on tape or DVD,
- or copy it to another machine.) On Tuesday 1 PM, execute
+ or copy it to another machine.) On Tuesday at 1 PM, execute
another <command>mysqladmin flush-logs</command> command. All
- changes between Monday 1 PM and Tuesday 1 PM are the file
- <filename>gbichot2-bin.000008</filename> (which also should be
- copied somewhere safe).
+ changes between Monday 1 PM and Tuesday 1 PM will be in the
+ <filename>gbichot2-bin.000008</filename> file (which also
+ should be copied somewhere safe).
</para>
<para>
@@ -19038,8 +19039,8 @@
</para>
<programlisting>
-shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2</userinput>
- <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
+shell> <userinput>mysqldump --single-transaction --flush-logs --master-data=2 \</userinput>
+ <userinput>--all-databases --delete-master-logs > backup_sunday_1_PM.sql</userinput>
</programlisting>
<para>
@@ -19048,9 +19049,6 @@
--delete-master-logs</command> can be dangerous if your server
is a replication master server, because slave servers might
not yet fully have processed the contents of the binary log.
- </para>
-
- <para>
The description for the <literal>PURGE MASTER LOGS</literal>
statement explains what should be verified before deleting the
MySQL binary logs. See <xref linkend="purge-master-logs"/>.
@@ -19063,7 +19061,7 @@
<title>&title-backup-recovery;</title>
<para>
- Now suppose that we have a catastrophic crash on Wednesday at
+ Now, suppose that we have a catastrophic crash on Wednesday at
8 AM that requires recovery from backups. To recover, first we
restore the last full backup we have (the one from Sunday 1
PM). The full backup file is just a set of SQL statements, so
@@ -19077,7 +19075,7 @@
<para>
At this point, the data is restored to its state as of Sunday
1 PM. To restore the changes made since then, we must use the
- incremental backups, that is, the
+ incremental backups; that is, the
<filename>gbichot2-bin.000007</filename> and
<filename>gbichot2-bin.000008</filename> binary log files.
Fetch them if necessary from where they were backed up, and
Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/functions.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -5096,7 +5096,7 @@
<para>
Returns the natural logarithm of
- <replaceable>X</replaceable>, that is, the
+ <replaceable>X</replaceable>; that is, the
base-<emphasis>e</emphasis> logarithm of
<replaceable>X</replaceable>.
</para>
@@ -9162,7 +9162,7 @@
columns included in a <literal>FULLTEXT</literal> index. The
search string is given as the argument to
<literal>AGAINST()</literal>. For each row in the table,
- <literal>MATCH()</literal> returns a relevance value, that is, a
+ <literal>MATCH()</literal> returns a relevance value; that is, a
similarity measure between the search string and the text in that
row in the columns named in the <literal>MATCH()</literal> list.
</para>
@@ -10734,7 +10734,7 @@
</para>
<para>
- The stopword list is free-form, that is, you may use any
+ The stopword list is free-form. That is, you may use any
non-alphanumeric character such as newline, space, or comma
to separate stopwords. Exceptions are the underscore
character (<literal>_</literal>) and a single apostrophe
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/innodb.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -2484,7 +2484,7 @@
deletes, or updates many rows, <literal>InnoDB</literal> checks
<literal>UNIQUE</literal> and <literal>FOREIGN KEY</literal>
constraints row-by-row. According to the SQL standard, the
- default behavior should be deferred checking, that is,
+ default behavior should be deferred checking. That is,
constraints are only checked after the <emphasis>entire SQL
statement</emphasis> has been processed. Until
<literal>InnoDB</literal> implements deferred constraint
@@ -2742,7 +2742,7 @@
slave. If the <literal>innodb_file_per_table</literal> variable
is enabled, you must also copy the <filename>.ibd</filename>
files as well. For the proper procedure to do this, see
- <xref linkend="backing-up"/>.
+ <xref linkend="innodb-backup"/>.
</para>
<para>
@@ -2934,9 +2934,9 @@
</section>
- <section id="backing-up">
+ <section id="innodb-backup">
- <title>&title-backing-up;</title>
+ <title>&title-innodb-backup;</title>
<para>
The key to safe database management is making regular backups.
@@ -3311,8 +3311,8 @@
<literal>InnoDB</literal> data and log files are binary-compatible
on all platforms having the same floating-point number format. You
can move an <literal>InnoDB</literal> database simply by copying
- all the relevant files listed in <xref linkend="backing-up"/>. If
- the floating-point formats differ but you have not used
+ all the relevant files listed in <xref linkend="innodb-backup"/>.
+ If the floating-point formats differ but you have not used
<literal>FLOAT</literal> or <literal>DOUBLE</literal> data types
in your tables, then the procedure is the same: simply copy the
relevant files. If the formats differ and your tables contain
@@ -4081,8 +4081,8 @@
<para>
Suppose that you are running in the default <literal>REPEATABLE
- READ</literal> isolation level. When you issue a consistent
- read, that is, an ordinary <literal>SELECT</literal> statement,
+ READ</literal> isolation level. When you issue a consistent read
+ (that is, an ordinary <literal>SELECT</literal> statement),
<literal>InnoDB</literal> gives your transaction a timepoint
according to which your query sees the database. If another
transaction deletes a row and commits after your timepoint was
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/ndbcluster.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -8088,7 +8088,7 @@
command-line utility <command>ndb_restore</command>, which
reads the files created by the backup and inserts the stored
information into the database. The restore program must be
- executed once for each set of backup files, that is, as many
+ executed once for each set of backup files; that is, as many
times as there were database nodes running when the backup was
created.
</para>
Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/partitioning.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -695,7 +695,7 @@
number, you can use an expression based on one of the two
<literal>DATE</literal> columns instead. For example, let us
suppose that you wish to partition based on the year that each
- employee left the company, that is, the value of
+ employee left the company; that is, the value of
<literal>YEAR(separated)</literal>. An example of a
<literal>CREATE TABLE</literal> statement that implements such a
partitioning scheme is shown here:
Modified: trunk/refman-5.1/precision-math.xml
===================================================================
--- trunk/refman-5.1/precision-math.xml 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/precision-math.xml 2006-01-29 05:00:13 UTC (rev 1096)
@@ -69,10 +69,10 @@
</indexterm>
<para>
- MySQL ¤t-series; provides support for precision math, that is,
- numeric value handling that results in extremely accurate results
- and a high degree control over invalid values. Precision math is
- based on these two features:
+ MySQL ¤t-series; provides support for precision math: numeric
+ value handling that results in extremely accurate results and a high
+ degree control over invalid values. Precision math is based on these
+ two features:
</para>
<itemizedlist>
Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-5.1/renamed-nodes.txt 2006-01-29 05:00:13 UTC (rev 1096)
@@ -115,3 +115,4 @@
secure-grant grant
secure-requirements secure-using-openssl
information-schema-tables information-schema
+backing-up innodb-backup
Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent 2006-01-29 01:03:44 UTC (rev 1095)
+++ trunk/refman-common/titles.en.ent 2006-01-29 05:00:13 UTC (rev 1096)
@@ -52,7 +52,6 @@
<!ENTITY title-arithmetic-functions "Arithmetic Operators">
<!ENTITY title-asp "ASP and MySQL with MyODBC">
<!ENTITY title-automatic-start "Starting and Stopping MySQL Automatically">
-<!ENTITY title-backing-up "Backing Up and Recovering an <literal>InnoDB</literal> Database">
<!ENTITY title-backup "Database Backups">
<!ENTITY title-backup-policy "Backup Policy">
<!ENTITY title-backup-recovery "Using Backups for Recovery">
@@ -466,6 +465,7 @@
<!ENTITY title-innodb-and-autocommit "<literal>InnoDB</literal> and <literal>AUTOCOMMIT</literal>">
<!ENTITY title-innodb-and-mysql-replication "<literal>InnoDB</literal> and MySQL Replication">
<!ENTITY title-innodb-auto-increment-column "How <literal>AUTO_INCREMENT</literal> Columns Work in <literal>InnoDB</literal>">
+<!ENTITY title-innodb-backup "Backing Up and Recovering an <literal>InnoDB</literal> Database">
<!ENTITY title-innodb-change-history "Changes in <literal>InnoDB</literal>">
<!ENTITY title-innodb-checkpoints "Checkpoints">
<!ENTITY title-innodb-configuration "<literal>InnoDB</literal> Configuration">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1096 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 29 Jan |
