Author: paul
Date: 2006-01-09 01:09:00 +0100 (Mon, 09 Jan 2006)
New Revision: 722
Log:
r5959@frost: paul | 2006-01-08 16:56:37 -0600
Move a couple of configuration-related sections into the main
configuration section.
Modified:
trunk/
trunk/refman-4.1/innodb.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.1/innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5958
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5959
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml 2006-01-09 00:08:43 UTC (rev 721)
+++ trunk/refman-4.1/innodb.xml 2006-01-09 00:09:00 UTC (rev 722)
@@ -745,6 +745,349 @@
set-variable = key_buffer_size=...
</programlisting>
+ <section id="multiple-tablespaces">
+
+ <title>&title-multiple-tablespaces;</title>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: There is a known bug in
+ versions prior to 4.1.8 that manifests itself if you specify
+ <literal>innodb_file_per_table</literal> in
+ <filename>my.cnf</filename>. If you shut down
+ <command>mysqld</command>, then records may disappear from the
+ secondary indexes of a table. See Bug #7496 for more information
+ and workarounds. This is fixed in 4.1.9, but another bug (Bug
+ #8021) bit the Windows version in 4.1.9, and in the Windows
+ version of 4.1.9 you must put the line
+ <literal>innodb_flush_method=unbuffered</literal> to your
+ <filename>my.cnf</filename> or <filename>my.ini</filename> to
+ get <command>mysqld</command> to work.
+ </para>
+
+ <para>
+ Starting from MySQL 4.1.1, you can store each
+ <literal>InnoDB</literal> table and its indexes in its own file.
+ This feature is called <quote>multiple tablespaces</quote>
+ because in effect each table has its own tablespace.
+ </para>
+
+ <para>
+ Using multiple tablespaces can be beneficial to users who want
+ to move specific tables to separate physical disks or who wish
+ to restore backups of single tables quickly without interrupting
+ the use of the remaining <literal>InnoDB</literal> tables.
+ </para>
+
+ <para>
+ If you need to downgrade to 4.0, you must make table dumps and
+ re-create the whole <literal>InnoDB</literal> tablespace. If you
+ have not created new <literal>InnoDB</literal> tables under
+ MySQL 4.1.1 or later, and need to downgrade quickly, you can
+ also do a direct downgrade to the MySQL 4.0.18 or later in the
+ 4.0 series. Before doing the direct downgrade to 4.0.x, you have
+ to end all client connections to the <command>mysqld</command>
+ server that is to be downgraded, and let it run the purge and
+ insert buffer merge operations to completion, so that
+ <literal>SHOW INNODB STATUS</literal> shows the main thread in
+ the state <literal>waiting for server activity</literal>. Then
+ you can shut down <command>mysqld</command> and start 4.0.18 or
+ later in the 4.0 series.
+ </para>
+
+ <para>
+ You can enable multiple tablespaces by adding a line to the
+ <literal>[mysqld]</literal> section of
+ <filename>my.cnf</filename>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_file_per_table
+</programlisting>
+
+ <para>
+ After restarting the server, <literal>InnoDB</literal> stores
+ each newly created table into its own file
+ <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
+ the database directory where the table belongs. This is similar
+ to what the <literal>MyISAM</literal> storage engine does, but
+ <literal>MyISAM</literal> divides the table into a data file
+ <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
+ the index file
+ <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
+ For <literal>InnoDB</literal>, the data and the indexes are
+ stored together in the <filename>.ibd</filename> file. The
+ <filename><replaceable>tbl_name</replaceable>.frm</filename>
+ file is still created as usual.
+ </para>
+
+ <para>
+ If you remove the <literal>innodb_file_per_table</literal> line
+ from <filename>my.cnf</filename> and restart the server,
+ <literal>InnoDB</literal> creates tables inside the shared
+ tablespace files again.
+ </para>
+
+ <para>
+ <literal>innodb_file_per_table</literal> affects only table
+ creation. If you start the server with this option, new tables
+ are created using <filename>.ibd</filename> files, but you can
+ still access tables that exist in the shared tablespace. If you
+ remove the option, new tables are created in the shared
+ tablespace, but you can still access any tables that were
+ created using multiple tablespaces.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> always needs the shared tablespace.
+ The <filename>.ibd</filename> files are not sufficient for
+ <literal>InnoDB</literal> to operate. The shared tablespace
+ consists of the familiar <filename>ibdata</filename> files where
+ <literal>InnoDB</literal> puts its internal data dictionary and
+ undo logs.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: You cannot freely move
+ <filename>.ibd</filename> files between database directories as
+ you can with <literal>MyISAM</literal> table files. This is
+ because the table definition is stored in the
+ <literal>InnoDB</literal> shared tablespace, and because
+ <literal>InnoDB</literal> must preserve the consistency of
+ transaction IDs and log sequence numbers.
+ </para>
+
+ <para>
+ Within a given MySQL installation, you can move an
+ <filename>.ibd</filename> file and the associated table from one
+ database to another with a <literal>RENAME TABLE</literal>
+ statement:
+ </para>
+
+<programlisting>
+RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
+</programlisting>
+
+ <indexterm type="function">
+ <primary>DISCARD TABLESPACE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>IMPORT TABLESPACE</primary>
+ </indexterm>
+
+ <para>
+ If you have a <quote>clean</quote> backup of an
+ <filename>.ibd</filename> file, you can restore it to the MySQL
+ installation from which it originated as follows:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
+</programlisting>
+
+ <para>
+ <emphasis role="bold">Caution</emphasis>: This statement
+ deletes the current <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Put the backup <filename>.ibd</filename> file back in the
+ proper database directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
+</programlisting>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ In this context, a <quote>clean</quote>
+ <filename>.ibd</filename> file backup means:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ There are no uncommitted modifications by transactions in
+ the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ There are no unmerged insert buffer entries in the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Purge has removed all delete-marked index records from the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>mysqld</command> has flushed all modified pages of
+ the <filename>.ibd</filename> file from the buffer pool to
+ the file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can make a clean backup <filename>.ibd</filename> file using
+ the following method:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Stop all activity from the <command>mysqld</command> server
+ and commit all transactions.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Wait until <literal>SHOW INNODB STATUS</literal> shows that
+ there are no active transactions in the database, and the
+ main thread status of <literal>InnoDB</literal> is
+ <literal>Waiting for server activity</literal>. Then you can
+ make a copy of the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ Another method for making a clean copy of an
+ <filename>.ibd</filename> file is to use the commercial
+ <command>InnoDB Hot Backup</command> tool:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Use <command>InnoDB Hot Backup</command> to back up the
+ <literal>InnoDB</literal> installation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Start a second <command>mysqld</command> server on the
+ backup and let it clean up the <filename>.ibd</filename>
+ files in the backup.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </section>
+
+ <section id="innodb-raw-devices">
+
+ <title>&title-innodb-raw-devices;</title>
+
+ <para>
+ Starting from MySQL 3.23.41, you can use raw disk partitions as
+ tablespace data files. By using a raw disk, you can perform
+ non-buffered I/O on Windows and on some Unix systems without
+ filesystem overhead, which might improve performance.
+ </para>
+
+ <para>
+ When you create a new data file, you must put the keyword
+ <literal>newraw</literal> immediately after the data file size
+ in <literal>innodb_data_file_path</literal>. The partition must
+ be at least as large as the size that you specify. Note that 1MB
+ in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
+ usually means 1,000,000 bytes in disk specifications.
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
+</programlisting>
+
+ <para>
+ The next time you start the server, <literal>InnoDB</literal>
+ notices the <literal>newraw</literal> keyword and initializes
+ the new partition. However, do not create or change any
+ <literal>InnoDB</literal> tables yet. Otherwise, when you next
+ restart the server, <literal>InnoDB</literal> reinitializes the
+ partition and your changes are lost. (Starting from 3.23.44, as
+ a safety measure <literal>InnoDB</literal> prevents users from
+ modifying data when any partition with <literal>newraw</literal>
+ is specified.)
+ </para>
+
+ <para>
+ After <literal>InnoDB</literal> has initialized the new
+ partition, stop the server, change <literal>newraw</literal> in
+ the data file specification to <literal>raw</literal>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
+</programlisting>
+
+ <para>
+ Then restart the server and <literal>InnoDB</literal> allows
+ changes to be made.
+ </para>
+
+ <para>
+ On Windows, starting from 4.1.1, you can allocate a disk
+ partition as a data file like this:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=//./D::10Gnewraw
+</programlisting>
+
+ <para>
+ The <filename>//./</filename> corresponds to the Windows syntax
+ of <filename>\\.\</filename> for accessing physical drives.
+ </para>
+
+ <para>
+ When you use raw disk partitions, be sure that they have
+ permissions that allow read and write access by the account used
+ for running the MySQL server.
+ </para>
+
+ </section>
+
</section>
<section id="innodb-start">
@@ -2543,270 +2886,6 @@
</section>
- <section id="multiple-tablespaces">
-
- <title>&title-multiple-tablespaces;</title>
-
- <para>
- <emphasis role="bold">Note</emphasis>: There is a known bug in
- versions prior to 4.1.8 that manifests itself if you specify
- <literal>innodb_file_per_table</literal> in
- <filename>my.cnf</filename>. If you shut down
- <command>mysqld</command>, then records may disappear from the
- secondary indexes of a table. See Bug #7496 for more information
- and workarounds. This is fixed in 4.1.9, but another bug (Bug
- #8021) bit the Windows version in 4.1.9, and in the Windows
- version of 4.1.9 you must put the line
- <literal>innodb_flush_method=unbuffered</literal> to your
- <filename>my.cnf</filename> or <filename>my.ini</filename> to
- get <command>mysqld</command> to work.
- </para>
-
- <para>
- Starting from MySQL 4.1.1, you can store each
- <literal>InnoDB</literal> table and its indexes in its own file.
- This feature is called <quote>multiple tablespaces</quote>
- because in effect each table has its own tablespace.
- </para>
-
- <para>
- Using multiple tablespaces can be beneficial to users who want
- to move specific tables to separate physical disks or who wish
- to restore backups of single tables quickly without interrupting
- the use of the remaining <literal>InnoDB</literal> tables.
- </para>
-
- <para>
- If you need to downgrade to 4.0, you must make table dumps and
- re-create the whole <literal>InnoDB</literal> tablespace. If you
- have not created new <literal>InnoDB</literal> tables under
- MySQL 4.1.1 or later, and need to downgrade quickly, you can
- also do a direct downgrade to the MySQL 4.0.18 or later in the
- 4.0 series. Before doing the direct downgrade to 4.0.x, you have
- to end all client connections to the <command>mysqld</command>
- server that is to be downgraded, and let it run the purge and
- insert buffer merge operations to completion, so that
- <literal>SHOW INNODB STATUS</literal> shows the main thread in
- the state <literal>waiting for server activity</literal>. Then
- you can shut down <command>mysqld</command> and start 4.0.18 or
- later in the 4.0 series.
- </para>
-
- <para>
- You can enable multiple tablespaces by adding a line to the
- <literal>[mysqld]</literal> section of
- <filename>my.cnf</filename>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_file_per_table
-</programlisting>
-
- <para>
- After restarting the server, <literal>InnoDB</literal> stores
- each newly created table into its own file
- <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
- the database directory where the table belongs. This is similar
- to what the <literal>MyISAM</literal> storage engine does, but
- <literal>MyISAM</literal> divides the table into a data file
- <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
- the index file
- <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
- For <literal>InnoDB</literal>, the data and the indexes are
- stored together in the <filename>.ibd</filename> file. The
- <filename><replaceable>tbl_name</replaceable>.frm</filename>
- file is still created as usual.
- </para>
-
- <para>
- If you remove the <literal>innodb_file_per_table</literal> line
- from <filename>my.cnf</filename> and restart the server,
- <literal>InnoDB</literal> creates tables inside the shared
- tablespace files again.
- </para>
-
- <para>
- <literal>innodb_file_per_table</literal> affects only table
- creation. If you start the server with this option, new tables
- are created using <filename>.ibd</filename> files, but you can
- still access tables that exist in the shared tablespace. If you
- remove the option, new tables are created in the shared
- tablespace, but you can still access any tables that were
- created using multiple tablespaces.
- </para>
-
- <para>
- <literal>InnoDB</literal> always needs the shared tablespace.
- The <filename>.ibd</filename> files are not sufficient for
- <literal>InnoDB</literal> to operate. The shared tablespace
- consists of the familiar <filename>ibdata</filename> files where
- <literal>InnoDB</literal> puts its internal data dictionary and
- undo logs.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: You cannot freely move
- <filename>.ibd</filename> files between database directories as
- you can with <literal>MyISAM</literal> table files. This is
- because the table definition is stored in the
- <literal>InnoDB</literal> shared tablespace, and because
- <literal>InnoDB</literal> must preserve the consistency of
- transaction IDs and log sequence numbers.
- </para>
-
- <para>
- Within a given MySQL installation, you can move an
- <filename>.ibd</filename> file and the associated table from one
- database to another with a <literal>RENAME TABLE</literal>
- statement:
- </para>
-
-<programlisting>
-RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
-</programlisting>
-
- <indexterm type="function">
- <primary>DISCARD TABLESPACE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>IMPORT TABLESPACE</primary>
- </indexterm>
-
- <para>
- If you have a <quote>clean</quote> backup of an
- <filename>.ibd</filename> file, you can restore it to the MySQL
- installation from which it originated as follows:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
-</programlisting>
-
- <para>
- <emphasis role="bold">Caution</emphasis>: This statement
- deletes the current <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Put the backup <filename>.ibd</filename> file back in the
- proper database directory.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
-</programlisting>
- </listitem>
-
- </orderedlist>
-
- <para>
- In this context, a <quote>clean</quote>
- <filename>.ibd</filename> file backup means:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- There are no uncommitted modifications by transactions in
- the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- There are no unmerged insert buffer entries in the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Purge has removed all delete-marked index records from the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>mysqld</command> has flushed all modified pages of
- the <filename>.ibd</filename> file from the buffer pool to
- the file.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
- You can make a clean backup <filename>.ibd</filename> file using
- the following method:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Stop all activity from the <command>mysqld</command> server
- and commit all transactions.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Wait until <literal>SHOW INNODB STATUS</literal> shows that
- there are no active transactions in the database, and the
- main thread status of <literal>InnoDB</literal> is
- <literal>Waiting for server activity</literal>. Then you can
- make a copy of the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- </orderedlist>
-
- <para>
- Another method for making a clean copy of an
- <filename>.ibd</filename> file is to use the commercial
- <command>InnoDB Hot Backup</command> tool:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Use <command>InnoDB Hot Backup</command> to back up the
- <literal>InnoDB</literal> installation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Start a second <command>mysqld</command> server on the
- backup and let it clean up the <filename>.ibd</filename>
- files in the backup.
- </para>
- </listitem>
-
- </orderedlist>
-
- </section>
-
</section>
<section id="adding-and-removing">
@@ -5682,85 +5761,6 @@
</section>
- <section id="innodb-raw-devices">
-
- <title>&title-innodb-raw-devices;</title>
-
- <para>
- Starting from MySQL 3.23.41, you can use raw disk partitions as
- tablespace data files. By using a raw disk, you can perform
- non-buffered I/O on Windows and on some Unix systems without
- filesystem overhead, which might improve performance.
- </para>
-
- <para>
- When you create a new data file, you must put the keyword
- <literal>newraw</literal> immediately after the data file size
- in <literal>innodb_data_file_path</literal>. The partition must
- be at least as large as the size that you specify. Note that 1MB
- in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
- usually means 1,000,000 bytes in disk specifications.
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
-</programlisting>
-
- <para>
- The next time you start the server, <literal>InnoDB</literal>
- notices the <literal>newraw</literal> keyword and initializes
- the new partition. However, do not create or change any
- <literal>InnoDB</literal> tables yet. Otherwise, when you next
- restart the server, <literal>InnoDB</literal> reinitializes the
- partition and your changes are lost. (Starting from 3.23.44, as
- a safety measure <literal>InnoDB</literal> prevents users from
- modifying data when any partition with <literal>newraw</literal>
- is specified.)
- </para>
-
- <para>
- After <literal>InnoDB</literal> has initialized the new
- partition, stop the server, change <literal>newraw</literal> in
- the data file specification to <literal>raw</literal>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
-</programlisting>
-
- <para>
- Then restart the server and <literal>InnoDB</literal> allows
- changes to be made.
- </para>
-
- <para>
- On Windows, starting from 4.1.1, you can allocate a disk
- partition as a data file like this:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=//./D::10Gnewraw
-</programlisting>
-
- <para>
- The <filename>//./</filename> corresponds to the Windows syntax
- of <filename>\\.\</filename> for accessing physical drives.
- </para>
-
- <para>
- When you use raw disk partitions, be sure that they have
- permissions that allow read and write access by the account used
- for running the MySQL server.
- </para>
-
- </section>
-
<section id="innodb-file-space">
<title>&title-innodb-file-space;</title>
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-09 00:08:43 UTC (rev 721)
+++ trunk/refman-5.0/innodb.xml 2006-01-09 00:09:00 UTC (rev 722)
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
[
<!ENTITY % fixedchars.entities SYSTEM "../refman-common/fixedchars.ent">
@@ -663,6 +663,318 @@
key_buffer_size=<replaceable>value</replaceable>
</programlisting>
+ <section id="multiple-tablespaces">
+
+ <title>&title-multiple-tablespaces;</title>
+
+ <para>
+ You can store each <literal>InnoDB</literal> table and its
+ indexes in its own file. This feature is called <quote>multiple
+ tablespaces</quote> because in effect each table has its own
+ tablespace.
+ </para>
+
+ <para>
+ Using multiple tablespaces can be beneficial to users who want
+ to move specific tables to separate physical disks or who wish
+ to restore backups of single tables quickly without interrupting
+ the use of the remaining <literal>InnoDB</literal> tables.
+ </para>
+
+ <para>
+ You can enable multiple tablespaces by adding this line to the
+ <literal>[mysqld]</literal> section of
+ <filename>my.cnf</filename>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_file_per_table
+</programlisting>
+
+ <para>
+ After restarting the server, <literal>InnoDB</literal> stores
+ each newly created table into its own file
+ <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
+ the database directory where the table belongs. This is similar
+ to what the <literal>MyISAM</literal> storage engine does, but
+ <literal>MyISAM</literal> divides the table into a data file
+ <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
+ the index file
+ <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
+ For <literal>InnoDB</literal>, the data and the indexes are
+ stored together in the <filename>.ibd</filename> file. The
+ <filename><replaceable>tbl_name</replaceable>.frm</filename>
+ file is still created as usual.
+ </para>
+
+ <para>
+ If you remove the <literal>innodb_file_per_table</literal> line
+ from <filename>my.cnf</filename> and restart the server,
+ <literal>InnoDB</literal> creates tables inside the shared
+ tablespace files again.
+ </para>
+
+ <para>
+ <literal>innodb_file_per_table</literal> affects only table
+ creation. If you start the server with this option, new tables
+ are created using <filename>.ibd</filename> files, but you can
+ still access tables that exist in the shared tablespace. If you
+ remove the option, new tables are created in the shared
+ tablespace, but you can still access any tables that were
+ created using multiple tablespaces.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> always needs the shared tablespace.
+ The <filename>.ibd</filename> files are not sufficient for
+ <literal>InnoDB</literal> to operate. The shared tablespace
+ consists of the familiar <filename>ibdata</filename> files where
+ <literal>InnoDB</literal> puts its internal data dictionary and
+ undo logs.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: You cannot freely move
+ <filename>.ibd</filename> files between database directories as
+ you can with <literal>MyISAM</literal> table files. This is
+ because the table definition is stored in the
+ <literal>InnoDB</literal> shared tablespace, and because
+ <literal>InnoDB</literal> must preserve the consistency of
+ transaction IDs and log sequence numbers.
+ </para>
+
+ <para>
+ Within a given MySQL installation, you can move an
+ <filename>.ibd</filename> file and the associated table from one
+ database to another with a <literal>RENAME TABLE</literal>
+ statement:
+ </para>
+
+<programlisting>
+RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
+</programlisting>
+
+ <indexterm type="function">
+ <primary>DISCARD TABLESPACE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>IMPORT TABLESPACE</primary>
+ </indexterm>
+
+ <para>
+ If you have a <quote>clean</quote> backup of an
+ <filename>.ibd</filename> file, you can restore it to the MySQL
+ installation from which it originated as follows:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
+</programlisting>
+
+ <para>
+ <emphasis role="bold">Caution</emphasis>: This statement
+ deletes the current <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Put the backup <filename>.ibd</filename> file back in the
+ proper database directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
+</programlisting>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ In this context, a <quote>clean</quote>
+ <filename>.ibd</filename> file backup means:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ There are no uncommitted modifications by transactions in
+ the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ There are no unmerged insert buffer entries in the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Purge has removed all delete-marked index records from the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>mysqld</command> has flushed all modified pages of
+ the <filename>.ibd</filename> file from the buffer pool to
+ the file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can make a clean backup <filename>.ibd</filename> file using
+ the following method:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Stop all activity from the <command>mysqld</command> server
+ and commit all transactions.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Wait until <literal>SHOW ENGINE INNODB STATUS</literal>
+ shows that there are no active transactions in the database,
+ and the main thread status of <literal>InnoDB</literal> is
+ <literal>Waiting for server activity</literal>. Then you can
+ make a copy of the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ Another method for making a clean copy of an
+ <filename>.ibd</filename> file is to use the commercial
+ <command>InnoDB Hot Backup</command> tool:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Use <command>InnoDB Hot Backup</command> to back up the
+ <literal>InnoDB</literal> installation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Start a second <command>mysqld</command> server on the
+ backup and let it clean up the <filename>.ibd</filename>
+ files in the backup.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </section>
+
+ <section id="innodb-raw-devices">
+
+ <title>&title-innodb-raw-devices;</title>
+
+ <para>
+ You can also use raw disk partitions as tablespace data files.
+ By using a raw disk, you can perform non-buffered I/O on Windows
+ and on some Unix systems without filesystem overhead, which may
+ improve performance.
+ </para>
+
+ <para>
+ When you create a new data file, you must put the keyword
+ <literal>newraw</literal> immediately after the data file size
+ in <literal>innodb_data_file_path</literal>. The partition must
+ be at least as large as the size that you specify. Note that 1MB
+ in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
+ usually means 1,000,000 bytes in disk specifications.
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
+</programlisting>
+
+ <para>
+ The next time you start the server, <literal>InnoDB</literal>
+ notices the <literal>newraw</literal> keyword and initializes
+ the new partition. However, do not create or change any
+ <literal>InnoDB</literal> tables yet. Otherwise, when you next
+ restart the server, <literal>InnoDB</literal> reinitializes the
+ partition and your changes are lost. (Starting from 3.23.44, as
+ a safety measure <literal>InnoDB</literal> prevents users from
+ modifying data when any partition with <literal>newraw</literal>
+ is specified.)
+ </para>
+
+ <para>
+ After <literal>InnoDB</literal> has initialized the new
+ partition, stop the server, change <literal>newraw</literal> in
+ the data file specification to <literal>raw</literal>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
+</programlisting>
+
+ <para>
+ Then restart the server and <literal>InnoDB</literal> allows
+ changes to be made.
+ </para>
+
+ <para>
+ On Windows, you can allocate a disk partition as a data file
+ like this:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=//./D::10Gnewraw
+</programlisting>
+
+ <para>
+ The <filename>//./</filename> corresponds to the Windows syntax
+ of <filename>\\.\</filename> for accessing physical drives.
+ </para>
+
+ <para>
+ When you use raw disk partitions, be sure that they have
+ permissions that allow read and write access by the account used
+ for running the MySQL server.
+ </para>
+
+ </section>
+
</section>
<section id="innodb-start">
@@ -2558,239 +2870,6 @@
</section>
- <section id="multiple-tablespaces">
-
- <title>&title-multiple-tablespaces;</title>
-
- <para>
- You can store each <literal>InnoDB</literal> table and its
- indexes in its own file. This feature is called <quote>multiple
- tablespaces</quote> because in effect each table has its own
- tablespace.
- </para>
-
- <para>
- Using multiple tablespaces can be beneficial to users who want
- to move specific tables to separate physical disks or who wish
- to restore backups of single tables quickly without interrupting
- the use of the remaining <literal>InnoDB</literal> tables.
- </para>
-
- <para>
- You can enable multiple tablespaces by adding this line to the
- <literal>[mysqld]</literal> section of
- <filename>my.cnf</filename>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_file_per_table
-</programlisting>
-
- <para>
- After restarting the server, <literal>InnoDB</literal> stores
- each newly created table into its own file
- <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
- the database directory where the table belongs. This is similar
- to what the <literal>MyISAM</literal> storage engine does, but
- <literal>MyISAM</literal> divides the table into a data file
- <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
- the index file
- <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
- For <literal>InnoDB</literal>, the data and the indexes are
- stored together in the <filename>.ibd</filename> file. The
- <filename><replaceable>tbl_name</replaceable>.frm</filename>
- file is still created as usual.
- </para>
-
- <para>
- If you remove the <literal>innodb_file_per_table</literal> line
- from <filename>my.cnf</filename> and restart the server,
- <literal>InnoDB</literal> creates tables inside the shared
- tablespace files again.
- </para>
-
- <para>
- <literal>innodb_file_per_table</literal> affects only table
- creation. If you start the server with this option, new tables
- are created using <filename>.ibd</filename> files, but you can
- still access tables that exist in the shared tablespace. If you
- remove the option, new tables are created in the shared
- tablespace, but you can still access any tables that were
- created using multiple tablespaces.
- </para>
-
- <para>
- <literal>InnoDB</literal> always needs the shared tablespace.
- The <filename>.ibd</filename> files are not sufficient for
- <literal>InnoDB</literal> to operate. The shared tablespace
- consists of the familiar <filename>ibdata</filename> files where
- <literal>InnoDB</literal> puts its internal data dictionary and
- undo logs.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: You cannot freely move
- <filename>.ibd</filename> files between database directories as
- you can with <literal>MyISAM</literal> table files. This is
- because the table definition is stored in the
- <literal>InnoDB</literal> shared tablespace, and because
- <literal>InnoDB</literal> must preserve the consistency of
- transaction IDs and log sequence numbers.
- </para>
-
- <para>
- Within a given MySQL installation, you can move an
- <filename>.ibd</filename> file and the associated table from one
- database to another with a <literal>RENAME TABLE</literal>
- statement:
- </para>
-
-<programlisting>
-RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
-</programlisting>
-
- <indexterm type="function">
- <primary>DISCARD TABLESPACE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>IMPORT TABLESPACE</primary>
- </indexterm>
-
- <para>
- If you have a <quote>clean</quote> backup of an
- <filename>.ibd</filename> file, you can restore it to the MySQL
- installation from which it originated as follows:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
-</programlisting>
-
- <para>
- <emphasis role="bold">Caution</emphasis>: This statement
- deletes the current <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Put the backup <filename>.ibd</filename> file back in the
- proper database directory.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
-</programlisting>
- </listitem>
-
- </orderedlist>
-
- <para>
- In this context, a <quote>clean</quote>
- <filename>.ibd</filename> file backup means:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- There are no uncommitted modifications by transactions in
- the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- There are no unmerged insert buffer entries in the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Purge has removed all delete-marked index records from the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>mysqld</command> has flushed all modified pages of
- the <filename>.ibd</filename> file from the buffer pool to
- the file.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
- You can make a clean backup <filename>.ibd</filename> file using
- the following method:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Stop all activity from the <command>mysqld</command> server
- and commit all transactions.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Wait until <literal>SHOW ENGINE INNODB STATUS</literal>
- shows that there are no active transactions in the database,
- and the main thread status of <literal>InnoDB</literal> is
- <literal>Waiting for server activity</literal>. Then you can
- make a copy of the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- </orderedlist>
-
- <para>
- Another method for making a clean copy of an
- <filename>.ibd</filename> file is to use the commercial
- <command>InnoDB Hot Backup</command> tool:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Use <command>InnoDB Hot Backup</command> to back up the
- <literal>InnoDB</literal> installation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Start a second <command>mysqld</command> server on the
- backup and let it clean up the <filename>.ibd</filename>
- files in the backup.
- </para>
- </listitem>
-
- </orderedlist>
-
- </section>
-
</section>
<section id="adding-and-removing">
@@ -5628,85 +5707,6 @@
</section>
- <section id="innodb-raw-devices">
-
- <title>&title-innodb-raw-devices;</title>
-
- <para>
- You can also use raw disk partitions as tablespace data files.
- By using a raw disk, you can perform non-buffered I/O on Windows
- and on some Unix systems without filesystem overhead, which may
- improve performance.
- </para>
-
- <para>
- When you create a new data file, you must put the keyword
- <literal>newraw</literal> immediately after the data file size
- in <literal>innodb_data_file_path</literal>. The partition must
- be at least as large as the size that you specify. Note that 1MB
- in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
- usually means 1,000,000 bytes in disk specifications.
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
-</programlisting>
-
- <para>
- The next time you start the server, <literal>InnoDB</literal>
- notices the <literal>newraw</literal> keyword and initializes
- the new partition. However, do not create or change any
- <literal>InnoDB</literal> tables yet. Otherwise, when you next
- restart the server, <literal>InnoDB</literal> reinitializes the
- partition and your changes are lost. (Starting from 3.23.44, as
- a safety measure <literal>InnoDB</literal> prevents users from
- modifying data when any partition with <literal>newraw</literal>
- is specified.)
- </para>
-
- <para>
- After <literal>InnoDB</literal> has initialized the new
- partition, stop the server, change <literal>newraw</literal> in
- the data file specification to <literal>raw</literal>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
-</programlisting>
-
- <para>
- Then restart the server and <literal>InnoDB</literal> allows
- changes to be made.
- </para>
-
- <para>
- On Windows, you can allocate a disk partition as a data file
- like this:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=//./D::10Gnewraw
-</programlisting>
-
- <para>
- The <filename>//./</filename> corresponds to the Windows syntax
- of <filename>\\.\</filename> for accessing physical drives.
- </para>
-
- <para>
- When you use raw disk partitions, be sure that they have
- permissions that allow read and write access by the account used
- for running the MySQL server.
- </para>
-
- </section>
-
<section id="innodb-file-space">
<title>&title-innodb-file-space;</title>
Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml 2006-01-09 00:08:43 UTC (rev 721)
+++ trunk/refman-5.1/innodb.xml 2006-01-09 00:09:00 UTC (rev 722)
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
[
<!ENTITY % fixedchars.entities SYSTEM "../refman-common/fixedchars.ent">
@@ -663,6 +663,318 @@
key_buffer_size=<replaceable>value</replaceable>
</programlisting>
+ <section id="multiple-tablespaces">
+
+ <title>&title-multiple-tablespaces;</title>
+
+ <para>
+ You can store each <literal>InnoDB</literal> table and its
+ indexes in its own file. This feature is called <quote>multiple
+ tablespaces</quote> because in effect each table has its own
+ tablespace.
+ </para>
+
+ <para>
+ Using multiple tablespaces can be beneficial to users who want
+ to move specific tables to separate physical disks or who wish
+ to restore backups of single tables quickly without interrupting
+ the use of the remaining <literal>InnoDB</literal> tables.
+ </para>
+
+ <para>
+ You can enable multiple tablespaces by adding this line to the
+ <literal>[mysqld]</literal> section of
+ <filename>my.cnf</filename>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_file_per_table
+</programlisting>
+
+ <para>
+ After restarting the server, <literal>InnoDB</literal> stores
+ each newly created table into its own file
+ <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
+ the database directory where the table belongs. This is similar
+ to what the <literal>MyISAM</literal> storage engine does, but
+ <literal>MyISAM</literal> divides the table into a data file
+ <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
+ the index file
+ <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
+ For <literal>InnoDB</literal>, the data and the indexes are
+ stored together in the <filename>.ibd</filename> file. The
+ <filename><replaceable>tbl_name</replaceable>.frm</filename>
+ file is still created as usual.
+ </para>
+
+ <para>
+ If you remove the <literal>innodb_file_per_table</literal> line
+ from <filename>my.cnf</filename> and restart the server,
+ <literal>InnoDB</literal> creates tables inside the shared
+ tablespace files again.
+ </para>
+
+ <para>
+ <literal>innodb_file_per_table</literal> affects only table
+ creation. If you start the server with this option, new tables
+ are created using <filename>.ibd</filename> files, but you can
+ still access tables that exist in the shared tablespace. If you
+ remove the option, new tables are created in the shared
+ tablespace, but you can still access any tables that were
+ created using multiple tablespaces.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> always needs the shared tablespace.
+ The <filename>.ibd</filename> files are not sufficient for
+ <literal>InnoDB</literal> to operate. The shared tablespace
+ consists of the familiar <filename>ibdata</filename> files where
+ <literal>InnoDB</literal> puts its internal data dictionary and
+ undo logs.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: You cannot freely move
+ <filename>.ibd</filename> files between database directories as
+ you can with <literal>MyISAM</literal> table files. This is
+ because the table definition is stored in the
+ <literal>InnoDB</literal> shared tablespace, and because
+ <literal>InnoDB</literal> must preserve the consistency of
+ transaction IDs and log sequence numbers.
+ </para>
+
+ <para>
+ Within a given MySQL installation, you can move an
+ <filename>.ibd</filename> file and the associated table from one
+ database to another with a <literal>RENAME TABLE</literal>
+ statement:
+ </para>
+
+<programlisting>
+RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
+</programlisting>
+
+ <indexterm type="function">
+ <primary>DISCARD TABLESPACE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>IMPORT TABLESPACE</primary>
+ </indexterm>
+
+ <para>
+ If you have a <quote>clean</quote> backup of an
+ <filename>.ibd</filename> file, you can restore it to the MySQL
+ installation from which it originated as follows:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
+</programlisting>
+
+ <para>
+ <emphasis role="bold">Caution</emphasis>: This statement
+ deletes the current <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Put the backup <filename>.ibd</filename> file back in the
+ proper database directory.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Issue this <literal>ALTER TABLE</literal> statement:
+ </para>
+
+<programlisting>
+ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
+</programlisting>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ In this context, a <quote>clean</quote>
+ <filename>.ibd</filename> file backup means:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ There are no uncommitted modifications by transactions in
+ the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ There are no unmerged insert buffer entries in the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Purge has removed all delete-marked index records from the
+ <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <command>mysqld</command> has flushed all modified pages of
+ the <filename>.ibd</filename> file from the buffer pool to
+ the file.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ You can make a clean backup <filename>.ibd</filename> file using
+ the following method:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Stop all activity from the <command>mysqld</command> server
+ and commit all transactions.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Wait until <literal>SHOW ENGINE INNODB STATUS</literal>
+ shows that there are no active transactions in the database,
+ and the main thread status of <literal>InnoDB</literal> is
+ <literal>Waiting for server activity</literal>. Then you can
+ make a copy of the <filename>.ibd</filename> file.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ <para>
+ Another method for making a clean copy of an
+ <filename>.ibd</filename> file is to use the commercial
+ <command>InnoDB Hot Backup</command> tool:
+ </para>
+
+ <orderedlist>
+
+ <listitem>
+ <para>
+ Use <command>InnoDB Hot Backup</command> to back up the
+ <literal>InnoDB</literal> installation.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Start a second <command>mysqld</command> server on the
+ backup and let it clean up the <filename>.ibd</filename>
+ files in the backup.
+ </para>
+ </listitem>
+
+ </orderedlist>
+
+ </section>
+
+ <section id="innodb-raw-devices">
+
+ <title>&title-innodb-raw-devices;</title>
+
+ <para>
+ You can also use raw disk partitions as tablespace data files.
+ By using a raw disk, you can perform non-buffered I/O on Windows
+ and on some Unix systems without filesystem overhead, which may
+ improve performance.
+ </para>
+
+ <para>
+ When you create a new data file, you must put the keyword
+ <literal>newraw</literal> immediately after the data file size
+ in <literal>innodb_data_file_path</literal>. The partition must
+ be at least as large as the size that you specify. Note that 1MB
+ in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
+ usually means 1,000,000 bytes in disk specifications.
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
+</programlisting>
+
+ <para>
+ The next time you start the server, <literal>InnoDB</literal>
+ notices the <literal>newraw</literal> keyword and initializes
+ the new partition. However, do not create or change any
+ <literal>InnoDB</literal> tables yet. Otherwise, when you next
+ restart the server, <literal>InnoDB</literal> reinitializes the
+ partition and your changes are lost. (Starting from 3.23.44, as
+ a safety measure <literal>InnoDB</literal> prevents users from
+ modifying data when any partition with <literal>newraw</literal>
+ is specified.)
+ </para>
+
+ <para>
+ After <literal>InnoDB</literal> has initialized the new
+ partition, stop the server, change <literal>newraw</literal> in
+ the data file specification to <literal>raw</literal>:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
+</programlisting>
+
+ <para>
+ Then restart the server and <literal>InnoDB</literal> allows
+ changes to be made.
+ </para>
+
+ <para>
+ On Windows, you can allocate a disk partition as a data file
+ like this:
+ </para>
+
+<programlisting>
+[mysqld]
+innodb_data_home_dir=
+innodb_data_file_path=//./D::10Gnewraw
+</programlisting>
+
+ <para>
+ The <filename>//./</filename> corresponds to the Windows syntax
+ of <filename>\\.\</filename> for accessing physical drives.
+ </para>
+
+ <para>
+ When you use raw disk partitions, be sure that they have
+ permissions that allow read and write access by the account used
+ for running the MySQL server.
+ </para>
+
+ </section>
+
</section>
<section id="innodb-start">
@@ -2534,239 +2846,6 @@
</section>
- <section id="multiple-tablespaces">
-
- <title>&title-multiple-tablespaces;</title>
-
- <para>
- You can store each <literal>InnoDB</literal> table and its
- indexes in its own file. This feature is called <quote>multiple
- tablespaces</quote> because in effect each table has its own
- tablespace.
- </para>
-
- <para>
- Using multiple tablespaces can be beneficial to users who want
- to move specific tables to separate physical disks or who wish
- to restore backups of single tables quickly without interrupting
- the use of the remaining <literal>InnoDB</literal> tables.
- </para>
-
- <para>
- You can enable multiple tablespaces by adding this line to the
- <literal>[mysqld]</literal> section of
- <filename>my.cnf</filename>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_file_per_table
-</programlisting>
-
- <para>
- After restarting the server, <literal>InnoDB</literal> stores
- each newly created table into its own file
- <filename><replaceable>tbl_name</replaceable>.ibd</filename> in
- the database directory where the table belongs. This is similar
- to what the <literal>MyISAM</literal> storage engine does, but
- <literal>MyISAM</literal> divides the table into a data file
- <filename><replaceable>tbl_name</replaceable>.MYD</filename> and
- the index file
- <filename><replaceable>tbl_name</replaceable>.MYI</filename>.
- For <literal>InnoDB</literal>, the data and the indexes are
- stored together in the <filename>.ibd</filename> file. The
- <filename><replaceable>tbl_name</replaceable>.frm</filename>
- file is still created as usual.
- </para>
-
- <para>
- If you remove the <literal>innodb_file_per_table</literal> line
- from <filename>my.cnf</filename> and restart the server,
- <literal>InnoDB</literal> creates tables inside the shared
- tablespace files again.
- </para>
-
- <para>
- <literal>innodb_file_per_table</literal> affects only table
- creation. If you start the server with this option, new tables
- are created using <filename>.ibd</filename> files, but you can
- still access tables that exist in the shared tablespace. If you
- remove the option, new tables are created in the shared
- tablespace, but you can still access any tables that were
- created using multiple tablespaces.
- </para>
-
- <para>
- <literal>InnoDB</literal> always needs the shared tablespace.
- The <filename>.ibd</filename> files are not sufficient for
- <literal>InnoDB</literal> to operate. The shared tablespace
- consists of the familiar <filename>ibdata</filename> files where
- <literal>InnoDB</literal> puts its internal data dictionary and
- undo logs.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: You cannot freely move
- <filename>.ibd</filename> files between database directories as
- you can with <literal>MyISAM</literal> table files. This is
- because the table definition is stored in the
- <literal>InnoDB</literal> shared tablespace, and because
- <literal>InnoDB</literal> must preserve the consistency of
- transaction IDs and log sequence numbers.
- </para>
-
- <para>
- Within a given MySQL installation, you can move an
- <filename>.ibd</filename> file and the associated table from one
- database to another with a <literal>RENAME TABLE</literal>
- statement:
- </para>
-
-<programlisting>
-RENAME TABLE <replaceable>old_db_name.tbl_name</replaceable> TO <replaceable>new_db_name.tbl_name</replaceable>;
-</programlisting>
-
- <indexterm type="function">
- <primary>DISCARD TABLESPACE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>IMPORT TABLESPACE</primary>
- </indexterm>
-
- <para>
- If you have a <quote>clean</quote> backup of an
- <filename>.ibd</filename> file, you can restore it to the MySQL
- installation from which it originated as follows:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
-</programlisting>
-
- <para>
- <emphasis role="bold">Caution</emphasis>: This statement
- deletes the current <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Put the backup <filename>.ibd</filename> file back in the
- proper database directory.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Issue this <literal>ALTER TABLE</literal> statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
-</programlisting>
- </listitem>
-
- </orderedlist>
-
- <para>
- In this context, a <quote>clean</quote>
- <filename>.ibd</filename> file backup means:
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- There are no uncommitted modifications by transactions in
- the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- There are no unmerged insert buffer entries in the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Purge has removed all delete-marked index records from the
- <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <command>mysqld</command> has flushed all modified pages of
- the <filename>.ibd</filename> file from the buffer pool to
- the file.
- </para>
- </listitem>
-
- </itemizedlist>
-
- <para>
- You can make a clean backup <filename>.ibd</filename> file using
- the following method:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Stop all activity from the <command>mysqld</command> server
- and commit all transactions.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Wait until <literal>SHOW ENGINE INNODB STATUS</literal>
- shows that there are no active transactions in the database,
- and the main thread status of <literal>InnoDB</literal> is
- <literal>Waiting for server activity</literal>. Then you can
- make a copy of the <filename>.ibd</filename> file.
- </para>
- </listitem>
-
- </orderedlist>
-
- <para>
- Another method for making a clean copy of an
- <filename>.ibd</filename> file is to use the commercial
- <command>InnoDB Hot Backup</command> tool:
- </para>
-
- <orderedlist>
-
- <listitem>
- <para>
- Use <command>InnoDB Hot Backup</command> to back up the
- <literal>InnoDB</literal> installation.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Start a second <command>mysqld</command> server on the
- backup and let it clean up the <filename>.ibd</filename>
- files in the backup.
- </para>
- </listitem>
-
- </orderedlist>
-
- </section>
-
</section>
<section id="adding-and-removing">
@@ -5589,85 +5668,6 @@
</section>
- <section id="innodb-raw-devices">
-
- <title>&title-innodb-raw-devices;</title>
-
- <para>
- You can also use raw disk partitions as tablespace data files.
- By using a raw disk, you can perform non-buffered I/O on Windows
- and on some Unix systems without filesystem overhead, which may
- improve performance.
- </para>
-
- <para>
- When you create a new data file, you must put the keyword
- <literal>newraw</literal> immediately after the data file size
- in <literal>innodb_data_file_path</literal>. The partition must
- be at least as large as the size that you specify. Note that 1MB
- in <literal>InnoDB</literal> is 1024 * 1024 bytes, whereas 1MB
- usually means 1,000,000 bytes in disk specifications.
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
-</programlisting>
-
- <para>
- The next time you start the server, <literal>InnoDB</literal>
- notices the <literal>newraw</literal> keyword and initializes
- the new partition. However, do not create or change any
- <literal>InnoDB</literal> tables yet. Otherwise, when you next
- restart the server, <literal>InnoDB</literal> reinitializes the
- partition and your changes are lost. (Starting from 3.23.44, as
- a safety measure <literal>InnoDB</literal> prevents users from
- modifying data when any partition with <literal>newraw</literal>
- is specified.)
- </para>
-
- <para>
- After <literal>InnoDB</literal> has initialized the new
- partition, stop the server, change <literal>newraw</literal> in
- the data file specification to <literal>raw</literal>:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw
-</programlisting>
-
- <para>
- Then restart the server and <literal>InnoDB</literal> allows
- changes to be made.
- </para>
-
- <para>
- On Windows, you can allocate a disk partition as a data file
- like this:
- </para>
-
-<programlisting>
-[mysqld]
-innodb_data_home_dir=
-innodb_data_file_path=//./D::10Gnewraw
-</programlisting>
-
- <para>
- The <filename>//./</filename> corresponds to the Windows syntax
- of <filename>\\.\</filename> for accessing physical drives.
- </para>
-
- <para>
- When you use raw disk partitions, be sure that they have
- permissions that allow read and write access by the account used
- for running the MySQL server.
- </para>
-
- </section>
-
<section id="innodb-file-space">
<title>&title-innodb-file-space;</title>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r722 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 9 Jan |
