Author: paul
Date: 2006-02-19 05:22:32 +0100 (Sun, 19 Feb 2006)
New Revision: 1395
Log:
r7861@frost: paul | 2006-02-18 21:29:21 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/database-administration.xml
trunk/refman-4.1/installing.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.0/installing.xml
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/installing.xml
trunk/refman-common/news-5.1.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7854
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7861
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-4.1/database-administration.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -18603,7 +18603,7 @@
creates <filename>gbichot2-bin.000008</filename>. All changes
between the Sunday 1 p.m. full backup and Monday 1 p.m. will
be in the <filename>gbichot2-bin.000007</filename> file. This
- incremental backup is important, so it's a good idea to copy
+ incremental backup is important, so it is 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 at 1 p.m., execute
another <command>mysqladmin flush-logs</command> command. All
@@ -18659,8 +18659,8 @@
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
- then process their contents like this:
+ Fetch the files if necessary from where they were backed up,
+ and then process their contents like this:
</para>
<programlisting>
@@ -18673,14 +18673,14 @@
date of the crash. To not lose them, we would have needed to
have the MySQL server store its MySQL binary logs into a safe
location (RAID disks, SAN, ...) different from the place where
- it stores its data files, so that these logs were not in the
+ it stores its data files, so that these logs were not on the
destroyed disk. (That is, we can start the server with a
<option>--log-bin</option> option that specifies a location on
- a different physical device than the one on which the data
- directory resides. That way, the logs are not lost even if the
- device containing the directory is.) If we had done this, we
- would have the <filename>gbichot2-bin.000009</filename> file
- at hand, and we could apply it using
+ a different physical device from the one on which the data
+ directory resides. That way, the logs are safe even if the
+ device containing the directory is lost.) If we had done this,
+ we would have the <filename>gbichot2-bin.000009</filename>
+ file at hand, and we could apply it using
<command>mysqlbinlog</command> and <command>mysql</command> to
restore the most recent data changes with no loss up to the
moment of the crash.
@@ -18708,17 +18708,18 @@
<option>--log-bin=<replaceable>log_name</replaceable></option>,
where the log file name is located on some safe media
different from the drive on which the data directory is
- located. If you have such safe media, this can also be
- good for disk load balancing (which results in a
+ located. If you have such safe media, this technique can
+ also be good for disk load balancing (which results in a
performance improvement).
</para>
</listitem>
<listitem>
<para>
- Make periodic full backups, using the last
- <command>mysqldump</command> command given earlier that
- makes an online, non-blocking backup.
+ Make periodic full backups, using the
+ <command>mysqldump</command> command shown earlier in
+ <xref linkend="backup-policy"/>, that makes an online,
+ non-blocking backup.
</para>
</listitem>
@@ -18750,38 +18751,40 @@
</indexterm>
<para>
- If a MySQL server has binary logging enabled, you can use the
- <command>mysqlbinlog</command> utility to recover data starting
- from a specified point in time (for example, since your last
- backup) until the present or another specified point in time.
- For information on enabling the binary log and using
- <command>mysqlbinlog</command>, see
+ If a MySQL server was started with the
+ <option>--log-bin</option> option to enable binary logging, you
+ can use the <command>mysqlbinlog</command> utility to recover
+ data from the binary log files, starting from a specified point
+ in time (for example, since your last backup) until the present
+ or another specified point in time. For information on enabling
+ the binary log and using <command>mysqlbinlog</command>, see
<xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
</para>
<para>
- To restore data from a binary log, you will need to know the
- path and name of the current binary log file. The path can
- typically be found in the option file (that is,
- <filename>my.cnf</filename> or <filename>my.ini</filename>,
- depending on your system). If the path is not contained in the
- option file, it may be given as an option at the command-line
- when the server is started. The option for enabling binary
- logging is <option>--log-bin</option>. To determine the name of
- the current binary log file, issue the following statement:
+ To restore data from a binary log, you must know the location
+ and name of the current binary log file. By default, the server
+ creates binary log files in the data directory, but a pathname
+ can be specified with the <option>--log-bin</option> option to
+ place the files in a different location. Typically the option is
+ given in an option file (that is, <filename>my.cnf</filename> or
+ <filename>my.ini</filename>, depending on your system). It can
+ also be given on the command line when the server is started. To
+ determine the name of the current binary log file, issue the
+ following statement:
</para>
<programlisting>
-mysql> <userinput>SHOW BINLOG EVENTS \G</userinput>
+mysql> <userinput>SHOW BINLOG EVENTS\G</userinput>
</programlisting>
<para>
- If you prefer, you could execute the following command from the
+ If you prefer, you can execute the following command from the
command line instead:
</para>
<programlisting>
-shell> <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
+shell> <userinput>mysql -u root -p -E -e "SHOW BINLOG EVENTS"</userinput>
</programlisting>
<para>
@@ -18831,9 +18834,18 @@
<command>mysqlbinlog</command> commands restores everything up
until one second before 10:00 a.m. and everything from 10:01
a.m. on. You should examine the log to be sure of the exact
- times. The next section explains how to do this.
+ times to specify for the commands. To display the log file
+ contents without executing them, use this command:
</para>
+<programlisting>
+shell> <userinput>mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql</userinput>
+</programlisting>
+
+ <para>
+ Then open the file with a text editor to examine it.
+ </para>
+
</section>
<section id="point-in-time-recovery-positions">
@@ -18846,14 +18858,15 @@
<option>--stop-position</option> options for
<command>mysqlbinlog</command> can be used for specifying log
positions. They work the same as the start and stop date
- options, except that position numbers from the log are given.
- Using log positions may a be more accurate recovery method,
- especially if many transactions occurred around the same time
- as a damaging SQL statement. To determine the position
- numbers, you could run <command>mysqlbinlog</command> for a
- range of times near the time when the unwanted transaction was
- executed, but redirect the results to a text file for
- examination. This can be done like so:
+ options, except that you specify log position numbers rather
+ than dates. Using positions may enable you to be more precise
+ about which part of the log to recover, especially if many
+ transactions occurred around the same time as a damaging SQL
+ statement. To determine the position numbers, run
+ <command>mysqlbinlog</command> for a range of times near the
+ time when the unwanted transaction was executed, but redirect
+ the results to a text file for examination. This can be done
+ like so:
</para>
<programlisting>
@@ -18892,7 +18905,7 @@
<command>mysqlbinlog</command> includes <literal>SET
TIMESTAMP</literal> statements before each SQL statement
recorded, the recovered data and related MySQL logs will
- reflect the original times that the transactions were
+ reflect the original times at which the transactions were
executed.
</para>
Modified: trunk/refman-4.1/installing.xml
===================================================================
--- trunk/refman-4.1/installing.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-4.1/installing.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -12064,7 +12064,9 @@
<listitem>
<para>
If you are running MySQL Server on Windows, see
- <xref linkend="windows-upgrading"/>.
+ <xref linkend="windows-upgrading"/>. You should also be
+ aware that two of the Windows MySQL servers were renamed in
+ MySQL 4.1. See <xref linkend="windows-select-server"/>.
</para>
</listitem>
@@ -12523,7 +12525,7 @@
<listitem>
<para>
As of MySQL 4.1.10a, the server by default no longer loads
- user-defined functions unless they have at least one
+ user-defined functions (UDFs) unless they have at least one
auxiliary symbol defined in addition to the main function
symbol. This behavior can be overridden with the
<option>--allow-suspicious-udfs</option> option. See
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-5.0/database-administration.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -21127,7 +21127,7 @@
creates <filename>gbichot2-bin.000008</filename>. All changes
between the Sunday 1 p.m. full backup and Monday 1 p.m. will
be in the <filename>gbichot2-bin.000007</filename> file. This
- incremental backup is important, so it's a good idea to copy
+ incremental backup is important, so it is 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 at 1 p.m., execute
another <command>mysqladmin flush-logs</command> command. All
@@ -21183,8 +21183,8 @@
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
- then process their contents like this:
+ Fetch the files if necessary from where they were backed up,
+ and then process their contents like this:
</para>
<programlisting>
@@ -21197,14 +21197,14 @@
date of the crash. To not lose them, we would have needed to
have the MySQL server store its MySQL binary logs into a safe
location (RAID disks, SAN, ...) different from the place where
- it stores its data files, so that these logs were not in the
+ it stores its data files, so that these logs were not on the
destroyed disk. (That is, we can start the server with a
<option>--log-bin</option> option that specifies a location on
- a different physical device than the one on which the data
- directory resides. That way, the logs are not lost even if the
- device containing the directory is.) If we had done this, we
- would have the <filename>gbichot2-bin.000009</filename> file
- at hand, and we could apply it using
+ a different physical device from the one on which the data
+ directory resides. That way, the logs are safe even if the
+ device containing the directory is lost.) If we had done this,
+ we would have the <filename>gbichot2-bin.000009</filename>
+ file at hand, and we could apply it using
<command>mysqlbinlog</command> and <command>mysql</command> to
restore the most recent data changes with no loss up to the
moment of the crash.
@@ -21232,17 +21232,18 @@
<option>--log-bin=<replaceable>log_name</replaceable></option>,
where the log file name is located on some safe media
different from the drive on which the data directory is
- located. If you have such safe media, this can also be
- good for disk load balancing (which results in a
+ located. If you have such safe media, this technique can
+ also be good for disk load balancing (which results in a
performance improvement).
</para>
</listitem>
<listitem>
<para>
- Make periodic full backups, using the last
- <command>mysqldump</command> command given earlier that
- makes an online, non-blocking backup.
+ Make periodic full backups, using the
+ <command>mysqldump</command> command shown earlier in
+ <xref linkend="backup-policy"/>, that makes an online,
+ non-blocking backup.
</para>
</listitem>
@@ -21274,38 +21275,40 @@
</indexterm>
<para>
- If a MySQL server has binary logging enabled, you can use the
- <command>mysqlbinlog</command> utility to recover data starting
- from a specified point in time (for example, since your last
- backup) until the present or another specified point in time.
- For information on enabling the binary log and using
- <command>mysqlbinlog</command>, see
+ If a MySQL server was started with the
+ <option>--log-bin</option> option to enable binary logging, you
+ can use the <command>mysqlbinlog</command> utility to recover
+ data from the binary log files, starting from a specified point
+ in time (for example, since your last backup) until the present
+ or another specified point in time. For information on enabling
+ the binary log and using <command>mysqlbinlog</command>, see
<xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
</para>
<para>
- To restore data from a binary log, you will need to know the
- path and name of the current binary log file. The path can
- typically be found in the option file (that is,
- <filename>my.cnf</filename> or <filename>my.ini</filename>,
- depending on your system). If the path is not contained in the
- option file, it may be given as an option at the command-line
- when the server is started. The option for enabling binary
- logging is <option>--log-bin</option>. To determine the name of
- the current binary log file, issue the following statement:
+ To restore data from a binary log, you must know the location
+ and name of the current binary log file. By default, the server
+ creates binary log files in the data directory, but a pathname
+ can be specified with the <option>--log-bin</option> option to
+ place the files in a different location. Typically the option is
+ given in an option file (that is, <filename>my.cnf</filename> or
+ <filename>my.ini</filename>, depending on your system). It can
+ also be given on the command line when the server is started. To
+ determine the name of the current binary log file, issue the
+ following statement:
</para>
<programlisting>
-mysql> <userinput>SHOW BINLOG EVENTS \G</userinput>
+mysql> <userinput>SHOW BINLOG EVENTS\G</userinput>
</programlisting>
<para>
- If you prefer, you could execute the following command from the
+ If you prefer, you can execute the following command from the
command line instead:
</para>
<programlisting>
-shell> <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
+shell> <userinput>mysql -u root -p -E -e "SHOW BINLOG EVENTS"</userinput>
</programlisting>
<para>
@@ -21355,9 +21358,18 @@
<command>mysqlbinlog</command> commands restores everything up
until one second before 10:00 a.m. and everything from 10:01
a.m. on. You should examine the log to be sure of the exact
- times. The next section explains how to do this.
+ times to specify for the commands. To display the log file
+ contents without executing them, use this command:
</para>
+<programlisting>
+shell> <userinput>mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql</userinput>
+</programlisting>
+
+ <para>
+ Then open the file with a text editor to examine it.
+ </para>
+
</section>
<section id="point-in-time-recovery-positions">
@@ -21370,14 +21382,15 @@
<option>--stop-position</option> options for
<command>mysqlbinlog</command> can be used for specifying log
positions. They work the same as the start and stop date
- options, except that position numbers from the log are given.
- Using log positions may a be more accurate recovery method,
- especially if many transactions occurred around the same time
- as a damaging SQL statement. To determine the position
- numbers, you could run <command>mysqlbinlog</command> for a
- range of times near the time when the unwanted transaction was
- executed, but redirect the results to a text file for
- examination. This can be done like so:
+ options, except that you specify log position numbers rather
+ than dates. Using positions may enable you to be more precise
+ about which part of the log to recover, especially if many
+ transactions occurred around the same time as a damaging SQL
+ statement. To determine the position numbers, run
+ <command>mysqlbinlog</command> for a range of times near the
+ time when the unwanted transaction was executed, but redirect
+ the results to a text file for examination. This can be done
+ like so:
</para>
<programlisting>
@@ -21416,7 +21429,7 @@
<command>mysqlbinlog</command> includes <literal>SET
TIMESTAMP</literal> statements before each SQL statement
recorded, the recovered data and related MySQL logs will
- reflect the original times that the transactions were
+ reflect the original times at which the transactions were
executed.
</para>
Modified: trunk/refman-5.0/installing.xml
===================================================================
--- trunk/refman-5.0/installing.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-5.0/installing.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -11865,19 +11865,17 @@
<listitem>
<para>
If you are running MySQL Server on Windows, see
- <xref linkend="windows-upgrading"/>. You should also be
- aware that two of the Windows MySQL servers were renamed.
- See <xref linkend="windows-select-server"/>.
+ <xref linkend="windows-upgrading"/>.
</para>
</listitem>
<listitem>
<para>
MySQL ¤t-series; adds support for stored procedures.
- This support requires the <literal>proc</literal> table in
- the <literal>mysql</literal> database. To create this file,
- you should run the <command>mysql_upgrade</command> script
- as described in <xref linkend="mysql-upgrade"/>.
+ This support requires the <literal>mysql.proc</literal>
+ table. To create this table, you should run the
+ <command>mysql_upgrade</command> script as described in
+ <xref linkend="mysql-upgrade"/>.
</para>
</listitem>
@@ -11885,10 +11883,10 @@
<para>
MySQL ¤t-series; adds support for views. This support
requires extra privilege columns in the
- <literal>user</literal> and <literal>db</literal> tables in
- the <literal>mysql</literal> database. To create these
- columns, you should run the <command>mysql_upgrade</command>
- script as described in <xref linkend="mysql-upgrade"/>.
+ <literal>mysql.user</literal> and
+ <literal>mysql.db</literal> tables. To create these columns,
+ you should run the <command>mysql_upgrade</command> script
+ as described in <xref linkend="mysql-upgrade"/>.
</para>
</listitem>
@@ -11912,7 +11910,7 @@
<para>
The following lists describe changes that may affect
applications and that you should watch out for when upgrading to
- version ¤t-series;.
+ MySQL ¤t-series;.
</para>
<para>
@@ -11954,20 +11952,6 @@
<listitem>
<para>
- <emphasis role="bold">Incompatible change</emphasis>:
- <literal>MyISAM</literal> and <literal>InnoDB</literal>
- tables created with <literal>DECIMAL</literal> columns in
- MySQL 5.0.3 to 5.0.5 will appear corrupt after an upgrade to
- MySQL 5.0.6. Dump such tables with
- <command>mysqldump</command> before upgrading, and then
- reload them after upgrading. (The same incompatibility will
- occur for these tables created in MySQL 5.0.6 after a
- downgrade to MySQL 5.0.3 to 5.0.5.)
- </para>
- </listitem>
-
- <listitem>
- <para>
<emphasis role="bold">Incompatible change</emphasis>: The
implementation of <literal>DECIMAL</literal> has changed in
MySQL 5.0.3. You should make your applications aware of that
@@ -11998,9 +11982,23 @@
<listitem>
<para>
+ <emphasis role="bold">Incompatible change</emphasis>:
+ <literal>MyISAM</literal> and <literal>InnoDB</literal>
+ tables created with <literal>DECIMAL</literal> columns in
+ MySQL 5.0.3 to 5.0.5 will appear corrupt after an upgrade to
+ MySQL 5.0.6. Dump such tables with
+ <command>mysqldump</command> before upgrading, and then
+ reload them after upgrading. (The same incompatibility will
+ occur for these tables created in MySQL 5.0.6 after a
+ downgrade to MySQL 5.0.3 to 5.0.5.)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<emphasis role="bold">Incompatible change</emphasis>: As of
MySQL 5.0.3, the server by default no longer loads
- user-defined functions unless they have at least one
+ user-defined functions (UDFs) unless they have at least one
auxiliary symbol (for example, an
<literal>xxx_init</literal> or <literal>xxx_deinit</literal>
symbol) defined in addition to the main function symbol.
@@ -12013,8 +12011,8 @@
<listitem>
<para>
<emphasis role="bold">Incompatible change</emphasis>: The
- update log was removed in MySQL 5.0. If you had enabled it
- previously, you should enable the binary log instead.
+ update log has been removed in MySQL 5.0. If you had enabled
+ it previously, you should enable the binary log instead.
</para>
</listitem>
@@ -12033,10 +12031,11 @@
<emphasis role="bold">Incompatible change:</emphasis>
Support for the <literal>ISAM</literal> storage engine has
- been removed. If you have any <literal>ISAM</literal>
- tables, you should convert them before upgrading. For
- example, to convert an <literal>ISAM</literal> table to use
- the <literal>MyISAM</literal> storage engine, use this
+ been removed in MySQL 5.0. If you have any
+ <literal>ISAM</literal> tables, you should convert them
+ <emphasis>before</emphasis> upgrading. For example, to
+ convert an <literal>ISAM</literal> table to use the
+ <literal>MyISAM</literal> storage engine, use this
statement:
</para>
@@ -12065,7 +12064,7 @@
<emphasis role="bold">Incompatible change</emphasis>:
Support for <literal>RAID</literal> options in
- <literal>MyISAM</literal> tables has been removed from MySQL
+ <literal>MyISAM</literal> tables has been removed in MySQL
5.0. If you have tables that use these options, you should
convert them before upgrading. One way to do this is to dump
them with <command>mysqldump</command>, edit the dump file
@@ -12074,7 +12073,7 @@
dump file. Another possibility is to use <literal>CREATE
TABLE <replaceable>new_tbl</replaceable> ... SELECT
<replaceable>raid_tbl</replaceable></literal> to create a
- new tablefrom the <literal>RAID</literal> table. However,
+ new table from the <literal>RAID</literal> table. However,
the <literal>CREATE TABLE</literal> part of the statement
must contain sufficient information to re-create column
attributes as well as indexes, or column attributes may be
@@ -12194,7 +12193,7 @@
<para>
The statement uses <literal>INTO OUTFILE</literal>, so
you must have the <literal>FILE</literal> privilege. The
- file will be created on the server host; use a different
+ file will be created on the server host. Use a different
filename if you like. To be 100% safe, inspect the
trigger definitions in the
<filename>triggers.sql</filename> file, and perhaps make
@@ -12218,8 +12217,9 @@
<listitem>
<para>
Start the server and re-create all triggers using the
- <filename>triggers.sql</filename> file: For example in
- my case it was:
+ <filename>triggers.sql</filename> file. For the file
+ created earlier, use these commands in the
+ <command>mysql</command> program:
</para>
<programlisting>
@@ -12230,8 +12230,8 @@
<listitem>
<para>
- Check that all triggers were successfully created using
- the <filename>SHOW TRIGGERS</filename> statement.
+ Use the <filename>SHOW TRIGGERS</filename> statement to
+ check that all triggers were created successfully.
</para>
</listitem>
@@ -12294,14 +12294,14 @@
<listitem>
<para>
- <literal>CREATE TABLE … SELECT
- CHAR(…)</literal> produces a
- <literal>VARBINARY</literal> column, not a
+ <literal>CREATE TABLE ... SELECT CHAR(...)</literal>
+ produces a <literal>VARBINARY</literal> column, not a
<literal>VARCHAR</literal> column. To produce a
<literal>VARCHAR</literal> column, use
<literal>USING</literal> or <literal>CONVERT()</literal>
- to convert the <literal>CHAR()</literal> result into a
- non-binary character set as just described.
+ as just described to convert the
+ <literal>CHAR()</literal> result into a non-binary
+ character set.
</para>
</listitem>
@@ -12337,7 +12337,8 @@
<literal>NATURAL</literal> joins and joins specified with a
<literal>USING</literal> clause and proper ordering of
output columns. The precedence of the comma operator also
- now is lower compared to <literal>JOIN</literal>.
+ now is lower compared to <literal>JOIN</literal>,
+ <literal>LEFT JOIN</literal>, and so forth.
</para>
<para>
@@ -12389,9 +12390,9 @@
<listitem>
<para>
- <literal>DECIMAL</literal> columns now are stored in a more
- efficient format. To convert a table to use the new
- <literal>DECIMAL</literal> type, you should do an
+ As of MySQL 5.0.3, <literal>DECIMAL</literal> columns are
+ stored in a more efficient format. To convert a table to use
+ the new <literal>DECIMAL</literal> type, you should do an
<literal>ALTER TABLE</literal> on it. The <literal>ALTER
TABLE</literal> also will change the table's
<literal>VARCHAR</literal> columns to use the new
@@ -12418,7 +12419,7 @@
imprecise in all MySQL versions, and you are
<emphasis>strongly advised</emphasis> to avoid such
comparisons as <literal>WHERE
- <replaceable>column</replaceable>=<replaceable>some_double</replaceable></literal>,
+ <replaceable>col_name</replaceable>=<replaceable>some_double</replaceable></literal>,
<emphasis>regardless of the MySQL version you are
using</emphasis>. See <xref linkend="problems-with-float"/>.
</para>
@@ -12440,7 +12441,7 @@
<literal>VARBINARY</literal> columns in MySQL 5.0.3 or
later, the table will not be usable if you downgrade to a
version older than 5.0.3. Dump the table before downgrading
- and then reload it after downgrading.
+ and reload it after downgrading.
</para>
</listitem>
@@ -12474,7 +12475,7 @@
<literal>DATABASES</literal>, respectively. (While
<quote>schemata</quote> is grammatically correct and even
appears in some MySQL 5.0 system database and table names,
- it cannot be used as a key word for input.)
+ it cannot be used as a keyword for input.)
</para>
</listitem>
@@ -12503,21 +12504,6 @@
</para>
</listitem>
- <listitem>
- <para>
- A new startup option named
- <option>innodb_table_locks</option> was added that causes
- <literal>LOCK TABLE</literal> to also acquire
- <literal>InnoDB</literal> table locks. This option is
- enabled by default. This can cause deadlocks in applications
- that use <literal>AUTOCOMMIT=1</literal> and <literal>LOCK
- TABLES</literal>. If you application encounters deadlocks
- after upgrading, you may need to add
- <literal>innodb_table_locks=0</literal> to your
- <filename>my.cnf</filename> file.
- </para>
- </listitem>
-
</itemizedlist>
<para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-5.1/database-administration.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -20967,7 +20967,7 @@
creates <filename>gbichot2-bin.000008</filename>. All changes
between the Sunday 1 p.m. full backup and Monday 1 p.m. will
be in the <filename>gbichot2-bin.000007</filename> file. This
- incremental backup is important, so it's a good idea to copy
+ incremental backup is important, so it is 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 at 1 p.m., execute
another <command>mysqladmin flush-logs</command> command. All
@@ -21023,8 +21023,8 @@
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
- then process their contents like this:
+ Fetch the files if necessary from where they were backed up,
+ and then process their contents like this:
</para>
<programlisting>
@@ -21037,14 +21037,14 @@
date of the crash. To not lose them, we would have needed to
have the MySQL server store its MySQL binary logs into a safe
location (RAID disks, SAN, ...) different from the place where
- it stores its data files, so that these logs were not in the
+ it stores its data files, so that these logs were not on the
destroyed disk. (That is, we can start the server with a
<option>--log-bin</option> option that specifies a location on
- a different physical device than the one on which the data
- directory resides. That way, the logs are not lost even if the
- device containing the directory is.) If we had done this, we
- would have the <filename>gbichot2-bin.000009</filename> file
- at hand, and we could apply it using
+ a different physical device from the one on which the data
+ directory resides. That way, the logs are safe even if the
+ device containing the directory is lost.) If we had done this,
+ we would have the <filename>gbichot2-bin.000009</filename>
+ file at hand, and we could apply it using
<command>mysqlbinlog</command> and <command>mysql</command> to
restore the most recent data changes with no loss up to the
moment of the crash.
@@ -21072,17 +21072,18 @@
<option>--log-bin=<replaceable>log_name</replaceable></option>,
where the log file name is located on some safe media
different from the drive on which the data directory is
- located. If you have such safe media, this can also be
- good for disk load balancing (which results in a
+ located. If you have such safe media, this technique can
+ also be good for disk load balancing (which results in a
performance improvement).
</para>
</listitem>
<listitem>
<para>
- Make periodic full backups, using the last
- <command>mysqldump</command> command given earlier that
- makes an online, non-blocking backup.
+ Make periodic full backups, using the
+ <command>mysqldump</command> command shown earlier in
+ <xref linkend="backup-policy"/>, that makes an online,
+ non-blocking backup.
</para>
</listitem>
@@ -21114,38 +21115,40 @@
</indexterm>
<para>
- If a MySQL server has binary logging enabled, you can use the
- <command>mysqlbinlog</command> utility to recover data starting
- from a specified point in time (for example, since your last
- backup) until the present or another specified point in time.
- For information on enabling the binary log and using
- <command>mysqlbinlog</command>, see
+ If a MySQL server was started with the
+ <option>--log-bin</option> option to enable binary logging, you
+ can use the <command>mysqlbinlog</command> utility to recover
+ data from the binary log files, starting from a specified point
+ in time (for example, since your last backup) until the present
+ or another specified point in time. For information on enabling
+ the binary log and using <command>mysqlbinlog</command>, see
<xref linkend="binary-log"/>, and <xref linkend="mysqlbinlog"/>.
</para>
<para>
- To restore data from a binary log, you will need to know the
- path and name of the current binary log file. The path can
- typically be found in the option file (that is,
- <filename>my.cnf</filename> or <filename>my.ini</filename>,
- depending on your system). If the path is not contained in the
- option file, it may be given as an option at the command-line
- when the server is started. The option for enabling binary
- logging is <option>--log-bin</option>. To determine the name of
- the current binary log file, issue the following statement:
+ To restore data from a binary log, you must know the location
+ and name of the current binary log file. By default, the server
+ creates binary log files in the data directory, but a pathname
+ can be specified with the <option>--log-bin</option> option to
+ place the files in a different location. Typically the option is
+ given in an option file (that is, <filename>my.cnf</filename> or
+ <filename>my.ini</filename>, depending on your system). It can
+ also be given on the command line when the server is started. To
+ determine the name of the current binary log file, issue the
+ following statement:
</para>
<programlisting>
-mysql> <userinput>SHOW BINLOG EVENTS \G</userinput>
+mysql> <userinput>SHOW BINLOG EVENTS\G</userinput>
</programlisting>
<para>
- If you prefer, you could execute the following command from the
+ If you prefer, you can execute the following command from the
command line instead:
</para>
<programlisting>
-shell> <userinput>mysql --user=root -p -E -e "SHOW BINLOG EVENTS"</userinput>
+shell> <userinput>mysql -u root -p -E -e "SHOW BINLOG EVENTS"</userinput>
</programlisting>
<para>
@@ -21195,9 +21198,18 @@
<command>mysqlbinlog</command> commands restores everything up
until one second before 10:00 a.m. and everything from 10:01
a.m. on. You should examine the log to be sure of the exact
- times. The next section explains how to do this.
+ times to specify for the commands. To display the log file
+ contents without executing them, use this command:
</para>
+<programlisting>
+shell> <userinput>mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql</userinput>
+</programlisting>
+
+ <para>
+ Then open the file with a text editor to examine it.
+ </para>
+
</section>
<section id="point-in-time-recovery-positions">
@@ -21210,14 +21222,15 @@
<option>--stop-position</option> options for
<command>mysqlbinlog</command> can be used for specifying log
positions. They work the same as the start and stop date
- options, except that position numbers from the log are given.
- Using log positions may a be more accurate recovery method,
- especially if many transactions occurred around the same time
- as a damaging SQL statement. To determine the position
- numbers, you could run <command>mysqlbinlog</command> for a
- range of times near the time when the unwanted transaction was
- executed, but redirect the results to a text file for
- examination. This can be done like so:
+ options, except that you specify log position numbers rather
+ than dates. Using positions may enable you to be more precise
+ about which part of the log to recover, especially if many
+ transactions occurred around the same time as a damaging SQL
+ statement. To determine the position numbers, run
+ <command>mysqlbinlog</command> for a range of times near the
+ time when the unwanted transaction was executed, but redirect
+ the results to a text file for examination. This can be done
+ like so:
</para>
<programlisting>
@@ -21256,7 +21269,7 @@
<command>mysqlbinlog</command> includes <literal>SET
TIMESTAMP</literal> statements before each SQL statement
recorded, the recovered data and related MySQL logs will
- reflect the original times that the transactions were
+ reflect the original times at which the transactions were
executed.
</para>
Modified: trunk/refman-5.1/installing.xml
===================================================================
--- trunk/refman-5.1/installing.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-5.1/installing.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -11866,10 +11866,10 @@
<listitem>
<para>
<emphasis role="bold">Incompatible change</emphasis>: The
- <literal>table_cache</literal> system variable was renamed
- to <literal>table_open_cache</literal>. Any scripts that
- refer to <literal>table_cache</literal> should be updated to
- use the new name.
+ <literal>table_cache</literal> system variable has been
+ renamed to <literal>table_open_cache</literal>. Any scripts
+ that refer to <literal>table_cache</literal> should be
+ updated to use the new name.
</para>
</listitem>
@@ -12031,7 +12031,7 @@
<listitem>
<para>
<emphasis role="bold">Incompatible change</emphasis>: MySQL
- 5.1.6 introduced the <literal>TRIGGER</literal> privilege.
+ 5.1.6 introduces the <literal>TRIGGER</literal> privilege.
Previously, the <literal>SUPER</literal> privilege was
needed to create or drop triggers. Now those operations
require the <literal>TRIGGER</literal> privilege. This is a
@@ -12041,15 +12041,16 @@
account named in a trigger's <literal>DEFINER</literal>
clause must have the <literal>SUPER</literal> privilege has
changed to a requirement for the <literal>TRIGGER</literal>
- privilege. When upgrading from a previous version of MySQL 5
- to MySQL 5.1.6 or newer, be sure to update your grant tables
- as described in <xref linkend="mysql-upgrade"/>. This
- process will assign the <literal>TRIGGER</literal> privilege
- to all accounts that had the <literal>SUPER</literal>
- privilege. If you fail to update the grant tables, triggers
- may fail when activated. After updating the grant tables,
- you can revoke the <literal>SUPER</literal> privilege from
- those accounts that no longer otherwise require it.
+ privilege. When upgrading from a previous version of MySQL
+ 5.0 or 5.1 to MySQL 5.1.6 or newer, be sure to update your
+ grant tables as described in
+ <xref linkend="mysql-upgrade"/>. This process assigns the
+ <literal>TRIGGER</literal> privilege to all accounts that
+ had the <literal>SUPER</literal> privilege. If you fail to
+ update the grant tables, triggers may fail when activated.
+ (After updating the grant tables, you can revoke the
+ <literal>SUPER</literal> privilege from those accounts that
+ no longer otherwise require it.)
</para>
</listitem>
Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml 2006-02-19 01:29:07 UTC (rev 1394)
+++ trunk/refman-common/news-5.1.xml 2006-02-19 04:22:32 UTC (rev 1395)
@@ -507,7 +507,7 @@
<listitem>
<para>
<emphasis role="bold">Incompatible change</emphasis>: This
- release introduced the <literal>TRIGGER</literal> privilege.
+ release introduces the <literal>TRIGGER</literal> privilege.
Previously, the <literal>SUPER</literal> privilege was needed
to create or drop triggers. Now those operations require the
<literal>TRIGGER</literal> privilege. This is a security
@@ -519,10 +519,10 @@
requirement for the <literal>TRIGGER</literal> privilege.
After upgrading, be sure to update your grant tables as
described in <xref linkend="mysql-fix-privilege-tables"/>.
- This process will assign the <literal>TRIGGER</literal>
- privilege to all accounts that had the
- <literal>SUPER</literal> privilege. (After updating, you might
- also consider whether any of those accounts no longer need
+ This process assigns the <literal>TRIGGER</literal> privilege
+ to all accounts that had the <literal>SUPER</literal>
+ privilege. (After updating, you might also consider whether
+ any of those accounts no longer need
<literal>SUPER</literal>.) If you fail to update the grant
tables, triggers may fail when activated. (Bug #9142)
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1395 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-common | paul | 19 Feb |
