Author: paul
Date: 2008-11-05 23:01:35 +0100 (Wed, 05 Nov 2008)
New Revision: 12299
Log:
r35329@frost: paul | 2008-11-05 16:02:24 -0500
General InnoDB revisions
Modified:
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-6.0/se-innodb-core.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35328
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:39854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:35329
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:34100
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2008-11-05 22:01:26 UTC (rev 12298)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-11-05 22:01:35 UTC (rev 12299)
Changed blocks: 12, Lines Added: 47, Lines Deleted: 52; 9382 bytes
@@ -2468,11 +2468,16 @@
<listitem>
<para>
- In the referencing table, there must be an index where the
- foreign key columns are listed as the
- <emphasis>first</emphasis> columns in the same order.
- Starting with MySQL 4.1.2, such an index is created on the
- referencing table automatically if it does not exist, and
+ <literal>InnoDB</literal> requires indexes on foreign keys
+ and referenced keys so that foreign key checks can be fast
+ and not require a table scan. In the referencing table,
+ there must be an index where the foreign key columns are
+ listed as the <emphasis>first</emphasis> columns in the same
+ order. Such an index is created on the referencing table
+ automatically if it does not exist. (This is in contrast to
+ versions older than MySQL 4.1.2, in which indexes had to be
+ created explicitly or the creation of foreign key
+ constraints would fail.)
<replaceable>index_name</replaceable>, if given, is used as
described previously.
</para>
@@ -2494,7 +2499,7 @@
consequence of this is that
<literal role="type">BLOB</literal> and
<literal role="type">TEXT</literal> columns cannot be
- included in a foreign key, because indexes on those columns
+ included in a foreign key because indexes on those columns
must always include a prefix length.
</para>
</listitem>
@@ -2609,22 +2614,12 @@
</itemizedlist>
<para>
- Note that <literal>InnoDB</literal> supports foreign key
- references within a table. In these cases, <quote>child table
- records</quote> really refers to dependent records within the
- same table.
+ <literal>InnoDB</literal> supports foreign key references within
+ a table. In these cases, <quote>child table records</quote>
+ really refers to dependent records within the same table.
</para>
<para>
- <literal>InnoDB</literal> requires indexes on foreign keys and
- referenced keys so that foreign key checks can be fast and not
- require a table scan. Starting with MySQL 4.1.2, the index on
- the foreign key is created automatically if no index on the key
- columns exists. In older versions, the indexes must be created
- explicitly or the creation of foreign key constraints fails.
- </para>
-
- <para>
Here is a simple example that relates <literal>parent</literal>
and <literal>child</literal> tables through a single-column
foreign key:
@@ -2687,10 +2682,10 @@
</programlisting>
<para>
- <emphasis role="bold">Remember to create the required indexes
- first</emphasis>. You can also add a self-referential foreign
- key constraint to a table using <literal role="stmt">ALTER
- TABLE</literal>.
+ The foreign key can be self referential (referring to the same
+ table). When you add a foreign key constraint to a table using
+ <literal role="stmt">ALTER TABLE</literal>, <emphasis>remember
+ to create the required indexes first.</emphasis>
</para>
<indexterm>
@@ -2810,7 +2805,7 @@
<para>
<command>mysqldump</command> also produces correct definitions
- of tables to the dump file, and does not forget about the
+ of tables in the dump file, and does not forget about the
foreign keys.
</para>
@@ -2887,16 +2882,16 @@
referencing it. It must have the right column names and types,
and it must have indexes on the referenced keys, as stated
earlier. If these are not satisfied, MySQL returns error number
- 1005 and refers to errno 150 in the error message.
+ 1005 and refers to error 150 in the error message.
</para>
<para>
If MySQL reports an error number 1005 from a
<literal role="stmt">CREATE TABLE</literal> statement, and the
- error message refers to errno 150, table creation failed because
+ error message refers to error 150, table creation failed because
a foreign key constraint was not correctly formed. Similarly, if
an <literal role="stmt">ALTER TABLE</literal> fails and it
- refers to errno 150, that means a foreign key definition would
+ refers to error 150, that means a foreign key definition would
be incorrectly formed for the altered table. Starting from MySQL
4.0.13, you can use <literal role="stmt">SHOW INNODB
STATUS</literal> to display a detailed explanation of the latest
@@ -2966,8 +2961,8 @@
<literal>DB_ROLL_PTR</literal> and
<literal>DB_MIX_ID</literal>). In versions of MySQL before
4.1.19 this would cause a crash, since 4.1.19 the server will
- report error 1005 and refers to <literal>errno</literal> -1 in
- the error message.
+ report error 1005 and refers to error −1 in the error
+ message.
</para>
<para>
@@ -3146,13 +3141,12 @@
<para>
Cascading actions for <literal>InnoDB</literal> tables on the
- master are replicated to the slave <emphasis>only</emphasis>
- if both the master's and slave' versions of the
- tables sharing the foreign key relation use
- <literal>InnoDB</literal>. For example, suppose you have
- started replication, and then create two tables on the master
- using the following <literal role="stmt">CREATE
- TABLE</literal> statements:
+ master are replicated on the slave <emphasis>only</emphasis>
+ if the tables sharing the foreign key relation use
+ <literal>InnoDB</literal> on both the master and slave. For
+ example, suppose you have started replication, and then create
+ two tables on the master using the following
+ <literal role="stmt">CREATE TABLE</literal> statements:
<programlisting>
CREATE TABLE fc1 (
@@ -3250,9 +3244,12 @@
1 row in set (0.00 sec)
</programlisting>
- However, the cascade does not propagate to the slave. The
- slave's copy of <literal>fc2</literal> still contains all
- of the rows that were originally inserted:
+ However, the cascade does not propagate on the slave because
+ on the slave the <literal role="stmt">DELETE</literal> for
+ <literal>fc1</literal> deletes no rows from
+ <literal>fc2</literal>. The slave's copy of
+ <literal>fc2</literal> still contains all of the rows that
+ were originally inserted:
<programlisting>
slave> <userinput>SELECT * FROM fc2;</userinput>
@@ -3440,11 +3437,11 @@
you to shut down your database and it does not set any locks or
disturb your normal database processing. <command>InnoDB Hot
Backup</command> is a non-free (commercial) add-on tool with an
- annual license fee of €390 per computer on which the MySQL
- server is run. See the
+ annual license fee per computer on which the MySQL server is run.
+ See the
<ulink url="http://www.innodb.com/hot-backup"><command>InnoDB Hot
- Backup</command> home page</ulink> for detailed information and
- screenshots.
+ Backup</command> home page</ulink> for detailed information,
+ screenshots, and licensing information.
</para>
<para>
@@ -3509,21 +3506,19 @@
the chance for serious data corruption is smaller.
<command>mysqldump</command> also has a
<option>--single-transaction</option> option that you can use to
- make a consistent snapshot without locking out other clients.
+ make a consistent snapshot without locking out other clients. See
+ <xref linkend="backup-policy"/>.
</para>
<para>
To be able to recover your <literal>InnoDB</literal> database to
the present from the binary backup just described, you have to run
- your MySQL server with binary logging turned on. Then you can
- apply the binary log to the backup database to achieve
- point-in-time recovery:
+ your MySQL server with binary logging turned on. To achieve
+ point-in-time recovery after restoring a backup, you can apply
+ changes from the binary log that occurred after the backup was
+ made. See See <xref linkend="point-in-time-recovery"/>.
</para>
-<programlisting>
-mysqlbinlog <replaceable>yourhostname</replaceable>-bin.123 | mysql
-</programlisting>
-
<para>
To recover from a crash of your MySQL server, the only requirement
is to restart it. <literal>InnoDB</literal> automatically checks
@@ -3564,7 +3559,7 @@
first find a backup that is not corrupted. After restoring the
base backup, do the recovery from the binary log files using
<command>mysqlbinlog</command> and <command>mysql</command> to
- restore the changes performed after the backup was made.
+ restore the changes that occurred after the backup was made.
</para>
<para>
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-11-05 22:01:26 UTC (rev 12298)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-11-05 22:01:35 UTC (rev 12299)
Changed blocks: 15, Lines Added: 60, Lines Deleted: 67; 11788 bytes
@@ -2583,12 +2583,17 @@
<listitem>
<para>
- In the referencing table, there must be an index where the
- foreign key columns are listed as the
- <emphasis>first</emphasis> columns in the same order. Such
- an index is created on the referencing table automatically
- if it does not exist. <replaceable>index_name</replaceable>,
- if given, is used as described previously.
+ <literal>InnoDB</literal> requires indexes on foreign keys
+ and referenced keys so that foreign key checks can be fast
+ and not require a table scan. In the referencing table,
+ there must be an index where the foreign key columns are
+ listed as the <emphasis>first</emphasis> columns in the same
+ order. Such an index is created on the referencing table
+ automatically if it does not exist. (This is in contrast to
+ some older versions, in which indexes had to be created
+ explicitly or the creation of foreign key constraints would
+ fail.) <replaceable>index_name</replaceable>, if given, is
+ used as described previously.
</para>
</listitem>
@@ -2608,7 +2613,7 @@
consequence of this is that
<literal role="type">BLOB</literal> and
<literal role="type">TEXT</literal> columns cannot be
- included in a foreign key, because indexes on those columns
+ included in a foreign key because indexes on those columns
must always include a prefix length.
</para>
</listitem>
@@ -2728,23 +2733,12 @@
</itemizedlist>
<para>
- Note that <literal>InnoDB</literal> supports foreign key
- references within a table. In these cases, <quote>child table
- records</quote> really refers to dependent records within the
- same table.
+ <literal>InnoDB</literal> supports foreign key references within
+ a table. In these cases, <quote>child table records</quote>
+ really refers to dependent records within the same table.
</para>
<para>
- <literal>InnoDB</literal> requires indexes on foreign keys and
- referenced keys so that foreign key checks can be fast and not
- require a table scan. The index on the foreign key is created
- automatically if no index on the key columns exists. This is in
- contrast to some older versions, in which indexes had to be
- created explicitly or the creation of foreign key constraints
- would fail.
- </para>
-
- <para>
Here is a simple example that relates <literal>parent</literal>
and <literal>child</literal> tables through a single-column
foreign key:
@@ -2807,10 +2801,10 @@
</programlisting>
<para>
- <emphasis role="bold">Remember to create the required indexes
- first</emphasis>. You can also add a self-referential foreign
- key constraint to a table using <literal role="stmt">ALTER
- TABLE</literal>.
+ The foreign key can be self referential (referring to the same
+ table). When you add a foreign key constraint to a table using
+ <literal role="stmt">ALTER TABLE</literal>, <emphasis>remember
+ to create the required indexes first.</emphasis>
</para>
<indexterm>
@@ -2828,7 +2822,7 @@
</indexterm>
<para>
- <literal>InnoDB</literal> also supports the use of
+ <literal>InnoDB</literal> supports the use of
<literal role="stmt">ALTER TABLE</literal> to drop foreign keys:
</para>
@@ -2909,7 +2903,7 @@
<para>
<command>mysqldump</command> also produces correct definitions
- of tables to the dump file, and does not forget about the
+ of tables in the dump file, and does not forget about the
foreign keys.
</para>
@@ -2983,16 +2977,16 @@
referencing it. It must have the right column names and types,
and it must have indexes on the referenced keys, as stated
earlier. If these are not satisfied, MySQL returns error number
- 1005 and refers to errno 150 in the error message.
+ 1005 and refers to error 150 in the error message.
</para>
<para>
If MySQL reports an error number 1005 from a
<literal role="stmt">CREATE TABLE</literal> statement, and the
- error message refers to errno 150, table creation failed because
+ error message refers to error 150, table creation failed because
a foreign key constraint was not correctly formed. Similarly, if
an <literal role="stmt">ALTER TABLE</literal> fails and it
- refers to errno 150, that means a foreign key definition would
+ refers to error 150, that means a foreign key definition would
be incorrectly formed for the altered table. You can use
<literal>SHOW ENGINE INNODB STATUS</literal> to display a
detailed explanation of the most recent
@@ -3189,13 +3183,12 @@
<para>
Cascading actions for <literal>InnoDB</literal> tables on the
- master are replicated to the slave <emphasis>only</emphasis>
- if both the master's and slave' versions of the
- tables sharing the foreign key relation use
- <literal>InnoDB</literal>. For example, suppose you have
- started replication, and then create two tables on the master
- using the following <literal role="stmt">CREATE
- TABLE</literal> statements:
+ master are replicated on the slave <emphasis>only</emphasis>
+ if the tables sharing the foreign key relation use
+ <literal>InnoDB</literal> on both the master and slave. For
+ example, suppose you have started replication, and then create
+ two tables on the master using the following
+ <literal role="stmt">CREATE TABLE</literal> statements:
<programlisting>
CREATE TABLE fc1 (
@@ -3293,9 +3286,12 @@
1 row in set (0.00 sec)
</programlisting>
- However, the cascade does not propagate to the slave. The
- slave's copy of <literal>fc2</literal> still contains all
- of the rows that were originally inserted:
+ However, the cascade does not propagate on the slave because
+ on the slave the <literal role="stmt">DELETE</literal> for
+ <literal>fc1</literal> deletes no rows from
+ <literal>fc2</literal>. The slave's copy of
+ <literal>fc2</literal> still contains all of the rows that
+ were originally inserted:
<programlisting>
slave> <userinput>SELECT * FROM fc2;</userinput>
@@ -3464,12 +3460,12 @@
<listitem>
<para>
If <literal>innodb_fast_shutdown</literal> is not set to 2:
- You must stop the MySQL server and make sure that it shuts
- down without errors (to ensure that there is no information
- for outstanding transactions in the logs). Then copy the old
- log files into a safe place just in case something went wrong
- in the shutdown and you need them to recover the tablespace.
- Delete the old log files from the log file directory, edit
+ Stop the MySQL server and make sure that it shuts down without
+ errors (to ensure that there is no information for outstanding
+ transactions in the logs). Then copy the old log files into a
+ safe place just in case something went wrong in the shutdown
+ and you need them to recover the tablespace. Delete the old
+ log files from the log file directory, edit
<filename>my.cnf</filename> to change the log file
configuration, and start the MySQL server again.
<command>mysqld</command> sees that no log files exist at
@@ -3479,12 +3475,11 @@
<listitem>
<para>
- If <literal>innodb_fast_shutdown</literal> is set to 2: You
- should shut down the server, set
- <literal>innodb_fast_shutdown</literal> to 1, and restart the
- server. The server should be allowed to recover. Then you
- should shut down the server again and follow the procedure
- described in the preceding item to change
+ If <literal>innodb_fast_shutdown</literal> is set to 2: Shut
+ down the server, set <literal>innodb_fast_shutdown</literal>
+ to 1, and restart the server. The server should be allowed to
+ recover. Then you should shut down the server again and follow
+ the procedure described in the preceding item to change
<literal>InnoDB</literal> log file size. Set
<literal>innodb_fast_shutdown</literal> back to 2 and restart
the server.
@@ -3510,11 +3505,11 @@
you to shut down your database and it does not set any locks or
disturb your normal database processing. <command>InnoDB Hot
Backup</command> is a non-free (commercial) add-on tool with an
- annual license fee of €390 per computer on which the MySQL
- server is run. See the
+ annual license fee per computer on which the MySQL server is run.
+ See the
<ulink url="http://www.innodb.com/hot-backup"><command>InnoDB Hot
- Backup</command> home page</ulink> for detailed information and
- screenshots.
+ Backup</command> home page</ulink> for detailed information,
+ screenshots, and licensing information.
</para>
<para>
@@ -3579,21 +3574,19 @@
the chance for serious data corruption is smaller.
<command>mysqldump</command> also has a
<option>--single-transaction</option> option that you can use to
- make a consistent snapshot without locking out other clients.
+ make a consistent snapshot without locking out other clients. See
+ <xref linkend="backup-policy"/>.
</para>
<para>
To be able to recover your <literal>InnoDB</literal> database to
the present from the binary backup just described, you have to run
- your MySQL server with binary logging turned on. Then you can
- apply the binary log to the backup database to achieve
- point-in-time recovery:
+ your MySQL server with binary logging turned on. To achieve
+ point-in-time recovery after restoring a backup, you can apply
+ changes from the binary log that occurred after the backup was
+ made. See See <xref linkend="point-in-time-recovery"/>.
</para>
-<programlisting>
-mysqlbinlog <replaceable>yourhostname</replaceable>-bin.123 | mysql
-</programlisting>
-
<para>
To recover from a crash of your MySQL server, the only requirement
is to restart it. <literal>InnoDB</literal> automatically checks
@@ -3634,7 +3627,7 @@
first find a backup that is not corrupted. After restoring the
base backup, do the recovery from the binary log files using
<command>mysqlbinlog</command> and <command>mysql</command> to
- restore the changes performed after the backup was made.
+ restore the changes that occurred after the backup was made.
</para>
<para>
@@ -7792,8 +7785,8 @@
<literal>DB_ROLL_PTR</literal> and
<literal>DB_MIX_ID</literal>). In versions of MySQL before
5.0.21 this would cause a crash, since 5.0.21 the server will
- report error 1005 and refers to <literal>errno</literal> -1 in
- the error message.
+ report error 1005 and refers to error −1 in the error
+ message.
</para>
</listitem>
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-11-05 22:01:26 UTC (rev 12298)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-11-05 22:01:35 UTC (rev 12299)
Changed blocks: 15, Lines Added: 62, Lines Deleted: 68; 11951 bytes
@@ -3269,12 +3269,17 @@
<listitem>
<para>
- In the referencing table, there must be an index where the
- foreign key columns are listed as the
- <emphasis>first</emphasis> columns in the same order. Such
- an index is created on the referencing table automatically
- if it does not exist. <replaceable>index_name</replaceable>,
- if given, is used as described previously.
+ <literal>InnoDB</literal> requires indexes on foreign keys
+ and referenced keys so that foreign key checks can be fast
+ and not require a table scan. In the referencing table,
+ there must be an index where the foreign key columns are
+ listed as the <emphasis>first</emphasis> columns in the same
+ order. Such an index is created on the referencing table
+ automatically if it does not exist. (This is in contrast to
+ some older versions, in which indexes had to be created
+ explicitly or the creation of foreign key constraints would
+ fail.) <replaceable>index_name</replaceable>, if given, is
+ used as described previously.
</para>
</listitem>
@@ -3294,7 +3299,7 @@
consequence of this is that
<literal role="type">BLOB</literal> and
<literal role="type">TEXT</literal> columns cannot be
- included in a foreign key, because indexes on those columns
+ included in a foreign key because indexes on those columns
must always include a prefix length.
</para>
</listitem>
@@ -3414,23 +3419,12 @@
</itemizedlist>
<para>
- Note that <literal>InnoDB</literal> supports foreign key
- references within a table. In these cases, <quote>child table
- records</quote> really refers to dependent records within the
- same table.
+ <literal>InnoDB</literal> supports foreign key references within
+ a table. In these cases, <quote>child table records</quote>
+ really refers to dependent records within the same table.
</para>
<para>
- <literal>InnoDB</literal> requires indexes on foreign keys and
- referenced keys so that foreign key checks can be fast and not
- require a table scan. The index on the foreign key is created
- automatically if no index on the key columns exists. This is in
- contrast to some older versions, in which indexes had to be
- created explicitly or the creation of foreign key constraints
- would fail.
- </para>
-
- <para>
Here is a simple example that relates <literal>parent</literal>
and <literal>child</literal> tables through a single-column
foreign key:
@@ -3493,10 +3487,10 @@
</programlisting>
<para>
- <emphasis role="bold">Remember to create the required indexes
- first</emphasis>. You can also add a self-referential foreign
- key constraint to a table using <literal role="stmt">ALTER
- TABLE</literal>.
+ The foreign key can be self referential (referring to the same
+ table). When you add a foreign key constraint to a table using
+ <literal role="stmt">ALTER TABLE</literal>, <emphasis>remember
+ to create the required indexes first.</emphasis>
</para>
<indexterm>
@@ -3514,7 +3508,7 @@
</indexterm>
<para>
- <literal>InnoDB</literal> also supports the use of
+ <literal>InnoDB</literal> supports the use of
<literal role="stmt">ALTER TABLE</literal> to drop foreign keys:
</para>
@@ -3595,7 +3589,7 @@
<para>
<command>mysqldump</command> also produces correct definitions
- of tables to the dump file, and does not forget about the
+ of tables in the dump file, and does not forget about the
foreign keys.
</para>
@@ -3669,16 +3663,16 @@
referencing it. It must have the right column names and types,
and it must have indexes on the referenced keys, as stated
earlier. If these are not satisfied, MySQL returns error number
- 1005 and refers to errno 150 in the error message.
+ 1005 and refers to error 150 in the error message.
</para>
<para>
If MySQL reports an error number 1005 from a
<literal role="stmt">CREATE TABLE</literal> statement, and the
- error message refers to errno 150, table creation failed because
+ error message refers to error 150, table creation failed because
a foreign key constraint was not correctly formed. Similarly, if
an <literal role="stmt">ALTER TABLE</literal> fails and it
- refers to errno 150, that means a foreign key definition would
+ refers to error 150, that means a foreign key definition would
be incorrectly formed for the altered table. You can use
<literal>SHOW ENGINE INNODB STATUS</literal> to display a
detailed explanation of the most recent
@@ -3745,8 +3739,8 @@
<literal>DB_ROLL_PTR</literal> and
<literal>DB_MIX_ID</literal>). In versions of MySQL before
5.1.10 this would cause a crash, since 5.1.10 the server will
- report error 1005 and refers to <literal>errno</literal> -1 in
- the error message.
+ report error 1005 and refers to error −1 in the error
+ message.
</para>
<para>
@@ -3886,14 +3880,14 @@
<para>
Cascading actions for <literal>InnoDB</literal> tables on the
- master are replicated to the slave <emphasis>only</emphasis>
- if both the master's and slave' versions of the
- tables sharing the foreign key relation use
- <literal>InnoDB</literal>. This is true whether you are using
- statement-based or row-based replication. For example, suppose
- you have started replication, and then create two tables on
- the master using the following <literal role="stmt">CREATE
- TABLE</literal> statements:
+ master are replicated on the slave <emphasis>only</emphasis>
+ if the tables sharing the foreign key relation use
+ <literal>InnoDB</literal> on both the master and slave. This
+ is true whether you are using statement-based or row-based
+ replication. For example, suppose you have started
+ replication, and then create two tables on the master using
+ the following <literal role="stmt">CREATE TABLE</literal>
+ statements:
<programlisting>
CREATE TABLE fc1 (
@@ -3991,9 +3985,12 @@
1 row in set (0.00 sec)
</programlisting>
- However, the cascade does not propagate to the slave. The
- slave's copy of <literal>fc2</literal> still contains all
- of the rows that were originally inserted:
+ However, the cascade does not propagate on the slave because
+ on the slave the <literal role="stmt">DELETE</literal> for
+ <literal>fc1</literal> deletes no rows from
+ <literal>fc2</literal>. The slave's copy of
+ <literal>fc2</literal> still contains all of the rows that
+ were originally inserted:
<programlisting>
slave> <userinput>SELECT * FROM fc2;</userinput>
@@ -4162,12 +4159,12 @@
<listitem>
<para>
If <literal>innodb_fast_shutdown</literal> is not set to 2:
- You must stop the MySQL server and make sure that it shuts
- down without errors (to ensure that there is no information
- for outstanding transactions in the logs). Then copy the old
- log files into a safe place just in case something went wrong
- in the shutdown and you need them to recover the tablespace.
- Delete the old log files from the log file directory, edit
+ Stop the MySQL server and make sure that it shuts down without
+ errors (to ensure that there is no information for outstanding
+ transactions in the logs). Then copy the old log files into a
+ safe place just in case something went wrong in the shutdown
+ and you need them to recover the tablespace. Delete the old
+ log files from the log file directory, edit
<filename>my.cnf</filename> to change the log file
configuration, and start the MySQL server again.
<command>mysqld</command> sees that no log files exist at
@@ -4177,12 +4174,11 @@
<listitem>
<para>
- If <literal>innodb_fast_shutdown</literal> is set to 2: You
- should shut down the server, set
- <literal>innodb_fast_shutdown</literal> to 1, and restart the
- server. The server should be allowed to recover. Then you
- should shut down the server again and follow the procedure
- described in the preceding item to change
+ If <literal>innodb_fast_shutdown</literal> is set to 2: Shut
+ down the server, set <literal>innodb_fast_shutdown</literal>
+ to 1, and restart the server. The server should be allowed to
+ recover. Then you should shut down the server again and follow
+ the procedure described in the preceding item to change
<literal>InnoDB</literal> log file size. Set
<literal>innodb_fast_shutdown</literal> back to 2 and restart
the server.
@@ -4208,11 +4204,11 @@
you to shut down your database and it does not set any locks or
disturb your normal database processing. <command>InnoDB Hot
Backup</command> is a non-free (commercial) add-on tool with an
- annual license fee of €390 per computer on which the MySQL
- server is run. See the
+ annual license fee per computer on which the MySQL server is run.
+ See the
<ulink url="http://www.innodb.com/hot-backup"><command>InnoDB Hot
- Backup</command> home page</ulink> for detailed information and
- screenshots.
+ Backup</command> home page</ulink> for detailed information,
+ screenshots, and licensing information.
</para>
<para>
@@ -4277,21 +4273,19 @@
the chance for serious data corruption is smaller.
<command>mysqldump</command> also has a
<option>--single-transaction</option> option that you can use to
- make a consistent snapshot without locking out other clients.
+ make a consistent snapshot without locking out other clients. See
+ <xref linkend="backup-policy"/>.
</para>
<para>
To be able to recover your <literal>InnoDB</literal> database to
the present from the binary backup just described, you have to run
- your MySQL server with binary logging turned on. Then you can
- apply the binary log to the backup database to achieve
- point-in-time recovery:
+ your MySQL server with binary logging turned on. To achieve
+ point-in-time recovery after restoring a backup, you can apply
+ changes from the binary log that occurred after the backup was
+ made. See See <xref linkend="point-in-time-recovery"/>.
</para>
-<programlisting>
-mysqlbinlog <replaceable>yourhostname</replaceable>-bin.123 | mysql
-</programlisting>
-
<para>
To recover from a crash of your MySQL server, the only requirement
is to restart it. <literal>InnoDB</literal> automatically checks
@@ -4332,7 +4326,7 @@
first find a backup that is not corrupted. After restoring the
base backup, do the recovery from the binary log files using
<command>mysqlbinlog</command> and <command>mysql</command> to
- restore the changes performed after the backup was made.
+ restore the changes that occurred after the backup was made.
</para>
<para>
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-11-05 22:01:26 UTC (rev 12298)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-11-05 22:01:35 UTC (rev 12299)
Changed blocks: 15, Lines Added: 61, Lines Deleted: 67; 11903 bytes
@@ -3170,12 +3170,17 @@
<listitem>
<para>
- In the referencing table, there must be an index where the
- foreign key columns are listed as the
- <emphasis>first</emphasis> columns in the same order. Such
- an index is created on the referencing table automatically
- if it does not exist. <replaceable>index_name</replaceable>,
- if given, is used as described previously.
+ <literal>InnoDB</literal> requires indexes on foreign keys
+ and referenced keys so that foreign key checks can be fast
+ and not require a table scan. In the referencing table,
+ there must be an index where the foreign key columns are
+ listed as the <emphasis>first</emphasis> columns in the same
+ order. Such an index is created on the referencing table
+ automatically if it does not exist. (This is in contrast to
+ some older versions, in which indexes had to be created
+ explicitly or the creation of foreign key constraints would
+ fail.) <replaceable>index_name</replaceable>, if given, is
+ used as described previously.
</para>
</listitem>
@@ -3195,7 +3200,7 @@
consequence of this is that
<literal role="type">BLOB</literal> and
<literal role="type">TEXT</literal> columns cannot be
- included in a foreign key, because indexes on those columns
+ included in a foreign key because indexes on those columns
must always include a prefix length.
</para>
</listitem>
@@ -3315,23 +3320,12 @@
</itemizedlist>
<para>
- Note that <literal>InnoDB</literal> supports foreign key
- references within a table. In these cases, <quote>child table
- records</quote> really refers to dependent records within the
- same table.
+ <literal>InnoDB</literal> supports foreign key references within
+ a table. In these cases, <quote>child table records</quote>
+ really refers to dependent records within the same table.
</para>
<para>
- <literal>InnoDB</literal> requires indexes on foreign keys and
- referenced keys so that foreign key checks can be fast and not
- require a table scan. The index on the foreign key is created
- automatically if no index on the key columns exists. This is in
- contrast to some older versions, in which indexes had to be
- created explicitly or the creation of foreign key constraints
- would fail.
- </para>
-
- <para>
Here is a simple example that relates <literal>parent</literal>
and <literal>child</literal> tables through a single-column
foreign key:
@@ -3394,10 +3388,10 @@
</programlisting>
<para>
- <emphasis role="bold">Remember to create the required indexes
- first</emphasis>. You can also add a self-referential foreign
- key constraint to a table using <literal role="stmt">ALTER
- TABLE</literal>.
+ The foreign key can be self referential (referring to the same
+ table). When you add a foreign key constraint to a table using
+ <literal role="stmt">ALTER TABLE</literal>, <emphasis>remember
+ to create the required indexes first.</emphasis>
</para>
<indexterm>
@@ -3415,7 +3409,7 @@
</indexterm>
<para>
- <literal>InnoDB</literal> also supports the use of
+ <literal>InnoDB</literal> supports the use of
<literal role="stmt">ALTER TABLE</literal> to drop foreign keys:
</para>
@@ -3496,7 +3490,7 @@
<para>
<command>mysqldump</command> also produces correct definitions
- of tables to the dump file, and does not forget about the
+ of tables in the dump file, and does not forget about the
foreign keys.
</para>
@@ -3570,16 +3564,16 @@
referencing it. It must have the right column names and types,
and it must have indexes on the referenced keys, as stated
earlier. If these are not satisfied, MySQL returns error number
- 1005 and refers to errno 150 in the error message.
+ 1005 and refers to error 150 in the error message.
</para>
<para>
If MySQL reports an error number 1005 from a
<literal role="stmt">CREATE TABLE</literal> statement, and the
- error message refers to errno 150, table creation failed because
+ error message refers to error 150, table creation failed because
a foreign key constraint was not correctly formed. Similarly, if
an <literal role="stmt">ALTER TABLE</literal> fails and it
- refers to errno 150, that means a foreign key definition would
+ refers to error 150, that means a foreign key definition would
be incorrectly formed for the altered table. You can use
<literal>SHOW ENGINE INNODB STATUS</literal> to display a
detailed explanation of the most recent
@@ -3645,7 +3639,7 @@
<literal>DB_ROW_ID</literal>, <literal>DB_TRX_ID</literal>,
<literal>DB_ROLL_PTR</literal> and
<literal>DB_MIX_ID</literal>). The server will report error 1005
- and refers to <literal>errno</literal> -1 in the error message.
+ and refers to error −1 in the error message.
</para>
<para>
@@ -3753,14 +3747,14 @@
<para>
Cascading actions for <literal>InnoDB</literal> tables on the
- master are replicated to the slave <emphasis>only</emphasis>
- if both the master's and slave' versions of the
- tables sharing the foreign key relation use
- <literal>InnoDB</literal>. This is true whether you are using
- statement-based or row-based replication. For example, suppose
- you have started replication, and then create two tables on
- the master using the following <literal role="stmt">CREATE
- TABLE</literal> statements:
+ master are replicated on the slave <emphasis>only</emphasis>
+ if the tables sharing the foreign key relation use
+ <literal>InnoDB</literal> on both the master and slave. This
+ is true whether you are using statement-based or row-based
+ replication. For example, suppose you have started
+ replication, and then create two tables on the master using
+ the following <literal role="stmt">CREATE TABLE</literal>
+ statements:
<programlisting>
CREATE TABLE fc1 (
@@ -3858,9 +3852,12 @@
1 row in set (0.00 sec)
</programlisting>
- However, the cascade does not propagate to the slave. The
- slave's copy of <literal>fc2</literal> still contains all
- of the rows that were originally inserted:
+ However, the cascade does not propagate on the slave because
+ on the slave the <literal role="stmt">DELETE</literal> for
+ <literal>fc1</literal> deletes no rows from
+ <literal>fc2</literal>. The slave's copy of
+ <literal>fc2</literal> still contains all of the rows that
+ were originally inserted:
<programlisting>
slave> <userinput>SELECT * FROM fc2;</userinput>
@@ -4029,12 +4026,12 @@
<listitem>
<para>
If <literal>innodb_fast_shutdown</literal> is not set to 2:
- You must stop the MySQL server and make sure that it shuts
- down without errors (to ensure that there is no information
- for outstanding transactions in the logs). Then copy the old
- log files into a safe place just in case something went wrong
- in the shutdown and you need them to recover the tablespace.
- Delete the old log files from the log file directory, edit
+ Stop the MySQL server and make sure that it shuts down without
+ errors (to ensure that there is no information for outstanding
+ transactions in the logs). Then copy the old log files into a
+ safe place just in case something went wrong in the shutdown
+ and you need them to recover the tablespace. Delete the old
+ log files from the log file directory, edit
<filename>my.cnf</filename> to change the log file
configuration, and start the MySQL server again.
<command>mysqld</command> sees that no log files exist at
@@ -4044,12 +4041,11 @@
<listitem>
<para>
- If <literal>innodb_fast_shutdown</literal> is set to 2: You
- should shut down the server, set
- <literal>innodb_fast_shutdown</literal> to 1, and restart the
- server. The server should be allowed to recover. Then you
- should shut down the server again and follow the procedure
- described in the preceding item to change
+ If <literal>innodb_fast_shutdown</literal> is set to 2: Shut
+ down the server, set <literal>innodb_fast_shutdown</literal>
+ to 1, and restart the server. The server should be allowed to
+ recover. Then you should shut down the server again and follow
+ the procedure described in the preceding item to change
<literal>InnoDB</literal> log file size. Set
<literal>innodb_fast_shutdown</literal> back to 2 and restart
the server.
@@ -4075,11 +4071,11 @@
you to shut down your database and it does not set any locks or
disturb your normal database processing. <command>InnoDB Hot
Backup</command> is a non-free (commercial) add-on tool with an
- annual license fee of €390 per computer on which the MySQL
- server is run. See the
+ annual license fee per computer on which the MySQL server is run.
+ See the
<ulink url="http://www.innodb.com/hot-backup"><command>InnoDB Hot
- Backup</command> home page</ulink> for detailed information and
- screenshots.
+ Backup</command> home page</ulink> for detailed information,
+ screenshots, and licensing information.
</para>
<para>
@@ -4144,21 +4140,19 @@
the chance for serious data corruption is smaller.
<command>mysqldump</command> also has a
<option>--single-transaction</option> option that you can use to
- make a consistent snapshot without locking out other clients.
+ make a consistent snapshot without locking out other clients. See
+ <xref linkend="backup-policy"/>.
</para>
<para>
To be able to recover your <literal>InnoDB</literal> database to
the present from the binary backup just described, you have to run
- your MySQL server with binary logging turned on. Then you can
- apply the binary log to the backup database to achieve
- point-in-time recovery:
+ your MySQL server with binary logging turned on. To achieve
+ point-in-time recovery after restoring a backup, you can apply
+ changes from the binary log that occurred after the backup was
+ made. See See <xref linkend="point-in-time-recovery"/>.
</para>
-<programlisting>
-mysqlbinlog <replaceable>yourhostname</replaceable>-bin.123 | mysql
-</programlisting>
-
<para>
To recover from a crash of your MySQL server, the only requirement
is to restart it. <literal>InnoDB</literal> automatically checks
@@ -4199,7 +4193,7 @@
first find a backup that is not corrupted. After restoring the
base backup, do the recovery from the binary log files using
<command>mysqlbinlog</command> and <command>mysql</command> to
- restore the changes performed after the backup was made.
+ restore the changes that occurred after the backup was made.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12299 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 5 Nov |
