| List: | Internals | « Previous MessageNext Message » | |
| From: | jon | Date: | July 7 2005 12:58pm |
| Subject: | bk commit - mysqldoc@docsrva tree (jon:1.2945) | ||
| View as plain text | |||
Below is the list of changes that have just been committed into a local mysqldoc repository of jon. When jon does a push these changes will be propagated to the main repository and, within 24 hours after the push, to the public repository. For information on how to access the public repository see http://www.mysql.com/doc/I/n/Installing_source_tree.html ChangeSet 1.2945 05/07/07 20:58:52 jon@stripped +1 -0 Remainder of 5.0-specific edits for SQL Syntax chapter. (Part of Operation Bifurcation.) refman-5.0/sql-syntax.xml 1.12 05/07/07 20:58:50 jon@stripped +2140 -2001 Remainder of 5.0-specific edits for this chapter. (Part of Operation Bifurcation.) # This is a BitKeeper patch. What follows are the unified diffs for the # set of deltas contained in the patch. The rest of the patch, the part # that BitKeeper cares about, is below these diffs. # User: jon # Host: gigan. # Root: /home/jon/bk/mysqldoc --- 1.11/refman-5.0/sql-syntax.xml 2005-07-07 03:41:07 +10:00 +++ 1.12/refman-5.0/sql-syntax.xml 2005-07-07 20:58:50 +10:00 @@ -11999,8 +11999,8 @@ <para> This variable is deprecated in MySQL 5.0 where it is mapped to - <literal>SQL_LOG_BIN</literal> (see <xref linkend="news-5-0-0"/> - for details). + <literal>SQL_LOG_BIN</literal>. (See <xref linkend="news-5-0-0"/> + for details.) </para></listitem> <listitem><para> @@ -12012,8 +12012,8 @@ TABLE</literal> quotes table and column names. If set to <literal>0</literal>, quoting is disabled. This option is enabled by default so that replication works for tables with table and - column names that require quoting. This variable was added in MySQL - 3.23.26. <xref linkend="show-create-table"/>. + column names that require quoting. See + <xref linkend="show-create-table"/>. </para></listitem> <listitem><para> @@ -12027,8 +12027,7 @@ <literal>LIMIT</literal> clause. This makes it possible to catch <literal>UPDATE</literal> or <literal>DELETE</literal> statements where keys are not used properly and that would probably change or - delete a large number of rows. This variable was added in MySQL - 3.22.32. + delete a large number of rows. </para></listitem> <listitem><para> @@ -12069,7 +12068,6 @@ This variable controls whether single-row <literal>INSERT</literal> statements produce an information string if warnings occur. The default is 0. Set the value to 1 to produce an information string. - This variable was added in MySQL 3.22.11. </para></listitem> <listitem><para> @@ -12084,37 +12082,24 @@ timestamp, not a MySQL timestamp. </para> - <para> -<!-- THIS IS NOT IMPLEMENTED --> - </para> - - <para> -<!-- @item TIME_FORMAT = @var{format_str} --> - </para> - - <para> -<!-- Determines how the server converts @code{TIME} values to strings. This --> - </para> - - <para> -<!-- variable is available as a global, local, or command-line --> - </para> - - <para> -<!-- option. @var{format_str} can be specified conveniently using the --> - </para> - - <para> -<!-- @code{GET_FORMAT()} function. --> - </para> - - <para> -<!-- @xref{Date and time functions}. --> - </para></listitem> - - <listitem><para> - <literal>UNIQUE_CHECKS = {0 | 1}</literal> - </para> +<!-- + NOT YET IMPLEMENTED: + + @item TIME_FORMAT = @var{format_str} + + Determines how the server converts @code{TIME} values to strings. + This variable is available as a global, local, or command-line + option. @var{format_str} can be specified conveniently using the + @code{GET_FORMAT()} function. + + @xref{Date and time functions}. +--> + </listitem> + + <listitem> + <para> + <literal>UNIQUE_CHECKS = {0 | 1}</literal> + </para> <para> If set to <literal>1</literal> (the default), uniqueness checks for @@ -12123,8 +12108,9 @@ not done for index entries inserted into InnoDB's insert buffer. If you know for certain that your data does not contain uniqueness violations, you can set this to 0 to speed up large table imports - to InnoDB. This variable was added in MySQL 3.23.52. - </para></listitem> + to InnoDB. + </para> + </listitem> </itemizedlist> @@ -12349,11 +12335,6 @@ bytes used to store one character. </para> - <para> - <literal>SHOW CHARACTER SET</literal> is available as of MySQL - 4.1.0. - </para> - </section> <section id="show-collation"> @@ -12371,7 +12352,8 @@ <para> The output from <literal>SHOW COLLATION</literal> includes all available character sets. It takes an optional - <literal>LIKE</literal> clause that indicates which collation names + <literal>LIKE</literal> clause whose + <replaceable>pattern</replaceable> indicates which collation names to match. For example: </para> @@ -12399,10 +12381,6 @@ required to sort strings expressed in the character set. </para> - <para> - <literal>SHOW COLLATION</literal> is available as of MySQL 4.1.0. - </para> - </section> <section id="show-columns"> @@ -12440,17 +12418,16 @@ </para> <para> - The <literal>FULL</literal> keyword can be used from MySQL 3.23.32 - on. It causes the output to include the privileges you have for - each column. As of MySQL 4.1, <literal>FULL</literal> also causes - any per-column comments to be displayed. + The <literal>FULL</literal> keyword causes the output to include + the privileges you have as well as any per-column comments for each + column. </para> <para> You can use <replaceable>db_name.tbl_name</replaceable> as an alternative to the <literal><replaceable>tbl_name</replaceable> - FROM <replaceable>db_name</replaceable></literal> syntax. These two - statements are equivalent: + FROM <replaceable>db_name</replaceable></literal> syntax. In other + words, these two statements are equivalent: </para> <programlisting> @@ -12491,8 +12468,8 @@ <para> Shows a <literal>CREATE DATABASE</literal> statement that creates - the given database. It was added in MySQL 4.1. <literal>SHOW CREATE - SCHEMA</literal> can be used as of MySQL 5.0.2. + the given database. <literal>SHOW CREATE SCHEMA</literal> can be + used as of MySQL 5.0.2. </para> <programlisting> @@ -12519,8 +12496,8 @@ <para> Shows a <literal>CREATE TABLE</literal> statement that creates the - given table. It was added in MySQL 3.23.20. As of MySQL 5.0.1, this - statement also works with views. + given table. As of MySQL 5.0.1, this statement also works with + views. </para> <programlisting> @@ -12531,7 +12508,7 @@ id INT(11) default NULL auto_increment, s char(60) default NULL, PRIMARY KEY (id) -) TYPE=MyISAM +) ENGINE=MyISAM </programlisting> @@ -12563,10 +12540,9 @@ <para> <literal>SHOW DATABASES</literal> lists the databases on the MySQL server host. You can also get this list using the - <command>mysqlshow</command> command. As of MySQL 4.0.2, you see - only those databases for which you have some kind of privilege, if - you don't have the global <literal>SHOW DATABASES</literal> - privilege. + <command>mysqlshow</command> command. In MySQL 5.0, you see only + those databases for which you have some kind of privilege, if you + don't have the global <literal>SHOW DATABASES</literal> privilege. </para> <para> @@ -12690,80 +12666,87 @@ <literal>SHOW ENGINES</literal> shows you status information about the storage engines. This is particularly useful for checking whether a storage engine is supported, or to see what the default - engine is. This statement is implemented in MySQL 4.1.2. - <literal>SHOW TABLE TYPES</literal> is a deprecated synonym. + engine is. <literal>SHOW TABLE TYPES</literal> is a deprecated + synonym. </para> + + +<!-- Output shown is from 5.0.7-beta; update as required. --> <programlisting> mysql> SHOW ENGINES\G *************************** 1. row *************************** - Engine: MyISAM +Engine: MyISAM Support: DEFAULT Comment: Default engine as of MySQL 3.23 with great performance *************************** 2. row *************************** - Engine: HEAP +Engine: MEMORY Support: YES -Comment: Alias for MEMORY +Comment: Hash based, stored in memory, useful for temporary tables *************************** 3. row *************************** - Engine: MEMORY +Engine: HEAP Support: YES -Comment: Hash based, stored in memory, useful for temporary tables +Comment: Alias for MEMORY *************************** 4. row *************************** - Engine: MERGE +Engine: MERGE Support: YES Comment: Collection of identical MyISAM tables *************************** 5. row *************************** - Engine: MRG_MYISAM +Engine: MRG_MYISAM Support: YES Comment: Alias for MERGE *************************** 6. row *************************** - Engine: ISAM +Engine: ISAM Support: NO Comment: Obsolete storage engine, now replaced by MyISAM *************************** 7. row *************************** - Engine: MRG_ISAM +Engine: MRG_ISAM Support: NO Comment: Obsolete storage engine, now replaced by MERGE *************************** 8. row *************************** - Engine: InnoDB +Engine: InnoDB Support: YES Comment: Supports transactions, row-level locking, and foreign keys *************************** 9. row *************************** - Engine: INNOBASE +Engine: INNOBASE Support: YES Comment: Alias for INNODB *************************** 10. row *************************** - Engine: BDB +Engine: BDB Support: YES Comment: Supports transactions and page-level locking *************************** 11. row *************************** - Engine: BERKELEYDB +Engine: BERKELEYDB Support: YES Comment: Alias for BDB *************************** 12. row *************************** - Engine: NDBCLUSTER -Support: YES +Engine: NDBCLUSTER +Support: NO Comment: Clustered, fault-tolerant, memory-based tables *************************** 13. row *************************** - Engine: NDB -Support: YES +Engine: NDB +Support: NO Comment: Alias for NDBCLUSTER *************************** 14. row *************************** - Engine: EXAMPLE -Support: YES +Engine: EXAMPLE +Support: NO Comment: Example storage engine *************************** 15. row *************************** - Engine: ARCHIVE +Engine: ARCHIVE Support: YES Comment: Archive storage engine *************************** 16. row *************************** - Engine: CSV -Support: YES +Engine: CSV +Support: NO Comment: CSV storage engine *************************** 17. row *************************** - Engine: FEDERATED +Engine: FEDERATED Support: YES Comment: Federated MySQL storage engine +*************************** 18. row *************************** +Engine: BLACKHOLE +Support: YES +Comment: /dev/null storage engine (anything you write to it disappears) </programlisting> <para> @@ -12793,8 +12776,7 @@ <para> This statement is similar to <literal>SHOW WARNINGS</literal>, except that instead of displaying errors, warnings, and notes, it - displays only errors. <literal>SHOW ERRORS</literal> is available - as of MySQL 4.1.0. + displays only errors. </para> <para> @@ -12856,8 +12838,8 @@ </programlisting> <para> - As of MySQL 4.1.2, to list privileges for the current session, you - can use any of the following statements: + To list privileges for the current session, you can use any of the + following statements: </para> <programlisting> @@ -12866,18 +12848,6 @@ SHOW GRANTS FOR CURRENT_USER(); </programlisting> - <para> - Before MySQL 4.1.2, you can find out what user the session was - authenticated as by selecting the value of the - <literal>CURRENT_USER()</literal> function (new in MySQL 4.0.6). - Then use that value in the <literal>SHOW GRANTS</literal> - statement. See <xref linkend="information-functions"/>. - </para> - - <para> - <literal>SHOW GRANTS</literal> is available as of MySQL 3.23.4. - </para> - </section> <section id="show-index"> @@ -13037,21 +13007,12 @@ </para> <para> - Various remarks. Before MySQL 4.0.2 when the - <literal>Index_type</literal> column was added, - <literal>Comment</literal> indicates whether an index is - <literal>FULLTEXT</literal>. + Various remarks. </para></listitem> </itemizedlist> <para> - The <literal>Packed</literal> and <literal>Comment</literal> - columns were added in MySQL 3.23.0. The <literal>Null</literal> and - <literal>Index_type</literal> columns were added in MySQL 4.0.2. - </para> - - <para> You can use <replaceable>db_name.tbl_name</replaceable> as an alternative to the <literal><replaceable>tbl_name</replaceable> FROM <replaceable>db_name</replaceable></literal> syntax. These two @@ -13081,10 +13042,8 @@ </programlisting> <para> - This statement shows extensive information about the state of the - <literal>InnoDB</literal> storage engine. As of MySQL 4.1.2, it is - deprecated and <literal>SHOW ENGINE INNODB STATUS</literal> should - be used instead. See <xref linkend="show-engine"/>. + In MySQL 5.0, this is a deprecated synonym for <literal>SHOW ENGINE + INNODB STATUS</literal>. See <xref linkend="show-engine"/>. </para> </section> @@ -13098,12 +13057,8 @@ </programlisting> <para> - <literal>SHOW LOGS</literal> displays status information about - existing <literal>BDB</literal> log files. It was implemented in - MySQL 3.23.29. An alias for it (available as of MySQL 4.1.1) is - <literal>SHOW BDB LOGS</literal>. As of MySQL 4.1.2, this statement - is deprecated and <literal>SHOW ENGINE BDB LOGS</literal> should be - used instead. See <xref linkend="show-engine"/>. + In MySQL 5.0, this is a deprecated synonym for <literal>SHOW ENGINE + BDB LOGS</literal>. See <xref linkend="show-engine"/>. </para> </section> @@ -13122,117 +13077,122 @@ <para> <literal>SHOW PRIVILEGES</literal> shows the list of system - privileges that the MySQL server supports. This statement is - implemented as of MySQL 4.1.0. The output depends on the version of - your server. + privileges that the MySQL server supports. The exact output depends + on the version of your server. </para> +<!-- Output shown is from 5.0.7-beta; update as required. --> + <programlisting> mysql> SHOW PRIVILEGES\G *************************** 1. row *************************** Privilege: Alter - Context: Tables - Comment: To alter the table +Context: Tables +Comment: To alter the table *************************** 2. row *************************** Privilege: Alter routine - Context: Functions,Procedures - Comment: To alter or drop stored functions/procedures +Context: Functions,Procedures +Comment: To alter or drop stored functions/procedures *************************** 3. row *************************** Privilege: Create - Context: Databases,Tables,Indexes - Comment: To create new databases and tables +Context: Databases,Tables,Indexes +Comment: To create new databases and tables *************************** 4. row *************************** Privilege: Create routine - Context: Functions,Procedures - Comment: To use CREATE FUNCTION/PROCEDURE +Context: Functions,Procedures +Comment: To use CREATE FUNCTION/PROCEDURE *************************** 5. row *************************** Privilege: Create temporary tables - Context: Databases - Comment: To use CREATE TEMPORARY TABLE +Context: Databases +Comment: To use CREATE TEMPORARY TABLE *************************** 6. row *************************** Privilege: Create view - Context: Tables - Comment: To create new views +Context: Tables +Comment: To create new views *************************** 7. row *************************** -Privilege: Delete - Context: Tables - Comment: To delete existing rows +Privilege: Create user +Context: Server Admin +Comment: To create new users *************************** 8. row *************************** -Privilege: Drop - Context: Databases,Tables - Comment: To drop databases, tables, and views +Privilege: Delete +Context: Tables +Comment: To delete existing rows *************************** 9. row *************************** -Privilege: Execute - Context: Functions,Procedures - Comment: To execute stored routines +Privilege: Drop +Context: Databases,Tables +Comment: To drop databases, tables, and views *************************** 10. row *************************** -Privilege: File - Context: File access on server - Comment: To read and write files on the server +Privilege: Execute +Context: Functions,Procedures +Comment: To execute stored routines *************************** 11. row *************************** -Privilege: Grant option - Context: Databases,Tables,Functions,Procedures - Comment: To give to other users those privileges you possess +Privilege: File +Context: File access on server +Comment: To read and write files on the server *************************** 12. row *************************** -Privilege: Index - Context: Tables - Comment: To create or drop indexes +Privilege: Grant option +Context: Databases,Tables,Functions,Procedures +Comment: To give to other users those privileges you possess *************************** 13. row *************************** -Privilege: Insert - Context: Tables - Comment: To insert data into tables +Privilege: Index +Context: Tables +Comment: To create or drop indexes *************************** 14. row *************************** -Privilege: Lock tables - Context: Databases - Comment: To use LOCK TABLES (together with SELECT privilege) +Privilege: Insert +Context: Tables +Comment: To insert data into tables *************************** 15. row *************************** -Privilege: Process - Context: Server Admin - Comment: To view the plain text of currently executing queries +Privilege: Lock tables +Context: Databases +Comment: To use LOCK TABLES (together with SELECT privilege) *************************** 16. row *************************** -Privilege: References - Context: Databases,Tables - Comment: To have references on tables +Privilege: Process +Context: Server Admin +Comment: To view the plain text of currently executing queries *************************** 17. row *************************** -Privilege: Reload - Context: Server Admin - Comment: To reload or refresh tables, logs and privileges +Privilege: References +Context: Databases,Tables +Comment: To have references on tables *************************** 18. row *************************** -Privilege: Replication client - Context: Server Admin - Comment: To ask where the slave or master servers are +Privilege: Reload +Context: Server Admin +Comment: To reload or refresh tables, logs and privileges *************************** 19. row *************************** -Privilege: Replication slave - Context: Server Admin - Comment: To read binary log events from the master +Privilege: Replication client +Context: Server Admin +Comment: To ask where the slave or master servers are *************************** 20. row *************************** -Privilege: Select - Context: Tables - Comment: To retrieve rows from table +Privilege: Replication slave +Context: Server Admin +Comment: To read binary log events from the master *************************** 21. row *************************** -Privilege: Show databases - Context: Server Admin - Comment: To see all databases with SHOW DATABASES +Privilege: Select +Context: Tables +Comment: To retrieve rows from table *************************** 22. row *************************** -Privilege: Show view - Context: Tables - Comment: To see views with SHOW CREATE VIEW +Privilege: Show databases +Context: Server Admin +Comment: To see all databases with SHOW DATABASES *************************** 23. row *************************** -Privilege: Shutdown - Context: Server Admin - Comment: To shut down the server +Privilege: Show view +Context: Tables +Comment: To see views with SHOW CREATE VIEW *************************** 24. row *************************** -Privilege: Super - Context: Server Admin - Comment: To use KILL thread, SET GLOBAL, CHANGE MASTER, etc. +Privilege: Shutdown +Context: Server Admin +Comment: To shut down the server *************************** 25. row *************************** -Privilege: Update - Context: Tables - Comment: To update existing rows +Privilege: Super +Context: Server Admin +Comment: To use KILL thread, SET GLOBAL, CHANGE MASTER, etc. *************************** 26. row *************************** +Privilege: Update +Context: Tables +Comment: To update existing rows +*************************** 27. row *************************** Privilege: Usage - Context: Server Admin - Comment: No privileges - allow connect only +Context: Server Admin +Comment: No privileges - allow connect only </programlisting> </section> @@ -13282,8 +13242,8 @@ </para> <para> - Starting from MySQL 4.0.12, the statement reports the hostname for - TCP/IP connections in + In MySQL 5.0, the statement reports the hostname for TCP/IP + connections in <literal><replaceable>host_name</replaceable>:<replaceable>client_port</replaceable></literal> format to make it easier to determine which client is doing what. </para> @@ -13312,270 +13272,321 @@ The thread is performing (automatic) checking of the table. </para></listitem> - <listitem><para> - <literal>Closing tables</literal> - </para> + <listitem> + <para> + <literal>Closing tables</literal> + </para> <para> Means that the thread is flushing the changed table data to disk and closing the used tables. This should be a fast operation. If not, then you should verify that you don't have a full disk and that the disk is not in very heavy use. - </para></listitem> - - <listitem><para> - <literal>Connect Out</literal> </para> + </listitem> + + <listitem> + <para> + <literal>Connect Out</literal> + </para> <para> Slave connecting to master. - </para></listitem> - - <listitem><para> - <literal>Copying to tmp table on disk</literal> </para> + </listitem> + + <listitem> + <para> + <literal>Copying to tmp table on disk</literal> + </para> <para> The temporary result set was larger than <literal>tmp_table_size</literal> and the thread is changing the temporary table from in-memory to disk-based format to save memory. - </para></listitem> - - <listitem><para> - <literal>Creating tmp table</literal> </para> + </listitem> + + <listitem> + <para> + <literal>Creating tmp table</literal> + </para> <para> The thread is creating a temporary table to hold a part of the result for the query. - </para></listitem> - - <listitem><para> - <literal>deleting from main table</literal> </para> + </listitem> + + <listitem> + <para> + <literal>deleting from main table</literal> + </para> <para> The server is executing the first part of a multiple-table delete and deleting only from the first table. - </para></listitem> - - <listitem><para> - <literal>deleting from reference tables</literal> </para> + </listitem> - <para> - The server is executing the second part of a multiple-table delete - and deleting the matched rows from the other tables. - </para></listitem> - - <listitem><para> - <literal>Flushing tables</literal> - </para> - - <para> - The thread is executing <literal>FLUSH TABLES</literal> and is - waiting for all threads to close their tables. - </para></listitem> - - <listitem><para> - <literal>Killed</literal> - </para> - - <para> - Someone has sent a kill to the thread and it should abort next - time it checks the kill flag. The flag is checked in each major - loop in MySQL, but in some cases it might still take a short time - for the thread to die. If the thread is locked by some other - thread, the kill takes effect as soon as the other thread releases - its lock. - </para></listitem> - - <listitem><para> - <literal>Locked</literal> - </para> - - <para> - The query is locked by another query. - </para></listitem> - - <listitem><para> - <literal>Sending data</literal> - </para> - - <para> - The thread is processing rows for a <literal>SELECT</literal> - statement and also is sending data to the client. - </para></listitem> - - <listitem><para> - <literal>Sorting for group</literal> - </para> - - <para> - The thread is doing a sort to satisfy a <literal>GROUP - BY</literal>. - </para></listitem> - - <listitem><para> - <literal>Sorting for order</literal> - </para> - - <para> - The thread is doing a sort to satisfy a <literal>ORDER - BY</literal>. - </para></listitem> - - <listitem><para> - <literal>Opening tables</literal> - </para> - - <para> - The thread is trying to open a table. This is should be very fast - procedure, unless something prevents opening. For example, an - <literal>ALTER TABLE</literal> or a <literal>LOCK TABLE</literal> - statement can prevent opening a table until the statement is - finished. - </para></listitem> - - <listitem><para> - <literal>Removing duplicates</literal> - </para> - - <para> - The query was using <literal>SELECT DISTINCT</literal> in such a - way that MySQL couldn't optimize away the distinct operation at an - early stage. Because of this, MySQL requires an extra stage to - remove all duplicated rows before sending the result to the - client. - </para></listitem> - - <listitem><para> - <literal>Reopen table</literal> - </para> - - <para> - The thread got a lock for the table, but noticed after getting the - lock that the underlying table structure changed. It has freed the - lock, closed the table, and is trying to reopen it. - </para></listitem> - - <listitem><para> - <literal>Repair by sorting</literal> - </para> - - <para> - The repair code is using sorting to create indexes. - </para></listitem> - - <listitem><para> - <literal>Repair with keycache</literal> - </para> - - <para> - The repair code is using creating keys one by one through the key - cache. This is much slower than <literal>Repair by - sorting</literal>. - </para></listitem> - - <listitem><para> - <literal>Searching rows for update</literal> - </para> - - <para> - The thread is doing a first phase to find all matching rows before - updating them. This has to be done if the - <literal>UPDATE</literal> is changing the index that is used to - find the involved rows. - </para></listitem> - - <listitem><para> - <literal>Sleeping</literal> - </para> - - <para> - The thread is waiting for the client to send a new statement to - it. - </para></listitem> - - <listitem><para> - <literal>System lock</literal> - </para> - - <para> - The thread is waiting to get an external system lock for the - table. If you are not using multiple <command>mysqld</command> - servers that are accessing the same tables, you can disable system - locks with the <literal>--skip-external-locking</literal> option. - </para></listitem> - - <listitem><para> - <literal>Upgrading lock</literal> - </para> - - <para> - The <literal>INSERT DELAYED</literal> handler is trying to get a - lock for the table to insert rows. - </para></listitem> - - <listitem><para> - <literal>Updating</literal> - </para> - - <para> - The thread is searching for rows to update and updating them. - </para></listitem> - - <listitem><para> - <literal>User Lock</literal> - </para> - - <para> - The thread is waiting on a <literal>GET_LOCK()</literal>. - </para></listitem> - - <listitem><para> - <literal>Waiting for tables</literal> - </para> - - <para> - The thread got a notification that the underlying structure for a - table has changed and it needs to reopen the table to get the new - structure. However, to be able to reopen the table, it must wait - until all other threads have closed the table in question. - </para> - - <para> - This notification happens if another thread has used - <literal>FLUSH TABLES</literal> or one of the following statements - on the table in question: <literal>FLUSH TABLES - <replaceable>tbl_name</replaceable></literal>, <literal>ALTER - TABLE</literal>, <literal>RENAME TABLE</literal>, <literal>REPAIR - TABLE</literal>, <literal>ANALYZE TABLE</literal>, or - <literal>OPTIMIZE TABLE</literal>. - </para></listitem> - - <listitem><para> - <literal>waiting for handler insert</literal> - </para> - - <para> - The <literal>INSERT DELAYED</literal> handler has processed all - pending inserts and is waiting for new ones. - </para></listitem> + <listitem> + <para> + <literal>deleting from reference tables</literal> + </para> + + <para> + The server is executing the second part of a multiple-table delete + and deleting the matched rows from the other tables. + </para> + </listitem> + + <listitem> + <para> + <literal>Flushing tables</literal> + </para> + + <para> + The thread is executing <literal>FLUSH TABLES</literal> and is + waiting for all threads to close their tables. + </para> + </listitem> + + <listitem> + <para> + <literal>Killed</literal> + </para> + + <para> + Someone has sent a <literal>KILL</literal> command to the thread + and it should abort next time it checks the kill flag. The flag + is checked in each major loop in MySQL, but in some cases it + might still take a short time for the thread to die. If the + thread is locked by some other thread, the kill takes effect as + soon as the other thread releases its lock. + </para> + </listitem> + + <listitem> + <para> + <literal>Locked</literal> + </para> + + <para> + The query is locked by another query. + </para> + </listitem> + + <listitem> + <para> + <literal>Sending data</literal> + </para> + + <para> + The thread is processing rows for a <literal>SELECT</literal> + statement and also is sending data to the client. + </para> + </listitem> + + <listitem> + <para> + <literal>Sorting for group</literal> + </para> + + <para> + The thread is doing a sort to satisfy a <literal>GROUP + BY</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Sorting for order</literal> + </para> + + <para> + The thread is doing a sort to satisfy a <literal>ORDER + BY</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Opening tables</literal> + </para> + + <para> + The thread is trying to open a table. This is should be very fast + procedure, unless something prevents opening. For example, an + <literal>ALTER TABLE</literal> or a <literal>LOCK TABLE</literal> + statement can prevent opening a table until the statement is + finished. + </para> + </listitem> + + <listitem> + <para> + <literal>Removing duplicates</literal> + </para> + + <para> + The query was using <literal>SELECT DISTINCT</literal> in such a + way that MySQL couldn't optimize away the distinct operation at an + early stage. Because of this, MySQL requires an extra stage to + remove all duplicated rows before sending the result to the + client. + </para> + </listitem> + + <listitem> + <para> + <literal>Reopen table</literal> + </para> + + <para> + The thread got a lock for the table, but noticed after getting the + lock that the underlying table structure changed. It has freed the + lock, closed the table, and is trying to reopen it. + </para> + </listitem> + + <listitem> + <para> + <literal>Repair by sorting</literal> + </para> + + <para> + The repair code is using a sort to create indexes. + </para> + </listitem> + + <listitem> + <para> + <literal>Repair with keycache</literal> + </para> + + <para> + The repair code is using creating keys one by one through the + key cache. This is much slower than <literal>Repair by + sorting</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Searching rows for update</literal> + </para> + + <para> + The thread is doing a first phase to find all matching rows + before updating them. This has to be done if the + <literal>UPDATE</literal> is changing the index that is used to + find the involved rows. + </para> + </listitem> + + <listitem> + <para> + <literal>Sleeping</literal> + </para> + + <para> + The thread is waiting for the client to send a new statement to + it. + </para> + </listitem> + + <listitem> + <para> + <literal>System lock</literal> + </para> + + <para> + The thread is waiting to get an external system lock for the + table. If you are not using multiple <command>mysqld</command> + servers that are accessing the same tables, you can disable + system locks with the + <literal>--skip-external-locking</literal> option. + </para> + </listitem> + + <listitem> + <para> + <literal>Upgrading lock</literal> + </para> + + <para> + The <literal>INSERT DELAYED</literal> handler is trying to get + a lock for the table to insert rows. + </para> + </listitem> + + <listitem> + <para> + <literal>Updating</literal> + </para> + + <para> + The thread is searching for rows to update and updating them. + </para> + </listitem> + + <listitem> + <para> + <literal>User Lock</literal> + </para> + + <para> + The thread is waiting on a <literal>GET_LOCK()</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Waiting for tables</literal> + </para> + + <para> + The thread got a notification that the underlying structure for + a table has changed and it needs to reopen the table to get the + new structure. However, to be able to reopen the table, it must + wait until all other threads have closed the table in question. + </para> + + <para> + This notification takes place if another thread has used + <literal>FLUSH TABLES</literal> or one of the following + statements on the table in question: <literal>FLUSH TABLES + <replaceable>tbl_name</replaceable></literal>, <literal>ALTER + TABLE</literal>, <literal>RENAME TABLE</literal>, + <literal>REPAIR TABLE</literal>, <literal>ANALYZE + TABLE</literal>, or <literal>OPTIMIZE TABLE</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>waiting for handler insert</literal> + </para> + + <para> + The <literal>INSERT DELAYED</literal> handler has processed all + pending inserts and is waiting for new ones. + </para> + </listitem> </itemizedlist> <para> - Most states correspond to very quick operations. If a thread stays - in any of these states for many seconds, there might be a problem - that needs to be investigated. + Most states correspond to very quick operations. If a thread stays + in any of these states for many seconds, there might be a problem + that needs to be investigated. </para> <para> - There are some other states that are not mentioned in the preceding - list, but many of them are useful only for finding bugs in the - server. + There are some other states that are not mentioned in the + preceding list, but many of them are useful only for finding bugs + in the server. </para> </section> @@ -13602,15 +13613,15 @@ </indexterm> <para> - <literal>SHOW STATUS</literal> provides server status information. - This information also can be obtained using the <command>mysqladmin - extended-status</command> command. + <literal>SHOW STATUS</literal> provides server status information. + This information also can be obtained using the + <command>mysqladmin extended-status</command> command. </para> <para> - Partial output is shown here. The list of variables and their - values may be different for your server. The meaning of each - variable is given in See <xref linkend="server-status-variables"/>. + Partial output is shown here. The list of variables and their + values may be different for your server. The meaning of each + variable is given in <xref linkend="server-status-variables"/>. </para> <programlisting> @@ -13626,13 +13637,13 @@ | Created_tmp_disk_tables | 0 | | Created_tmp_tables | 8340 | | Created_tmp_files | 60 | -... +... ... ... | Open_tables | 1 | | Open_files | 2 | | Open_streams | 0 | | Opened_tables | 44600 | | Questions | 2026873 | -... +... ... ... | Table_locks_immediate | 1920382 | | Table_locks_waited | 0 | | Threads_cached | 0 | @@ -13644,8 +13655,8 @@ </programlisting> <para> - With a <literal>LIKE</literal> clause, the statement displays only - those variables that match the pattern: + With a <literal>LIKE</literal> clause, the statement displays only + those variables that match the pattern: </para> <programlisting> @@ -13662,19 +13673,19 @@ </programlisting> <para> - The <literal>GLOBAL</literal> and <literal>SESSION</literal> - options are new in MySQL 5.0.2 With <literal>GLOBAL</literal>, you - get the status values for all connections to MySQL. With - <literal>SESSION</literal>, you get the status values for the - current connection. If you use neither option, the default is - <literal>SESSION</literal>. <literal>LOCAL</literal> is a synonym - for <literal>SESSION</literal>. + The <literal>GLOBAL</literal> and <literal>SESSION</literal> + options are new in MySQL 5.0.2 With <literal>GLOBAL</literal>, you + get the status values for all connections to MySQL. With + <literal>SESSION</literal>, you get the status values for the + current connection. If you use neither option, the default is + <literal>SESSION</literal>. <literal>LOCAL</literal> is a synonym + for <literal>SESSION</literal>. </para> <para> - Note that some status variables only have a global value. For these - you get the same value for both <literal>GLOBAL</literal> and - <literal>SESSION</literal>. + Note that some status variables only have a global value. For + these you get the same value for both <literal>GLOBAL</literal> + and <literal>SESSION</literal>. </para> </section> @@ -13703,218 +13714,256 @@ </programlisting> <para> - <literal>SHOW TABLE STATUS</literal> works likes <literal>SHOW - TABLE</literal>, but provides a lot of information about each - table. You can also get this list using the <command>mysqlshow - --status <replaceable>db_name</replaceable></command> command. This - statement was added in MySQL 3.23. As of MySQL 5.0.1, it also - displays information about views. + <literal>SHOW TABLE STATUS</literal> works likes <literal>SHOW + TABLE</literal>, but provides a lot of information about each + table. You can also get this list using the <command>mysqlshow + --status <replaceable>db_name</replaceable></command> command. + As of MySQL 5.0.1, this statement also displays information about + views. </para> <para> - <literal>SHOW TABLE STATUS</literal> returns the following fields: + <literal>SHOW TABLE STATUS</literal> returns the following fields: </para> <itemizedlist> - <listitem><para> - <literal>Name</literal> - </para> - - <para> - The name of the table. - </para></listitem> - - <listitem><para> - <literal>Engine</literal> - </para> - - <para> - The storage engine for the table. Before MySQL 4.1.2, this value - is labeled as <literal>Type</literal>. See - <xref linkend="storage-engines"/>. - </para></listitem> - - <listitem><para> - <literal>Version</literal> - </para> - - <para> - The version number of the table's <filename>.frm</filename> file. - </para></listitem> - - <listitem><para> - <literal>Row_format</literal> - </para> - - <para> - The row storage format (<literal>Fixed</literal>, - <literal>Dynamic</literal>, <literal>Compressed</literal>, - <literal>Redundant</literal>, <literal>Compact</literal>). - Starting with MySQL/InnoDB 5.0.3, the format of InnoDB tables is - reported as <literal>Redundant</literal> or - <literal>Compact</literal>. Before 5.0.3, InnoDB tables are always - in the <literal>Redundant</literal> format. - </para></listitem> - - <listitem><para> - <literal>Rows</literal> - </para> - - <para> - The number of rows. Some storage engines, such as - <literal>MyISAM</literal> and <literal>ISAM</literal>, store the - exact count. - </para> - - <para> - For other storage engines, such as <literal>InnoDB</literal>, this - value is an approximation, and may vary from the actual value by - as much as 40 to 50%. In such cases, use <literal>SELECT - COUNT(*)</literal> to obtain an accurate count. - </para> - - <para> - The <literal>Rows</literal> value is <literal>NULL</literal> for - tables in the <literal>INFORMATION_SCHEMA</literal> database. - </para></listitem> - - <listitem><para> - <literal>Avg_row_length</literal> - </para> - - <para> - The average row length. - </para> - - <para> -<!-- TODO: Next few item descriptions are MyISAM-specific; generalize. --> - </para></listitem> - - <listitem><para> - <literal>Data_length</literal> - </para> - - <para> - The length of the data file. - </para></listitem> - - <listitem><para> - <literal>Max_data_length</literal> - </para> - - <para> - The maximum length of the data file. This is the total number of - data bytes that can be stored in the table, given the data pointer - size used. - </para></listitem> - - <listitem><para> - <literal>Index_length</literal> - </para> - - <para> - The length of the index file. - </para></listitem> - - <listitem><para> - <literal>Data_free</literal> - </para> - - <para> - The number of allocated but unused bytes. - </para></listitem> - - <listitem><para> - <literal>Auto_increment</literal> - </para> - - <para> - The next <literal>AUTO_INCREMENT</literal> value. - </para></listitem> - - <listitem><para> - <literal>Create_time</literal> - </para> - - <para> - When the table was created. - </para></listitem> - - <listitem><para> - <literal>Update_time</literal> - </para> - - <para> - When the data file was last updated. - </para></listitem> - - <listitem><para> - <literal>Check_time</literal> - </para> - - <para> - When the table was last checked. - </para></listitem> - - <listitem><para> - <literal>Collation</literal> - </para> - - <para> - The table's character set and collation. (New in 4.1.1) - </para></listitem> - - <listitem><para> - <literal>Checksum</literal> - </para> - - <para> - The live checksum value (if any). (New in 4.1.1) - </para></listitem> - - <listitem><para> - <literal>Create_options</literal> - </para> - - <para> - Extra options used with <literal>CREATE TABLE</literal>. - </para></listitem> - - <listitem><para> - <literal>Comment</literal> - </para> - - <para> - The comment used when creating the table (or some information why - MySQL couldn't access the table information). - </para></listitem> - - </itemizedlist> + <listitem> + <para> + <literal>Name</literal> + </para> + + <para> + The name of the table. + </para> + </listitem> + + <listitem> + <para> + <literal>Engine</literal> + </para> + + <para> + The storage engine for the table. Before MySQL 4.1.2, this + value is labeled as <literal>Type</literal>. See + <xref linkend="storage-engines"/>. + </para> + </listitem> + + <listitem> + <para> + <literal>Version</literal> + </para> + + <para> + The version number of the table's <filename>.frm</filename> + file. + </para> + </listitem> + + <listitem> + <para> + <literal>Row_format</literal> + </para> + + <para> + The row storage format (<literal>Fixed</literal>, + <literal>Dynamic</literal>, <literal>Compressed</literal>, + <literal>Redundant</literal>, <literal>Compact</literal>). + Starting with MySQL/InnoDB 5.0.3, the format of InnoDB tables + is reported as <literal>Redundant</literal> or + <literal>Compact</literal>. Priot to 5.0.3, InnoDB tables are + always in the <literal>Redundant</literal> format. + </para> + </listitem> + + <listitem> + <para> + <literal>Rows</literal> + </para> + + <para> + The number of rows. Some storage engines, such as + <literal>MyISAM</literal>, store the exact count. + </para> + + <para> + For other storage engines, such as <literal>InnoDB</literal>, + this value is an approximation, and may vary from the actual + value by as much as 40 to 50%. In such cases, use + <literal>SELECT COUNT(*)</literal> to obtain an accurate count. + </para> + + <para> + The <literal>Rows</literal> value is <literal>NULL</literal> + for tables in the <literal>INFORMATION_SCHEMA</literal> + database. + </para> + </listitem> + + <listitem> + <para> + <literal>Avg_row_length</literal> + </para> + + <para> + The average row length. + </para> + </listitem> + +<!-- + TODO: Next few item descriptions are MyISAM-specific; + generalize. +--> + + <listitem> + <para> + <literal>Data_length</literal> + </para> + + <para> + The length of the data file. + </para> + </listitem> + + <listitem> + <para> + <literal>Max_data_length</literal> + </para> + + <para> + The maximum length of the data file. This is the total number + of bytes of data that can be stored in the table, given the + data pointer size used. + </para> + </listitem> + + <listitem> + <para> + <literal>Index_length</literal> + </para> + + <para> + The length of the index file. + </para> + </listitem> + + <listitem> + <para> + <literal>Data_free</literal> + </para> + + <para> + The number of allocated but unused bytes. + </para> + </listitem> + + <listitem> + <para> + <literal>Auto_increment</literal> + </para> + + <para> + The next <literal>AUTO_INCREMENT</literal> value. + </para> + </listitem> + + <listitem> + <para> + <literal>Create_time</literal> + </para> + + <para> + When the table was created. + </para> + </listitem> + + <listitem> + <para> + <literal>Update_time</literal> + </para> + + <para> + When the data file was last updated. + </para> + </listitem> + + <listitem> + <para> + <literal>Check_time</literal> + </para> + + <para> + When the table was last checked. + </para> + </listitem> + + <listitem> + <para> + <literal>Collation</literal> + </para> + + <para> + The table's character set and collation. + </para> + </listitem> + + <listitem> + <para> + <literal>Checksum</literal> + </para> + + <para> + The live checksum value (if any). + </para> + </listitem> + + <listitem> + <para> + <literal>Create_options</literal> + </para> + + <para> + Extra options used with <literal>CREATE TABLE</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Comment</literal> + </para> + + <para> + The comment used when creating the table (or information as to + why MySQL could not access the table information). + </para> + </listitem> + </itemizedlist> <para> - In the table comment, <literal>InnoDB</literal> tables report the - free space of the tablespace to which the table belongs. For a - table located in the shared tablespace, this is the free space of - the shared tablespace. If you are using multiple tablespaces and - the table has its own tablespace, the free space is for just that - table. + In the table comment, <literal>InnoDB</literal> tables report the + free space of the tablespace to which the table belongs. For a + table located in the shared tablespace, this is the free space of + the shared tablespace. If you are using multiple tablespaces and + the table has its own tablespace, the free space is for just that + table. </para> <para> - For <literal>MEMORY</literal> (<literal>HEAP</literal>) tables, the - <literal>Data_length</literal>, <literal>Max_data_length</literal>, - and <literal>Index_length</literal> values approximate the actual - amount of allocated memory. The allocation algorithm reserves - memory in large amounts to reduce the number of allocation - operations. + For <literal>MEMORY</literal> (<literal>HEAP</literal>) tables, + the <literal>Data_length</literal>, + <literal>Max_data_length</literal>, and + <literal>Index_length</literal> values approximate the actual + amount of allocated memory. The allocation algorithm reserves + memory in large amounts to reduce the number of allocation + operations. </para> <para> - For views, all the fields displayed by <literal>SHOW TABLE - STATUS</literal> are <literal>NULL</literal> except that - <literal>Name</literal> indicates the view name and - <literal>Comment</literal> says <literal>view</literal>. + For views, all the fields displayed by <literal>SHOW TABLE + STATUS</literal> are <literal>NULL</literal> except that + <literal>Name</literal> indicates the view name and + <literal>Comment</literal> says <literal>view</literal>. </para> </section> @@ -13923,9 +13972,11 @@ <title id='title-show-tables'>&title-show-tables;</title> -<!-- TODO: need description of SHOW OPEN TABLES output columns, particularly --> - -<!-- as the output no longer seems to *have* a Comment field --> +<!-- + TODO: need description of SHOW OPEN TABLES output columns, + particularly as the output no longer seems to *have* a Comment + field +--> <indexterm type="concept"> <primary>displaying</primary> @@ -13942,38 +13993,37 @@ </programlisting> <para> - <literal>SHOW TABLES</literal> lists the - non-<literal>TEMPORARY</literal> tables in a given database. You - can also get this list using the <command>mysqlshow - <replaceable>db_name</replaceable></command> command. + <literal>SHOW TABLES</literal> lists the + non-<literal>TEMPORARY</literal> tables in a given database. You + can also get this list using the <command>mysqlshow + <replaceable>db_name</replaceable></command> command. </para> <para> Before MySQL 5.0.1, the output from <literal>SHOW TABLES</literal> contains a single column of table names. Beginning with MySQL - 5.0.1, also lists the views in the database. As of MySQL 5.0.2, the - <literal>FULL</literal> modifier is supported such that - <literal>SHOW FULL TABLES</literal> displays a second output - column. Values in the second column are <literal>BASE + 5.0.1, this command also lists any views in the database. As of + MySQL 5.0.2, the <literal>FULL</literal> modifier is supported such + that <literal>SHOW FULL TABLES</literal> displays a second output + column. Values for the second column are <literal>BASE TABLE</literal> for a table and <literal>VIEW</literal> for a view. </para> <para> - <emphasis role="bold">Note</emphasis>: If you have no privileges - for a table, the table does not show up in the output from - <literal>SHOW TABLES</literal> or <command>mysqlshow - db_name</command>. + <emphasis role="bold">Note</emphasis>: If you have no privileges + for a table, the table does not show up in the output from + <literal>SHOW TABLES</literal> or <command>mysqlshow + db_name</command>. </para> <!-- TODO: non-TEMPORARY tables only? --> <para> - <literal>SHOW OPEN TABLES</literal> lists the tables that are - currently open in the table cache. See - <xref linkend="table-cache"/>. The <literal>Comment</literal> field - in the output tells how many times the table is - <literal>cached</literal> and <literal>in_use</literal>. - <literal>OPEN</literal> can be used from MySQL 3.23.33 on. + <literal>SHOW OPEN TABLES</literal> lists the tables that are + currently open in the table cache. See + <xref linkend="table-cache"/>. The <literal>Comment</literal> + field in the output tells how many times the table is + <literal>cached</literal> and <literal>in_use</literal>. </para> </section> @@ -14009,62 +14059,80 @@ </indexterm> <para> - <literal>SHOW VARIABLES</literal> shows the values of some MySQL - system variables. This information also can be obtained using the - <command>mysqladmin variables</command> command. + <literal>SHOW VARIABLES</literal> shows the values of some MySQL + system variables. This information also can be obtained using the + <command>mysqladmin variables</command> command. </para> <para> - The <literal>GLOBAL</literal> and <literal>SESSION</literal> - options are new in MySQL 4.0.3. With <literal>GLOBAL</literal>, you - get the values that are used for new connections to MySQL. With - <literal>SESSION</literal>, you get the values that are in effect - for the current connection. If you use neither option, the default - is <literal>SESSION</literal>. <literal>LOCAL</literal> is a - synonym for <literal>SESSION</literal>. + With the <literal>GLOBAL</literal> option, you obtain the values + that are used for new connections to MySQL. With + <literal>SESSION</literal>, you get the values that are in effect + for the current connection. If you use neither option, the default + is <literal>SESSION</literal>. + </para> + + <para> + <literal>LOCAL</literal> is a synonym for + <literal>SESSION</literal>. </para> <para> - If the default values are unsuitable, you can set most of these - variables using command-line options when <command>mysqld</command> - starts or at runtime with the <literal>SET</literal> statement. See - <xref linkend="server-options"/> and <xref linkend="set-option"/>. + If the default values are unsuitable, you can set most of these + variables using command-line options when + <command>mysqld</command> starts or at runtime with the + <literal>SET</literal> statement. See + <xref linkend="server-options"/> and <xref linkend="set-option"/>. </para> <para> - Partial output is shown here. The list of variables and their - values may be different for your server. The meaning of each - variable is given in See <xref linkend="server-system-variables"/>. - Information about tuning them is provided in - <xref linkend="server-parameters"/>. + Partial output is shown here. The list of variables and their + values may be different for your server. The meaning of each + variable is given in <xref linkend="server-system-variables"/>. + Information about tuning them is provided in + <xref linkend="server-parameters"/>. </para> +<!-- Output from 5.0.7-beta; update as needed. --> + <programlisting> mysql> SHOW VARIABLES; -+---------------------------------+------------------------------+ -| Variable_name | Value | -+---------------------------------+------------------------------| -| back_log | 50 | -| basedir | /usr/local/mysql | -| bdb_cache_size | 8388572 | -| bdb_log_buffer_size | 32768 | -| bdb_home | /usr/local/mysql | -... -| max_connections | 100 | -| max_connect_errors | 10 | -| max_delayed_threads | 20 | -| max_error_count | 64 | -| max_heap_table_size | 16777216 | -| max_join_size | 4294967295 | -| max_relay_log_size | 0 | -| max_sort_length | 1024 | -... -| timezone | EEST | -| tmp_table_size | 33554432 | -| tmpdir | /tmp/:/mnt/hd2/tmp/ | -| version | 4.0.4-beta | -| wait_timeout | 28800 | -+---------------------------------+------------------------------+ ++---------------------------------+---------------------------------------------------------+ +| Variable_name | Value | ++---------------------------------+---------------------------------------------------------+ +| auto_increment_increment | 1 | +| auto_increment_offset | 1 | +| automatic_sp_privileges | ON | +| back_log | 50 | +| basedir | / | +| bdb_cache_size | 8388600 | +| bdb_home | /var/lib/mysql/ | +| bdb_log_buffer_size | 32768 | +... ... ... +| max_connections | 100 | +| max_connect_errors | 10 | +| max_delayed_threads | 20 | +| max_error_count | 64 | +| max_heap_table_size | 16777216 | +| max_join_size | 4294967295 | +| max_relay_log_size | 0 | +| max_sort_length | 1024 | +... ... ... +| time_zone | SYSTEM | +| timed_mutexes | OFF | +| tmp_table_size | 33554432 | +| tmpdir | | +| transaction_alloc_block_size | 8192 | +| transaction_prealloc_size | 4096 | +| tx_isolation | REPEATABLE-READ | +| updatable_views_with_limit | YES | +| version | 5.0.7-beta-Max | +| version_bdb | Sleepycat Software: Berkeley DB 4.1.24: (June 11, 2005) | +| version_comment | MySQL Community Edition - Max (GPL) | +| version_compile_machine | i686 | +| version_compile_os | pc-linux-gnu | +| wait_timeout | 28800 | ++---------------------------------+---------------------------------------------------------+ </programlisting> <para> @@ -14072,19 +14140,32 @@ those variables that match the pattern: </para> + +<!-- Output from 5.0.7-beta; update as needed. --> + <programlisting> mysql> SHOW VARIABLES LIKE 'have%'; -+--------------------+----------+ -| Variable_name | Value | -+--------------------+----------+ -| have_bdb | YES | -| have_innodb | YES | -| have_isam | YES | -| have_raid | NO | -| have_symlink | DISABLED | -| have_openssl | YES | -| have_query_cache | YES | -+--------------------+----------+ ++-----------------------+----------+ +| Variable_name | Value | ++-----------------------+----------+ +| have_archive | NO | +| have_bdb | YES | +| have_blackhole_engine | YES | +| have_compress | YES | +| have_crypt | YES | +| have_csv | YES | +| have_example_engine | YES | +| have_federated_engine | YES | +| have_geometry | YES | +| have_innodb | YES | +| have_isam | NO | +| have_ndbcluster | DISABLED | +| have_openssl | NO | +| have_query_cache | YES | +| have_raid | NO | +| have_rtree_keys | YES | +| have_symlink | YES | ++-----------------------+----------+ </programlisting> </section> @@ -14103,24 +14184,24 @@ </programlisting> <para> - <literal>SHOW WARNINGS</literal> shows the error, warning, and note - messages that resulted from the last statement that generated - messages, or nothing if the last statement that used a table - generated no messages. This statement is implemented as of MySQL - 4.1.0. A related statement, <literal>SHOW ERRORS</literal>, shows - only the errors. See <xref linkend="show-errors"/>. + <literal>SHOW WARNINGS</literal> shows the error, warning, and + note messages that resulted from the last statement that generated + messages, or nothing if the last statement that used a table + generated no messages. A related statement, + <literal>SHOW ERRORS</literal>, shows only the errors. See + <xref linkend="show-errors"/>. </para> <para> - The list of messages is reset for each new statement that uses a - table. + The list of messages is reset for each new statement that uses a + table. </para> <para> - The <literal>SHOW COUNT(*) WARNINGS</literal> statement displays - the total number of errors, warnings, and notes. You can also - retrieve this number from the <literal>warning_count</literal> - variable: + The <literal>SHOW COUNT(*) WARNINGS</literal> statement displays + the total number of errors, warnings, and notes. You can also + retrieve this number from the <literal>warning_count</literal> + variable: </para> <programlisting> @@ -14129,40 +14210,38 @@ </programlisting> <para> - The value of <literal>warning_count</literal> might be greater than - the number of messages displayed by <literal>SHOW - WARNINGS</literal> if the <literal>max_error_count</literal> system - variable is set low enough that not all messages are stored. An - example shown later in this section demonstrates how this can - happen. + The value of <literal>warning_count</literal> might be greater + than the number of messages displayed by <literal>SHOW + WARNINGS</literal> if the <literal>max_error_count</literal> + system variable is set so low that not all messages are stored. + An example shown later in this section demonstrates how this can + happen. </para> <para> - The <literal>LIMIT</literal> clause has the same syntax as for the - <literal>SELECT</literal> statement. See <xref linkend="select"/>. + The <literal>LIMIT</literal> clause has the same syntax as for the + <literal>SELECT</literal> statement. See <xref linkend="select"/>. </para> <para> - The MySQL server sends back the total number of errors, warnings, - and notes resulting from the last statement. If you are using the C - API, this value can be obtained by calling - <literal>mysql_warning_count()</literal>. See - <xref linkend="mysql-warning-count"/>. + The MySQL server sends back the total number of errors, warnings, + and notes resulting from the last statement. If you are using the + C API, this value can be obtained by calling + <literal>mysql_warning_count()</literal>. See + <xref linkend="mysql-warning-count"/>. </para> <para> - Note that the framework for warnings was added in MySQL 4.1.0, at - which point many statements did not generate warnings. In 4.1.1, - the situation is much improved, with warnings generated for - statements such as <literal>LOAD DATA INFILE</literal> and DML - statements such as <literal>INSERT</literal>, - <literal>UPDATE</literal>, <literal>CREATE TABLE</literal>, and - <literal>ALTER TABLE</literal>. + Warnings are generated for statements such as <literal>LOAD DATA + INFILE</literal> and DML statements such as + <literal>INSERT</literal>, <literal>UPDATE</literal>, + <literal>CREATE TABLE</literal>, and <literal>ALTER + TABLE</literal>. </para> <para> - The following <literal>DROP TABLE</literal> statement results in a - note: + The following <literal>DROP TABLE</literal> statement results in a + note: </para> <programlisting> @@ -14176,9 +14255,9 @@ </programlisting> <para> - Here is a simple example that shows a syntax warning for - <literal>CREATE TABLE</literal> and conversion warnings for - <literal>INSERT</literal>: + Here is a simple example that shows a syntax warning for + <literal>CREATE TABLE</literal> and conversion warnings for + <literal>INSERT</literal>: </para> <programlisting> @@ -14218,15 +14297,14 @@ </programlisting> <para> - The maximum number of error, warning, and note messages to store is - controlled by the <literal>max_error_count</literal> system - variable. By default, its value is 64. To change the number of - messages you want stored, change the value of - <literal>max_error_count</literal>. In the following example, the - <literal>ALTER TABLE</literal> statement produces three warning - messages, but only one is stored because - <literal>max_error_count</literal> has been set to - <literal>1</literal>: + The maximum number of error, warning, and note messages to store + is controlled by the <literal>max_error_count</literal> system + variable. By default, its value is 64. To change the number of + messages you want stored, change the value of + <literal>max_error_count</literal>. In the following example, the + <literal>ALTER TABLE</literal> statement produces three warning + messages, but only one is stored because + <literal>max_error_count</literal> has been set to 1: </para> <programlisting> @@ -14263,16 +14341,15 @@ </programlisting> <para> - To disable warnings, set <literal>max_error_count</literal> to - <literal>0</literal>. In this case, - <literal>warning_count</literal> still indicates how many warnings - have occurred, but none of the messages are stored. + To disable warnings, set <literal>max_error_count</literal> to + 0. In this case, <literal>warning_count</literal> still indicates + how many warnings occur, but none of the messages are stored. </para> <para> - As of MySQL 4.1.11/5.0.3, you can set the - <literal>SQL_NOTES</literal> session variable to 0 to cause - <literal>Note</literal>-level warnings not to be recorded. + As of MySQL 5.0.3, you can set the <literal>SQL_NOTES</literal> + session variable to 0 to cause <literal>Note</literal>-level + warnings not to be recorded. </para> </section> @@ -14315,16 +14392,16 @@ <!-- description_for_help_topic CACHE INDEX --> <para> - The <literal>CACHE INDEX</literal> statement assigns table indexes - to a specific key cache. It is used only for - <literal>MyISAM</literal> tables. + The <literal>CACHE INDEX</literal> statement assigns table indexes + to a specific key cache. It is used only for + <literal>MyISAM</literal> tables. </para> <para> - The following statement assigns indexes from the tables - <literal>t1</literal>, <literal>t2</literal>, and - <literal>t3</literal> to the key cache named - <literal>hot_cache</literal>: + The following statement assigns indexes from the tables + <literal>t1</literal>, <literal>t2</literal>, and + <literal>t3</literal> to the key cache named + <literal>hot_cache</literal>: </para> <programlisting> @@ -14341,17 +14418,18 @@ <!-- end_description_for_help_topic --> <para> - The syntax of <literal>CACHE INDEX</literal> allows you to specify - that only particular indexes from a table should be assigned to the - cache. However, the current implementation assigns all the table's - indexes to the cache, so there is no reason to specify anything - other than the table name. + The syntax of <literal>CACHE INDEX</literal> allows you to specify + that only particular indexes from a table should be assigned to + the cache. However, the current implementation assigns all the + table's indexes to the cache, so there is no reason to specify + anything other than the table name. </para> <para> - The key cache referred to in a <literal>CACHE INDEX</literal> - statement can be created by setting its size with a parameter - setting statement or in the server parameter settings. For example: + The key cache referred to in a <literal>CACHE INDEX</literal> + statement can be created by setting its size with a parameter + setting statement or in the server parameter settings. For + example: </para> <programlisting> @@ -14359,12 +14437,13 @@ </programlisting> <para> - Key cache parameters can be accessed as members of a structured - system variable. See <xref linkend="structured-system-variables"/>. + Key cache parameters can be accessed as members of a structured + system variable. See + <xref linkend="structured-system-variables"/>. </para> <para> - A key cache must exist before you can assign indexes to it: + A key cache must exist before you can assign indexes to it: </para> <programlisting> @@ -14373,20 +14452,17 @@ </programlisting> <para> - By default, table indexes are assigned to the main (default) key - cache created at the server startup. When a key cache is destroyed, - all indexes assigned to it become assigned to the default key cache - again. + By default, table indexes are assigned to the main (default) key + cache created at the server startup. When a key cache is + destroyed, all indexes assigned to it become assigned to the + default key cache again. </para> <para> - Index assignment affects the server globally: If one client assigns - an index to a given cache, this cache is used for all queries - involving the index, no matter what client issues the queries. - </para> - - <para> - <literal>CACHE INDEX</literal> was added in MySQL 4.1.1. + Index assignment affects the server globally: If one client + assigns an index to a given cache, this cache is used for all + queries involving the index, no matter what client issues the + queries. </para> </section> @@ -14422,160 +14498,178 @@ <!-- description_for_help_topic FLUSH LOCAL NO_WRITE_TO_BINLOG DES_KEY_FILE USER_RESOURCES --> <para> - You should use the <literal>FLUSH</literal> statement if you want - to clear some of the internal caches MySQL uses. To execute - <literal>FLUSH</literal>, you must have the - <literal>RELOAD</literal> privilege. + You should use the <literal>FLUSH</literal> statement if you want + to clear some of the internal caches MySQL uses. To execute + <literal>FLUSH</literal>, you must have the + <literal>RELOAD</literal> privilege. <!-- end_description_for_help_topic --> </para> <para> - <replaceable>flush_option</replaceable> can be any of the - following: + <replaceable>flush_option</replaceable> can be any of the + following: </para> <itemizedlist> + + <listitem> + <para> + <literal>HOSTS</literal> + </para> + + <para> + Empties the host cache tables. You should flush the host + tables if some of your hosts change IP number or if you get + the error message <literal>Host ... is blocked</literal>. When + more than <literal>max_connect_errors</literal> errors occur + successively for a given host while connecting to the MySQL + server, MySQL assumes that something is wrong and blocks the + host from further connection requests. Flushing the host + tables allows the host to attempt to connect again. See + <xref linkend="blocked-host"/>. You can start + <command>mysqld</command> with + <literal>--max_connect_errors=999999999</literal> to avoid + this error message. + </para> + </listitem> + + <listitem> + <para> + <literal>DES_KEY_FILE</literal> + </para> + + <para> + Reloads the DES keys from the file that was specified with the + <literal>--des-key-file</literal> option at server startup + time. + </para> + </listitem> + + <listitem> + <para> + <literal>LOGS</literal> + </para> + + <para> + Closes and reopens all log files. If you have specified an + update log file or a binary log file without an extension, the + extension number of the log file is incremented by one + relative to the previous file. If you have used an extension + in the file name, MySQL closes and reopens the log file. On + Unix, this is the same thing as sending a + <literal>SIGHUP</literal> signal to the + <command>mysqld</command> server (except on some Mac OS X 10.3 + versions where <command>mysqld</command> ignores + <literal>SIGHUP</literal> and <literal>SIGQUIT</literal>). + </para> + </listitem> + + <listitem> + <para> + <literal>PRIVILEGES</literal> + </para> + + <para> + Reloads the privileges from the grant tables in the + <literal>mysql</literal> database. + </para> + </listitem> + + <listitem> + <para> + <literal>QUERY CACHE</literal> + </para> + + <para> + Defragment the query cache to better utilize its memory. This + statement does not remove any queries from the cache, unlike + <literal>RESET QUERY CACHE</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>STATUS</literal> + </para> + + <para> + Resets most status variables to zero. This is something you + should use only when debugging a query. See + <xref linkend="bug-reports"/>. + </para> + </listitem> - <listitem><para> - <literal>HOSTS</literal> - </para> - - <para> - Empties the host cache tables. You should flush the host tables if - some of your hosts change IP number or if you get the error - message <literal>Host ... is blocked</literal>. When more than - <literal>max_connect_errors</literal> errors occur successively - for a given host while connecting to the MySQL server, MySQL - assumes that something is wrong and blocks the host from further - connection requests. Flushing the host tables allows the host to - attempt to connect again. See <xref linkend="blocked-host"/>. You - can start <command>mysqld</command> with - <literal>--max_connect_errors=999999999</literal> to avoid this - error message. - </para></listitem> - - <listitem><para> - <literal>DES_KEY_FILE</literal> - </para> - - <para> - Reloads the DES keys from the file that was specified with the - <literal>--des-key-file</literal> option at server startup time. - </para></listitem> - - <listitem><para> - <literal>LOGS</literal> - </para> - - <para> - Closes and reopens all log files. If you have specified an update - log file or a binary log file without an extension, the extension - number of the log file is incremented by one relative to the - previous file. If you have used an extension in the file name, - MySQL closes and reopens the log file. On Unix, this is the same - thing as sending a <literal>SIGHUP</literal> signal to the - <command>mysqld</command> server (except on some Mac OS X 10.3 - versions where <command>mysqld</command> ignores - <literal>SIGHUP</literal> and <literal>SIGQUIT</literal>). - </para></listitem> - - <listitem><para> - <literal>PRIVILEGES</literal> - </para> - - <para> - Reloads the privileges from the grant tables in the - <literal>mysql</literal> database. - </para></listitem> - - <listitem><para> - <literal>QUERY CACHE</literal> - </para> - - <para> - Defragment the query cache to better utilize its memory. This - statement does not remove any queries from the cache, unlike - <literal>RESET QUERY CACHE</literal>. - </para></listitem> - - <listitem><para> - <literal>STATUS</literal> - </para> - - <para> - Resets most status variables to zero. This is something you should - use only when debugging a query. See - <xref linkend="bug-reports"/>. - </para> - - <para> <!-- TODO: non-TEMPORARY tables only? --> - </para></listitem> - - <listitem><para> - <literal>{TABLE | TABLES} [<replaceable>tbl_name</replaceable> [, - <replaceable>tbl_name</replaceable>] ...]</literal> - </para> - - <para> - When no tables are named, closes all open tables and forces all - tables in use to be closed. This also flushes the query cache. - With one or more table names, flushes only the given tables. - <literal>FLUSH TABLES</literal> also removes all query results - from the query cache, like the <literal>RESET QUERY - CACHE</literal> statement. - </para></listitem> - - <listitem><para> - <literal>TABLES WITH READ LOCK</literal> - </para> - - <para> - Closes all open tables and locks all tables for all databases with - a read lock until you execute <literal>UNLOCK TABLES</literal>. - This is very convenient way to get backups if you have a - filesystem such as Veritas that can take snapshots in time. - </para></listitem> - - <listitem><para> - <literal>USER_RESOURCES</literal> - </para> - - <para> - Resets all per-hour user resources to zero. This enables clients - that have reached their hourly connection, query, or update limits - to resume activity. <literal>FLUSH USER_RESOURCES</literal> does - not apply to the limit on maximum simultaneous connections. See - <xref linkend="grant"/>. - </para></listitem> - - </itemizedlist> - - <para> - Before MySQL 4.1.1, <literal>FLUSH</literal> statements are not - written to the binary log. As of MySQL 4.1.1, they are written to + <listitem> + <para> + <literal>{TABLE | TABLES} [<replaceable>tbl_name</replaceable> + [, <replaceable>tbl_name</replaceable>] ...]</literal> + </para> + + <para> + When no tables are named, closes all open tables and forces all + tables in use to be closed. This also flushes the query cache. + With one or more table names, flushes only the given tables. + <literal>FLUSH TABLES</literal> also removes all query results + from the query cache, like the <literal>RESET QUERY + CACHE</literal> statement. + </para> + </listitem> + + <listitem> + <para> + <literal>TABLES WITH READ LOCK</literal> + </para> + + <para> + Closes all open tables and locks all tables for all databases + with a read lock until you execute <literal>UNLOCK + TABLES</literal>. This is very convenient way to get backups if + you have a filesystem such as Veritas that can take snapshots + in time. + </para> + </listitem> + + <listitem> + <para> + <literal>USER_RESOURCES</literal> + </para> + + <para> + Resets all per-hour user resources to zero. This enables + clients that have reached their hourly connection, query, or + update limits to resume activity immediately. <literal>FLUSH + USER_RESOURCES</literal> does not apply to the limit on maximum + simultaneous connections. See <xref linkend="grant"/>. + </para> + </listitem> + </itemizedlist> + + <para> + In MySQL 5.0, <literal>FLUSH</literal> statements are written to the binary log unless the optional <literal>NO_WRITE_TO_BINLOG</literal> keyword (or its alias - <literal>LOCAL</literal>) is used. Exceptions are that - <literal>FLUSH LOGS</literal>, <literal>FLUSH MASTER</literal>, - <literal>FLUSH SLAVE</literal>, and <literal>FLUSH TABLES WITH READ - LOCK</literal> are not logged in any case because they would cause - problems if replicated to a slave. + <literal>LOCAL</literal>) is used. + <emphasis role="bold">Note</emphasis>: <literal>FLUSH + LOGS</literal>, <literal>FLUSH MASTER</literal>, <literal>FLUSH + SLAVE</literal>, and <literal>FLUSH TABLES WITH READ LOCK</literal> + are not logged in any case because they would cause problems if + replicated to a slave. </para> <para> - You can also access some of these statements with the - <command>mysqladmin</command> utility, using the - <literal>flush-hosts</literal>, <literal>flush-logs</literal>, - <literal>flush-privileges</literal>, - <literal>flush-status</literal>, or <literal>flush-tables</literal> - commands. + You can also access some of these statements with the + <command>mysqladmin</command> utility, using the + <literal>flush-hosts</literal>, <literal>flush-logs</literal>, + <literal>flush-privileges</literal>, + <literal>flush-status</literal>, or + <literal>flush-tables</literal> commands. </para> <para> - Take also a look at the <literal>RESET</literal> statement used - with replication. See <xref linkend="reset"/>. + See also <xref linkend="reset"/> for information about how the + <literal>RESET</literal> statement is used with replication. </para> </section> @@ -14601,123 +14695,141 @@ <!-- description_for_help_topic KILL --> <para> - Each connection to <command>mysqld</command> runs in a separate - thread. You can see which threads are running with the - <literal>SHOW PROCESSLIST</literal> statement and kill a thread - with the <literal>KILL thread_id</literal> statement. + Each connection to <command>mysqld</command> runs in a separate + thread. You can see which threads are running with the + <literal>SHOW PROCESSLIST</literal> statement and kill a thread + with the + <literal>KILL <replaceable>thread_id</replaceable></literal> + statement. </para> <para> - As of MySQL 5.0.0, <literal>KILL</literal> allows the optional - <literal>CONNECTION</literal> or <literal>QUERY</literal> - modifiers: + In MySQL 5.0.0, <literal>KILL</literal> allows the optional + <literal>CONNECTION</literal> or <literal>QUERY</literal> + modifiers: </para> <itemizedlist> - - <listitem><para> - <literal>KILL CONNECTION</literal> is the same as - <literal>KILL</literal> with no modifier: It terminates the - connection associated with the given - <replaceable>thread_id</replaceable>. - </para></listitem> - - <listitem><para> - <literal>KILL QUERY</literal> terminates the statement that the - connection currently is executing, but leaves the connection - intact. - </para></listitem> - + + <listitem> + <para> + <literal>KILL CONNECTION</literal> is the same as + <literal>KILL</literal> with no modifier: It terminates the + connection associated with the given + <replaceable>thread_id</replaceable>. + </para> + </listitem> + + <listitem> + <para> + <literal>KILL QUERY</literal> terminates the statement that + the connection is currently executing, but leaves the + connection itself intact. + </para> + </listitem> + </itemizedlist> <para> - If you have the <literal>PROCESS</literal> privilege, you can see - all threads. If you have the <literal>SUPER</literal> privilege, - you can kill all threads and statements. Otherwise, you can see and - kill only your own threads and statements. + If you have the <literal>PROCESS</literal> privilege, you can see + all threads. If you have the <literal>SUPER</literal> privilege, + you can kill all threads and statements. Otherwise, you can see + and kill only your own threads and statements. </para> <para> - You can also use the <command>mysqladmin processlist</command> and - <command>mysqladmin kill</command> commands to examine and kill - threads. + You can also use the <command>mysqladmin processlist</command> and + <command>mysqladmin kill</command> commands to examine and kill + threads. </para> <para> - <emphasis role="bold">Note</emphasis>: You currently cannot use - <literal>KILL</literal> with the Embedded MySQL Server library, - because the embedded server merely runs inside the threads of the - host application, it does not create connection threads of its own. + <emphasis role="bold">Note</emphasis>: You currently cannot use + <literal>KILL</literal> with the Embedded MySQL Server library, + because the embedded server merely runs inside the threads of the + host application. It does not create any connection threads of its + own. <!-- end_description_for_help_topic --> </para> <para> - When you do a <literal>KILL</literal>, a thread-specific kill flag - is set for the thread. In most cases, it might take some time for - the thread to die, because the kill flag is checked only at - specific intervals: + When you do a <literal>KILL</literal>, a thread-specific kill flag + is set for the thread. In most cases, it might take some time for + the thread to die, because the kill flag is checked only at + specific intervals: </para> <itemizedlist> - - <listitem><para> - In <literal>SELECT</literal>, <literal>ORDER BY</literal> and - <literal>GROUP BY</literal> loops, the flag is checked after - reading a block of rows. If the kill flag is set, the statement is - aborted. - </para></listitem> - - <listitem><para> - During <literal>ALTER TABLE</literal>, the kill flag is checked - before each block of rows are read from the original table. If the - kill flag was set, the statement is aborted and the temporary - table is deleted. - </para></listitem> - - <listitem><para> - During <literal>UPDATE</literal> or <literal>DELETE</literal>, the - kill flag is checked after each block read and after each updated - or deleted row. If the kill flag is set, the statement is aborted. - Note that if you are not using transactions, the changes are not - rolled back. - </para></listitem> - - <listitem><para> - <literal>GET_LOCK()</literal> aborts and returns - <literal>NULL</literal>. - </para></listitem> - - <listitem><para> - An <literal>INSERT DELAYED</literal> thread quickly flushes - (inserts) all rows it has in memory and terminates. - </para></listitem> - - <listitem><para> - If the thread is in the table lock handler (state: - <literal>Locked</literal>), the table lock is quickly aborted. - </para></listitem> - - <listitem><para> - If the thread is waiting for free disk space in a write call, the - write is aborted with a "disk full" error message. - </para></listitem> - - <listitem><para> - Some threads might refuse to be killed. For example, - <literal>REPAIR TABLE</literal>, <literal>CHECK TABLE</literal>, - and <literal>OPTIMIZE TABLE</literal> cannot be killed before - MySQL 4.1 and run to completion. This is changed: <literal>REPAIR - TABLE</literal> and <literal>OPTIMIZE TABLE</literal> can be - killed as of MySQL 4.1.0, as can <literal>CHECK TABLE</literal> as - of MySQL 4.1.3. However, killing a <literal>REPAIR TABLE</literal> - or <literal>OPTIMIZE TABLE</literal> operation on a - <literal>MyISAM</literal> table results in a table that - <emphasis>is</emphasis> corrupted and is unusable (reads and - writes to it fail) until you optimize or repair it again. - </para></listitem> - - </itemizedlist> + + <listitem> + <para> + In <literal>SELECT</literal>, <literal>ORDER BY</literal> and + <literal>GROUP BY</literal> loops, the flag is checked after + reading a block of rows. If the kill flag is set, the + statement is aborted. + </para> + </listitem> + + <listitem> + <para> + During <literal>ALTER TABLE</literal>, the kill flag is checked + before each block of rows are read from the original table. If + the kill flag was set, the statement is aborted and the + temporary table is deleted. + </para> + </listitem> + + <listitem> + <para> + During <literal>UPDATE</literal> or <literal>DELETE</literal> + operations, the kill flag is checked after each block read and + after each updated or deleted row. If the kill flag is set, the + statement is aborted. Note that if you are not using + transactions, the changes are not rolled back. + </para> + </listitem> + + <listitem> + <para> + <literal>GET_LOCK()</literal> aborts and returns + <literal>NULL</literal>. + </para> + </listitem> + + <listitem> + <para> + An <literal>INSERT DELAYED</literal> thread quickly flushes + (inserts) all rows it has in memory and then terminates. + </para> + </listitem> + + <listitem> + <para> + If the thread is in the table lock handler (state: + <literal>Locked</literal>), the table lock is quickly aborted. + </para> + </listitem> + + <listitem> + <para> + If the thread is waiting for free disk space in a write call, + the write is aborted with a "disk full" error message. + </para> + </listitem> + + <listitem> + <para> + <emphasis role="bold">Warning</emphasis>: Killing a + <literal>REPAIR TABLE</literal> or <literal>OPTIMIZE + TABLE</literal> operation on a <literal>MyISAM</literal> table + results in a table that is corrupted and unusable. Any reads or + writes to such a table fail until you optimize or repair it + again (without interruption). + </para> + </listitem> + + </itemizedlist> </section> @@ -14740,23 +14852,23 @@ <!-- description_for_help_topic LOAD INDEX --> <para> - The <literal>LOAD INDEX INTO CACHE</literal> statement preloads a - table index into the key cache to which it has been assigned by an - explicit <literal>CACHE INDEX</literal> statement, or into the - default key cache otherwise. <literal>LOAD INDEX INTO - CACHE</literal> is used only for <literal>MyISAM</literal> tables. + The <literal>LOAD INDEX INTO CACHE</literal> statement in MySQL + 5.0 preloads a table index into the key cache to which it has been + assigned by an explicit <literal>CACHE INDEX</literal> statement, + or into the default key cache otherwise. <literal>LOAD INDEX INTO + CACHE</literal> is used only for <literal>MyISAM</literal> tables. </para> <para> - The <literal>IGNORE LEAVES</literal> modifier causes only blocks - for the non-leaf nodes of the index to be preloaded. + The <literal>IGNORE LEAVES</literal> modifier causes only blocks + for the non-leaf nodes of the index to be preloaded. <!-- end_description_for_help_topic --> </para> <para> - The following statement preloads nodes (index blocks) of indexes of - the tables <literal>t1</literal> and <literal>t2</literal>: + The following statement preloads nodes (index blocks) of indexes + for the tables <literal>t1</literal> and <literal>t2</literal>: </para> <programlisting> @@ -14770,21 +14882,17 @@ </programlisting> <para> - This statement preloads all index blocks from - <literal>t1</literal>. It preloads only blocks for the non-leaf - nodes from <literal>t2</literal>. - </para> - - <para> - The syntax of <literal>LOAD INDEX INTO CACHE</literal> allows you - to specify that only particular indexes from a table should be - preloaded. However, the current implementation preloads all the - table's indexes into the cache, so there is no reason to specify - anything other than the table name. + This statement preloads all index blocks from + <literal>t1</literal>. It preloads only blocks for the non-leaf + nodes from <literal>t2</literal>. </para> <para> - <literal>LOAD INDEX INTO CACHE</literal> was added in MySQL 4.1.1. + The syntax of <literal>LOAD INDEX INTO CACHE</literal> allows you + to specify that only particular indexes from a table should be + preloaded. However, the current implementation preloads all the + table's indexes into the cache, so there is no reason to specify + anything other than the table name. </para> </section> @@ -14802,57 +14910,64 @@ <!-- description_for_help_topic RESET --> <para> - The <literal>RESET</literal> statement is used to clear the state - of various server operations. It also acts as a stronger version of - the <literal>FLUSH</literal> statement. See - <xref linkend="flush"/>. + The <literal>RESET</literal> statement is used to clear the state + of various server operations. It also acts as a stronger version + of the <literal>FLUSH</literal> statement. See + <xref linkend="flush"/>. <!-- end_description_for_help_topic --> </para> <para> - To execute <literal>RESET</literal>, you must have the - <literal>RELOAD</literal> privilege. + You must have the <literal>RELOAD</literal> privilege in order to + execute <literal>RESET</literal>, </para> <para> - <replaceable>reset_option</replaceable> can be any of the - following: + <replaceable>reset_option</replaceable> can be any of the + following: </para> <itemizedlist> - - <listitem><para> - <literal>MASTER</literal> - </para> - - <para> - Deletes all binary logs listed in the index file, resets the - binary log index file to be empty, and creates a new binary log - file. Previously named <literal>FLUSH MASTER</literal>. See - <xref linkend="replication-master-sql"/>. - </para></listitem> - - <listitem><para> - <literal>QUERY CACHE</literal> - </para> - - <para> - Removes all query results from the query cache. - </para></listitem> - - <listitem><para> - <literal>SLAVE</literal> - </para> - - <para> - Makes the slave forget its replication position in the master - binary logs. Also resets the relay log by deleting any existing - relay log files and beginning a new one. Previously named - <literal>FLUSH SLAVE</literal>. See - <xref linkend="replication-slave-sql"/>. - </para></listitem> - + + <listitem> + <para> + <literal>MASTER</literal> + </para> + + <para> + Deletes all binary logs listed in the index file, resets the + binary log index file to be empty, and creates a new binary + log file. (Known as <literal>FLUSH MASTER</literal> in + previous versions of MySQL.) See + <xref linkend="replication-master-sql"/>. + </para> + </listitem> + + <listitem> + <para> + <literal>QUERY CACHE</literal> + </para> + + <para> + Removes all query results from the query cache. + </para> + </listitem> + + <listitem> + <para> + <literal>SLAVE</literal> + </para> + + <para> + Makes the slave forget its replication position in the master + binary logs. Also resets the relay log by deleting any + existing relay log files and beginning a new one. (Known as + <literal>FLUSH SLAVE</literal> in previous versions of MySQL.) + See <xref linkend="replication-slave-sql"/>. + </para> + </listitem> + </itemizedlist> </section> @@ -14866,9 +14981,9 @@ <title id='title-replication-sql'>&title-replication-sql;</title> <para> - This section describes replication-related SQL statements. One group - of statements is used for controlling master servers. The other is - used for controlling slave servers. + This section describes SQL statements related to replication. One + group of statements is used for controlling master servers. The + other is used for controlling slave servers. </para> <section id="replication-master-sql"> @@ -14891,10 +15006,10 @@ </indexterm> <para> - Replication can be controlled through the SQL interface. This - section discusses statements for managing master replication - servers. <xref linkend="replication-slave-sql"/> discusses - statements for managing slave servers. + Replication can be controlled through the SQL interface. This + section discusses statements for managing master replication + servers. <xref linkend="replication-slave-sql"/> discusses + statements for managing slave servers. </para> <section id="purge-master-logs"> @@ -14913,16 +15028,16 @@ </programlisting> <para> - Deletes all the binary logs listed in the log index that are - strictly prior to the specified log or date. The logs also are - removed from the list recorded in the log index file, so that the - given log becomes the first. + Deletes all the binary logs listed in the log index prior to the + specified log or date. The logs also are removed from the list + recorded in the log index file, so that the given log becomes the + first. <!-- end_description_for_help_topic --> </para> <para> - Example: + Example: </para> <!-- example_for_help_topic PURGE --> @@ -14933,54 +15048,64 @@ </programlisting> <para> - The <literal>BEFORE</literal> variant is available as of MySQL 4.1. - Its date argument can be in <literal>'YYYY-MM-DD - hh:mm:ss'</literal> format. <literal>MASTER</literal> and - <literal>BINARY</literal> are synonyms, but - <literal>BINARY</literal> can be used only as of MySQL 4.1.1. + The <literal>BEFORE</literal> variant's + <replaceable>date</replaceable> argument can be in + <literal>'YYYY-MM-DD hh:mm:ss'</literal> format. + <literal>MASTER</literal> and <literal>BINARY</literal> are + synonyms in MySQL 5.0. </para> <para> - If you have an active slave that currently is reading one of the - logs you are trying to delete, this statement does nothing and - fails with an error. However, if a slave is dormant and you happen - to purge one of the logs it wants to read, the slave is unable to - replicate once it comes up. The statement is safe to run while - slaves are replicating. You do not need to stop them. + If you have an active slave that currently is reading one of the + logs you are trying to delete, this statement does nothing and + fails with an error. However, if a slave is dormant and you happen + to purge one of the logs it wants to read, the slave is unable to + replicate once it comes up. The statement is safe to run while + slaves are replicating. You do not need to stop them. </para> <para> - To purge logs, follow this procedure: + To purge logs, follow this procedure: </para> <orderedlist> - - <listitem><para> - On each slave server, use <literal>SHOW SLAVE STATUS</literal> to - check which log it is reading. - </para></listitem> - - <listitem><para> - Obtain a listing of the logs on the master server with - <literal>SHOW MASTER LOGS</literal>. - </para></listitem> - - <listitem><para> - Determine the earliest log among all the slaves. This is the - target log. If all the slaves are up to date, this is the last log - on the list. - </para></listitem> - - <listitem><para> - Make a backup of all the logs you are about to delete. (The step - is optional, but a good idea.) - </para></listitem> - - <listitem><para> - Purge all logs up to but not including the target log. - </para></listitem> - - </orderedlist> + + <listitem> + <para> + On each slave server, use <literal>SHOW SLAVE STATUS</literal> + to check which log it is reading. + </para> + </listitem> + + <listitem> + <para> + Obtain a listing of the logs on the master server with + <literal>SHOW MASTER LOGS</literal>. + </para> + </listitem> + + <listitem> + <para> + Determine the earliest log among all the slaves. This is the + target log. If all the slaves are up to date, this is the last + log on the list. + </para> + </listitem> + + <listitem> + <para> + Make a backup of all the logs you are about to delete. (This + step is optional, but always advisable.) + </para> + </listitem> + + <listitem> + <para> + Purge all logs up to but not including the target log. + </para> + </listitem> + + </orderedlist> </section> @@ -14999,14 +15124,10 @@ </programlisting> <para> - Deletes all binary logs listed in the index file, resets the binary - log index file to be empty, and creates a new binary log file. - </para> - - <para> - This statement was named <literal>FLUSH MASTER</literal> before - MySQL 3.23.26. - + Deletes all binary logs listed in the index file, resets the + binary log index file to be empty, and creates a new binary log + file. + <!-- end_description_for_help_topic --> </para> @@ -15027,13 +15148,12 @@ </programlisting> <para> - Disables or enables binary logging for the current connection - (<literal>SQL_LOG_BIN</literal> is a session variable) if the - client connects using an account that has the - <literal>SUPER</literal> privilege. The statement is refused with - an error if the client does not have that privilege. (Before MySQL - 4.1.2, the statement was simply ignored in that case.) - + Disables or enables binary logging for the current connection + (<literal>SQL_LOG_BIN</literal> is a session variable) if the + client connects using an account that has the + <literal>SUPER</literal> privilege. In MySQL 5.0, statement is + refused with an error if the client does not have that privilege. + <!-- end_description_for_help_topic --> </para> @@ -15055,19 +15175,26 @@ </programlisting> <para> - Shows the events in the binary log. If you do not specify - <literal>'log_name'</literal>, the first binary log is displayed. + Shows the events in the binary log. If you do not specify + <literal>'log_name'</literal>, the first binary log is displayed. <!-- end_description_for_help_topic --> </para> <para> - The <literal>LIMIT</literal> clause has the same syntax as for the - <literal>SELECT</literal> statement. See <xref linkend="select"/>. + The <literal>LIMIT</literal> clause has the same syntax as for the + <literal>SELECT</literal> statement. See <xref linkend="select"/>. </para> - + <para> - This statement is available as of MySQL 4.0. + <emphasis role="bold">Note</emphasis>: Issuing a <literal>SHOW + BINLOG EVENTS</literal> with no <literal>LIMIT</literal> clause + could start a very time- and resource-consuming process as the + server dumps the complete contents of the binary log (which + includes most of the queries executed by MySQL) to stdout. To + save the binary log to a text file for later examination and + analysis, use the <command>mysqlbinlog</command> utility. See + <xref linkend="mysqlbinlog"/>. </para> </section> @@ -15094,10 +15221,10 @@ </programlisting> <para> - Lists the binary log files on the server. This statement is used as - part of the procedure described in - <xref linkend="purge-master-logs"/> for determining which logs can - be purged. + Lists the binary log files on the server. This statement is used + as part of the procedure described in + <xref linkend="purge-master-logs"/> for determining which logs can + be purged. </para> <programlisting> @@ -15113,11 +15240,10 @@ <!-- end_description_for_help_topic --> <para> - <literal>SHOW MASTER LOGS</literal> was added in MySQL 3.23.38. As - of MySQL 4.1.1, you can also use <literal>SHOW BINARY - LOGS</literal>, which is equivalent. The - <literal>File_size</literal> column is displayed as of MySQL 4.1.13 - and 5.0.7. + In MySQL 5.0, <literal>SHOW BINARY LOGS</literal>, is equivalent + to <literal>SHOW MASTER LOGS</literal>. The + <literal>File_size</literal> column is displayed as of MySQL + 5.0.7. </para> </section> @@ -15139,7 +15265,8 @@ </programlisting> <para> - Provides status information on the binary log files of the master. + Provides status information on the binary log files of the + replication master. <!-- end_description_for_help_topic --> </para> @@ -15163,10 +15290,10 @@ </programlisting> <para> - Displays a list of slaves currently registered with the master. Any - slave not started with the - <literal>--report-host=<replaceable>slave_name</replaceable></literal> - option is not visible in that list. + Displays a list of replication slaves currently registered with + the master. Any slave not started with the + <literal>--report-host=<replaceable>slave_name</replaceable></literal> + option is not visible in this list. <!-- end_description_for_help_topic --> </para> @@ -15195,10 +15322,10 @@ </indexterm> <para> - Replication can be controlled through the SQL interface. This - section discusses statements for managing slave replication servers. - <xref linkend="replication-master-sql"/> discusses statements for - managing master servers. + Replication can be controlled through the SQL interface. This + section discusses statements for managing slave replication + servers. <xref linkend="replication-master-sql"/> discusses + statements for managing master servers. </para> <section id="change-master-to"> @@ -15212,7 +15339,7 @@ <!-- description_for_help_topic CHANGE MASTER TO CHANGE MASTER TO MASTER_HOST MASTER_USER MASTER_PASSWORD MASTER_PORT MASTER_LOG_FILE MASTER_LOG_POS MASTER_CONNECT_RETRY RELAY_LOG_POS RELAY_LOG_FILE MASTER_SSL MASTER_SSL_CA MASTER_SSL_CERT MASTER_SSL_KEY MASTER_SSL_CIPHER --> <programlisting> -CHANGE MASTER TO master_def [, master_def] ... + CHANGE MASTER TO <replaceable>master_def</replaceable> [, <replaceable>master_def</replaceable>] ... master_def: MASTER_HOST = '<replaceable>host_name</replaceable>' @@ -15233,45 +15360,40 @@ </programlisting> <para> - Changes the parameters that the slave server uses for connecting to - and communicating with the master server. - </para> - - <para> - <literal>MASTER_USER</literal>, <literal>MASTER_PASSWORD</literal>, - <literal>MASTER_SSL</literal>, <literal>MASTER_SSL_CA</literal>, - <literal>MASTER_SSL_CAPATH</literal>, - <literal>MASTER_SSL_CERT</literal>, - <literal>MASTER_SSL_KEY</literal>, and - <literal>MASTER_SSL_CIPHER</literal> provide information for the - slave about how to connect to its master. + Changes the parameters that the slave server uses for connecting + to and communicating with the master server. </para> <para> - The relay log options (<literal>RELAY_LOG_FILE</literal> and - <literal>RELAY_LOG_POS</literal>) are available beginning with - MySQL 4.0. + <literal>MASTER_USER</literal>, + <literal>MASTER_PASSWORD</literal>, <literal>MASTER_SSL</literal>, + <literal>MASTER_SSL_CA</literal>, + <literal>MASTER_SSL_CAPATH</literal>, + <literal>MASTER_SSL_CERT</literal>, + <literal>MASTER_SSL_KEY</literal>, and + <literal>MASTER_SSL_CIPHER</literal> provide information to the + slave about how to connect to its master. </para> <para> - The SSL options (<literal>MASTER_SSL</literal>, - <literal>MASTER_SSL_CA</literal>, - <literal>MASTER_SSL_CAPATH</literal>, - <literal>MASTER_SSL_CERT</literal>, - <literal>MASTER_SSL_KEY</literal>, and - <literal>MASTER_SSL_CIPHER</literal>) are available beginning with - MySQL 4.1.1. You can change these options even on slaves that are - compiled without SSL support. They are saved to the - <filename>master.info</filename> file, but are ignored until you - use a server that has SSL support enabled. + The SSL options (<literal>MASTER_SSL</literal>, + <literal>MASTER_SSL_CA</literal>, + <literal>MASTER_SSL_CAPATH</literal>, + <literal>MASTER_SSL_CERT</literal>, + <literal>MASTER_SSL_KEY</literal>, and + <literal>MASTER_SSL_CIPHER</literal>) can be changed + even on slaves that are + compiled without SSL support. They are saved to the + <filename>master.info</filename> file, but are ignored until you + use a server that has SSL support enabled. </para> <para> - If you don't specify a given parameter, it keeps its old value, - except as indicated in the following discussion. For example, if - the password to connect to your MySQL master has changed, you just - need to issue these statements to tell the slave about the new - password: + If you don't specify a given parameter, it keeps its old value, + except as indicated in the following discussion. For example, if + the password to connect to your MySQL master has changed, you just + need to issue these statements to tell the slave about the new + password: </para> <programlisting> @@ -15281,80 +15403,76 @@ </programlisting> <para> - There is no need to specify the parameters that do not change - (host, port, user, and so forth). + There is no need to specify the parameters that do not change + (host, port, user, and so forth). </para> <para> - <literal>MASTER_HOST</literal> and <literal>MASTER_PORT</literal> - are the hostname (or IP address) of the master host and its TCP/IP - port. Note that if <literal>MASTER_HOST</literal> is equal to - <literal>localhost</literal>, then, like in other parts of MySQL, - the port may be ignored (if Unix socket files can be used, for - example). + <literal>MASTER_HOST</literal> and <literal>MASTER_PORT</literal> + are the hostname (or IP address) of the master host and its TCP/IP + port. Note that if <literal>MASTER_HOST</literal> is equal to + <literal>localhost</literal>, then, like in other parts of MySQL, + the port may be ignored (if Unix socket files can be used, for + example). </para> <para> - If you specify <literal>MASTER_HOST</literal> or - <literal>MASTER_PORT</literal>, the slave assumes that the master - server is different than before (even if you specify a host or port - value that is the same as the current value.) In this case, the old - values for the master binary log name and position are considered - no longer applicable, so if you do not specify - <literal>MASTER_LOG_FILE</literal> and - <literal>MASTER_LOG_POS</literal> in the statement, - <literal>MASTER_LOG_FILE=''</literal> and - <literal>MASTER_LOG_POS=4</literal> are silently appended to it. + If you specify <literal>MASTER_HOST</literal> or + <literal>MASTER_PORT</literal>, the slave assumes that the master + server is different than before (even if you specify a host or + port value that is the same as the current value.) In this case, + the old values for the master binary log name and position are + considered no longer applicable, so if you do not specify + <literal>MASTER_LOG_FILE</literal> and + <literal>MASTER_LOG_POS</literal> in the statement, + <literal>MASTER_LOG_FILE=''</literal> and + <literal>MASTER_LOG_POS=4</literal> are silently appended to it. </para> <para> - <literal>MASTER_LOG_FILE</literal> and - <literal>MASTER_LOG_POS</literal> are the coordinates at which the - slave I/O thread should begin reading from the master the next time - the thread starts. If you specify either of them, you can't specify - <literal>RELAY_LOG_FILE</literal> or - <literal>RELAY_LOG_POS</literal>. If neither of - <literal>MASTER_LOG_FILE</literal> or - <literal>MASTER_LOG_POS</literal> are specified, the slave uses the - last coordinates of the <emphasis>slave SQL thread</emphasis> - before <literal>CHANGE MASTER</literal> was issued. This ensures - that replication has no discontinuity, even if the slave SQL thread - was late compared to the slave I/O thread, when you just want to - change, say, the password to use. This safe behavior was introduced - starting from MySQL 4.0.17 and 4.1.1. (Before these versions, the - coordinates used were the last coordinates of the slave I/O thread - before <literal>CHANGE MASTER</literal> was issued. This caused the - SQL thread to possibly lose some events from the master, thus - breaking replication.) + <literal>MASTER_LOG_FILE</literal> and + <literal>MASTER_LOG_POS</literal> are the coordinates at which the + slave I/O thread should begin reading from the master the next + time the thread starts. If you specify either of them, you can't + specify <literal>RELAY_LOG_FILE</literal> or + <literal>RELAY_LOG_POS</literal>. If neither of + <literal>MASTER_LOG_FILE</literal> or + <literal>MASTER_LOG_POS</literal> are specified, the slave uses + the last coordinates of the <emphasis>slave SQL thread</emphasis> + before <literal>CHANGE MASTER</literal> was issued. This ensures + that there is no discontinuity in replication, even if the slave + SQL thread was late compared to the slave I/O thread, when you + merely want to change, say, the password to use. </para> <para> - <literal>CHANGE MASTER</literal> <emphasis>deletes all relay log - files</emphasis> and starts a new one, unless you specify - <literal>RELAY_LOG_FILE</literal> or - <literal>RELAY_LOG_POS</literal>. In that case, relay logs are - kept; as of MySQL 4.1.1 the <literal>relay_log_purge</literal> - global variable is set silently to 0. + <literal>CHANGE MASTER</literal> <emphasis>deletes all relay log + files</emphasis> and starts a new one, unless you specify + <literal>RELAY_LOG_FILE</literal> or + <literal>RELAY_LOG_POS</literal>. In that case, relay logs are + kept; in MySQL 5.0, the <literal>relay_log_purge</literal> + global variable is set silently to 0. </para> <para> - <literal>CHANGE MASTER TO</literal> updates the contents of the - <filename>master.info</filename> and - <filename>relay-log.info</filename> files. + <literal>CHANGE MASTER TO</literal> updates the contents of the + <filename>master.info</filename> and + <filename>relay-log.info</filename> files. </para> <para> - <literal>CHANGE MASTER</literal> is useful for setting up a slave - when you have the snapshot of the master and have recorded the log - and the offset corresponding to it. After loading the snapshot into - the slave, you can run <literal>CHANGE MASTER TO - MASTER_LOG_FILE='<replaceable>log_name_on_master</replaceable>', - MASTER_LOG_POS=<replaceable>log_offset_on_master</replaceable></literal> - on the slave. + <literal>CHANGE MASTER</literal> is useful for setting up a slave + when you have the snapshot of the master and have recorded the log + and the offset corresponding to it. After loading the snapshot + into + the slave, you can run <literal>CHANGE MASTER TO + MASTER_LOG_FILE='<replaceable>log_name_on_master</replaceable>', + MASTER_LOG_POS=<replaceable>log_offset_on_master</replaceable></literal> + on the slave. </para> <para> - Examples: + Examples: </para> <programlisting> @@ -15375,39 +15493,37 @@ <!-- end_description_for_help_topic --> <para> - The first example changes the master and master's binary log - coordinates. This is used when you want to set up the slave to - replicate the master. + The first example changes the master and master's binary log + coordinates. This is used when you want to set up the slave to + replicate the master. </para> <para> - The second example shows an operation that is less frequently used. - It is done when the slave has relay logs that you want it to - execute again for some reason. To do this, the master need not be - reachable. You just have to use <literal>CHANGE MASTER TO</literal> - and start the SQL thread (<literal>START SLAVE - SQL_THREAD</literal>). + The second example shows an operation that is less frequently + employed. It is used when the slave has relay logs that you want + it to execute again for some reason. To do this, the master need + not be reachable. You need only use <literal>CHANGE MASTER + TO</literal> and start the SQL thread (<literal>START SLAVE + SQL_THREAD</literal>). </para> <para> - You can even use the second operation in a non-replication setup - with a standalone, non-slave server, to recover after a crash. - Suppose that your server has crashed and you have restored a - backup. You want to replay the server's own binary logs (not relay - logs, but regular binary logs), supposedly named - <filename>myhost-bin.*</filename>. First, make a backup copy of - these binary logs in some safe place, in case you don't exactly - follow the procedure below and accidentally have the server purge - the binary logs. If using MySQL 4.1.1 or newer, use <literal>SET - GLOBAL relay_log_purge=0</literal> for additional safety. Then - start the server without the <literal>--log-bin</literal> option. - Before MySQL 4.0.19, start it with a new (different from before) - server id; in newer versions there is no need, just use the - <literal>--replicate-same-server-id</literal> option. Start it with - <literal>--relay-log=myhost-bin</literal> (to make the server - believe that these regular binary logs are relay logs) and with - <literal>--skip-slave-start</literal>. After the server starts, - issue these statements: + You can even use the second operation in a non-replication setup + with a standalone, non-slave server for recovery following a + crash. Suppose that your server has crashed and you have restored + a backup. You want to replay the server's own binary logs (not + relay logs, but regular binary logs), named (for example) + <filename>myhost-bin.*</filename>. First, make a backup copy of + these binary logs in some safe place, in case you don't exactly + follow the procedure below and accidentally have the server purge + the binary logs. In MySQL 5.0, use <literal>SET GLOBAL + relay_log_purge=0</literal> for additional safety. Then + start the server without the <literal>--log-bin</literal> option, + Instead, use the <literal>--replicate-same-server-id</literal>, + <literal>--relay-log=myhost-bin</literal> (to make the server + believe that these regular binary logs are relay logs), + <literal>--skip-slave-start</literal> options. Once the server + starts, issue these statements: </para> <programlisting> @@ -15419,19 +15535,19 @@ </programlisting> <para> - The server reads and executes its own binary logs, thus achieving - crash recovery. Once the recovery is finished, run <literal>STOP - SLAVE</literal>, shut down the server, delete - <filename>master.info</filename> and - <filename>relay-log.info</filename>, and restart the server with - its original options. + The server reads and executes its own binary logs, thus achieving + crash recovery. Once the recovery is finished, run <literal>STOP + SLAVE</literal>, shut down the server, delete + <filename>master.info</filename> and + <filename>relay-log.info</filename>, and restart the server with + its original options. </para> <para> - For the moment, specifying <literal>MASTER_HOST</literal> (even - with a dummy value) is required to make the server think it is a - slave. In the future, we plan to add options to get rid of these - small constraints. + Currently, specifying <literal>MASTER_HOST</literal> (even with a + dummy value) is required to make the server think it is a slave. + In the future, we plan to add options to get rid of these minor + constraints. </para> </section> @@ -15451,80 +15567,85 @@ </programlisting> <para> - Takes a snapshot of the master and copies it to the slave. It - updates the values of <literal>MASTER_LOG_FILE</literal> and - <literal>MASTER_LOG_POS</literal> so that the slave starts - replicating from the correct position. Any table and database - exclusion rules specified with the - <literal>--replicate-*-do-*</literal> and - <literal>--replicate-*-ignore-*</literal> options are honored. - <literal>--replicate-rewrite-db</literal> is - <emphasis>not</emphasis> taken into account (because one user - could, with this option, set up a non-unique mapping such as - <literal>--replicate-rewrite-db=db1->db3</literal> and - <literal>--replicate-rewrite-db=db2->db3</literal>, which would - confuse the slave when it loads the master's tables). + This command takes a snapshot of the master and copies it to the + slave. It updates the values of <literal>MASTER_LOG_FILE</literal> + and <literal>MASTER_LOG_POS</literal> so that the slave starts + replicating from the correct position. Any table and database + exclusion rules specified with the + <literal>--replicate-*-do-*</literal> and + <literal>--replicate-*-ignore-*</literal> options are honored. + <literal>--replicate-rewrite-db</literal> is + <emphasis>not</emphasis> taken into account. This is because a + user could, with this option, set up a non-unique mapping such as + <literal>--replicate-rewrite-db=db1->db3</literal> and + <literal>--replicate-rewrite-db=db2->db3</literal>, which would + confuse the slave when loading tables from the master. </para> <para> - Use of this statement is subject to the following conditions: + Use of this statement is subject to the following conditions: </para> <itemizedlist> - - <listitem><para> - It works only with <literal>MyISAM</literal> tables. Attempting to - load a non-<literal>MyISAM</literal> table results in the error: - </para> + + <listitem> + <para> + It works only with <literal>MyISAM</literal> tables. + Attempting to load a non-<literal>MyISAM</literal> table + results in the following error: + </para> <programlisting> ERROR 1189 (08S01): Net error reading from master -</programlisting></listitem> - - <listitem><para> - It acquires a global read lock on the master while taking the - snapshot, which prevents updates on the master during the load - operation. - </para></listitem> - +</programlisting> + </listitem> + + <listitem> + <para> + It acquires a global read lock on the master while taking the + snapshot, which prevents updates on the master during the load + operation. + </para> + </listitem> + </itemizedlist> <para> - In the future, it is planned to make this statement work with - <literal>InnoDB</literal> tables and to remove the need for a - global read lock by using non-blocking online backup. + In the future, we plan to make this statement work with + <literal>InnoDB</literal> tables and to remove the need for a + global read lock by using non-blocking online backup. </para> <para> - If you are loading big tables, you might have to increase the - values of <literal>net_read_timeout</literal> and - <literal>net_write_timeout</literal> on both your master and slave - servers. See <xref linkend="server-system-variables"/>. + If you are loading large tables, you might have to increase the + values of <literal>net_read_timeout</literal> and + <literal>net_write_timeout</literal> on both the master and slave + servers. See <xref linkend="server-system-variables"/>. </para> <para> - Note that <literal>LOAD DATA FROM MASTER</literal> does - <emphasis>not</emphasis> copy any tables from the - <literal>mysql</literal> database. This makes it easy to have - different users and privileges on the master and the slave. + Note that <literal>LOAD DATA FROM MASTER</literal> does + <emphasis>not</emphasis> copy any tables from the + <literal>mysql</literal> database. This makes it easy to have + different users and privileges on the master and the slave. </para> <para> - The <literal>LOAD DATA FROM MASTER</literal> statement requires the - replication account that is used to connect to the master to have - the <literal>RELOAD</literal> and <literal>SUPER</literal> - privileges on the master and the <literal>SELECT</literal> - privilege for all master tables you want to load. All master tables - for which the user does not have the <literal>SELECT</literal> - privilege are ignored by <literal>LOAD DATA FROM MASTER</literal>. - This is because the master hides them from the user: <literal>LOAD - DATA FROM MASTER</literal> calls <literal>SHOW DATABASES</literal> - to know the master databases to load, but <literal>SHOW - DATABASES</literal> returns only databases for which the user has - some privilege. See <xref linkend="show-databases"/>. On the - slave's side, the user that issues <literal>LOAD DATA FROM - MASTER</literal> should have grants to drop and create the - databases and tables that are copied. + The <literal>LOAD DATA FROM MASTER</literal> statement requires + the replication account that is used to connect to the master to + have the <literal>RELOAD</literal> and <literal>SUPER</literal> + privileges on the master and the <literal>SELECT</literal> + privilege for all master tables you want to load. All master + tables for which the user does not have the + <literal>SELECT</literal> privilege are ignored by <literal>LOAD + DATA FROM MASTER</literal>. This is because the master hides them + from the user: <literal>LOAD DATA FROM MASTER</literal> calls + <literal>SHOW DATABASES</literal> to know the master databases to + load, but <literal>SHOW DATABASES</literal> returns only databases + for which the user has some privilege. See + <xref linkend="show-databases"/>. On the slave side, the user that + issues <literal>LOAD DATA FROM MASTER</literal> should have grants + to drop and create the databases and tables that are copied. <!-- end_description_for_help_topic --> </para> @@ -15546,22 +15667,23 @@ </programlisting> <para> - Transfers a copy of the table from master to the slave. This - statement is implemented mainly for debugging of <literal>LOAD DATA - FROM MASTER</literal>. It requires that the account used for - connecting to the master server has the <literal>RELOAD</literal> - and <literal>SUPER</literal> privileges on the master and the - <literal>SELECT</literal> privilege on the master table to load. On - the slave side, the user that issues <literal>LOAD TABLE FROM - MASTER</literal> should have privileges to drop and create the - table. + Transfers a copy of the table from the master to the slave. This + statement is implemented mainly for debugging of <literal>LOAD + DATA FROM MASTER</literal>. It requires that the account used for + connecting to the master server has the <literal>RELOAD</literal> + and <literal>SUPER</literal> privileges on the master and the + <literal>SELECT</literal> privilege on the master table to load. + On the slave side, the user that issues <literal>LOAD TABLE FROM + MASTER</literal> should have privileges to drop and create the + table. </para> <para> - The conditions for <literal>LOAD DATA FROM MASTER</literal> apply - here, too. For example, <literal>LOAD TABLE FROM MASTER</literal> - works only for <literal>MyISAM</literal> tables. The timeout notes - for <literal>LOAD DATA FROM MASTER</literal> apply as well. + The conditions for <literal>LOAD DATA FROM MASTER</literal> apply + here as well. For example, <literal>LOAD TABLE FROM + MASTER</literal> works only for <literal>MyISAM</literal> tables. + The timeout notes for <literal>LOAD DATA FROM MASTER</literal> + apply as well. <!-- end_description_for_help_topic --> </para> @@ -15587,10 +15709,10 @@ <!-- help_category Administration --> <para> - This is a function, not a statement. It is used to ensure that the - slave has read and executed events up to a given position in the - master's binary log. See <xref linkend="miscellaneous-functions"/> - for a full description. + This is actually a function, not a statement. It is used to ensure + that the slave has read and executed events up to a given position + in the master's binary log. See + <xref linkend="miscellaneous-functions"/> for a full description. <!-- end_description_for_help_topic --> </para> @@ -15612,35 +15734,30 @@ </programlisting> <para> - Makes the slave forget its replication position in the master's - binary logs. This statement is meant to be used for a clean start: - It deletes the <filename>master.info</filename> and - <filename>relay-log.info</filename> files, all the relay logs, and - starts a new relay log. + Makes the slave forget its replication position in the master's + binary logs. This statement is meant to be used for a clean start: + It deletes the <filename>master.info</filename> and + <filename>relay-log.info</filename> files, all the relay logs, and + starts a new relay log. </para> <para> - <emphasis role="bold">Note</emphasis>: All relay logs are deleted, - even if they have not been totally executed by the slave SQL - thread. (This is a condition likely to exist on a replication slave - if you have issued a <literal>STOP SLAVE</literal> statement or if - the slave is highly loaded.) + <emphasis role="bold">Note</emphasis>: All relay logs are deleted, + even if they have not been completely executed by the slave SQL + thread. (This is a condition likely to exist on a replication + slave if you have issued a <literal>STOP SLAVE</literal> statement + or if the slave is highly loaded.) </para> <para> - Connection information stored in the - <filename>master.info</filename> file is immediately reset using - any values specified in the corresponding startup options. This - information includes values such as master host, master port, - master user, and master password. If the slave SQL thread was in - the middle of replicating temporary tables when it was stopped, and - <literal>RESET SLAVE</literal> is issued, these replicated - temporary tables are deleted on the slave. - </para> - - <para> - This statement was named <literal>FLUSH SLAVE</literal> before - MySQL 3.23.26. + Connection information stored in the + <filename>master.info</filename> file is immediately reset using + any values specified in the corresponding startup options. This + information includes values such as master host, master port, + master user, and master password. If the slave SQL thread was in + the middle of replicating temporary tables when it was stopped, + and <literal>RESET SLAVE</literal> is issued, these replicated + temporary tables are deleted on the slave. <!-- end_description_for_help_topic --> </para> @@ -15662,19 +15779,14 @@ </programlisting> <para> - Skip the next <replaceable>n</replaceable> events from the master. - This is useful for recovering from replication stops caused by a - statement. - </para> - - <para> - This statement is valid only when the slave thread is not running. - Otherwise, it produces an error. + Skip the next <replaceable>n</replaceable> events from the master. + This is useful for recovering from replication stops caused by a + statement. </para> <para> - Before MySQL 4.0, omit the <literal>GLOBAL</literal> keyword from - the statement. + This statement is valid only when the slave thread is not running. + Otherwise, it produces an error. <!-- end_description_for_help_topic --> </para> @@ -15696,11 +15808,11 @@ </programlisting> <para> - Provides status information on essential parameters of the slave - threads. If you issue this statement using the - <command>mysql</command> client, you can use a - <literal>\G</literal> statement terminator rather than semicolon to - get a more readable vertical layout: + Provides status information on essential parameters of the slave + threads. If you issue this statement using the + <command>mysql</command> client, you can use a + <literal>\G</literal> statement terminator rather than semicolon + to obtain a more readable vertical layout: </para> <programlisting> @@ -15740,380 +15852,403 @@ <!-- end_description_for_help_topic --> <para> - Depending on your version of MySQL, you may not see all the fields - just shown. In particular, several fields are present only as of - MySQL 4.1.1. - </para> - - <para> <literal>SHOW SLAVE STATUS</literal> returns the following fields: </para> <itemizedlist> - - <listitem><para> - <literal>Slave_IO_State</literal> - </para> - - <para> - A copy of the <literal>State</literal> field of the output of - <literal>SHOW PROCESSLIST</literal> for the slave I/O thread. This - tells you if the thread is trying to connect to the master, - waiting for events from the master, reconnecting to the master, - and so on. Possible states are listed in - <xref linkend="replication-implementation-details"/>. Looking at - this field is necessary because, for example, the thread can be - running but unsuccessfully trying to connect to the master; only - this field makes you aware of the connection problem. The state of - the SQL thread is not copied because it is simpler. If it is - running, there is no problem; if it is not, you can find the error - in the <literal>Last_Error</literal> field (described below). - </para> - - <para> - This field is present beginning with MySQL 4.1.1. - </para></listitem> - - <listitem><para> - <literal>Master_Host</literal> - </para> - - <para> - The current master host. - </para></listitem> - - <listitem><para> - <literal>Master_User</literal> - </para> - - <para> - The current user used to connect to the master. - </para></listitem> - - <listitem><para> - <literal>Master_Port</literal> - </para> - - <para> - The current master port. - </para></listitem> - - <listitem><para> - <literal>Connect_Retry</literal> - </para> - - <para> - The current value of the <literal>--master-connect-retry</literal> - option. - </para></listitem> - - <listitem><para> - <literal>Master_Log_File</literal> - </para> - - <para> - The name of the master binary log file from which the I/O thread - is currently reading. - </para></listitem> - - <listitem><para> - <literal>Read_Master_Log_Pos</literal> - </para> - - <para> - The position up to which the I/O thread has read in the current - master binary log. - </para></listitem> - - <listitem><para> - <literal>Relay_Log_File</literal> - </para> - - <para> - The name of the relay log file from which the SQL thread is - currently reading and executing. - </para></listitem> - - <listitem><para> - <literal>Relay_Log_Pos</literal> - </para> - - <para> - The position up to which the SQL thread has read and executed in - the current relay log. - </para></listitem> - - <listitem><para> - <literal>Relay_Master_Log_File</literal> - </para> - - <para> - The name of the master binary log file that contains the last - event executed by the SQL thread. - </para></listitem> - - <listitem><para> - <literal>Slave_IO_Running</literal> - </para> - - <para> - Whether or not the I/O thread is started. - </para></listitem> - - <listitem><para> - <literal>Slave_SQL_Running</literal> - </para> - - <para> - Whether or not the SQL thread is started. - </para></listitem> - - <listitem><para> - <literal>Replicate_Do_DB, Replicate_Ignore_DB</literal> - </para> - - <para> - The lists of databases that were specified with the - <literal>--replicate-do-db</literal> and - <literal>--replicate-ignore-db</literal> options, if any. - </para> - - <para> - These fields are present beginning with MySQL 4.1.1. - </para></listitem> - - <listitem><para> - <literal>Replicate_Do_Table, Replicate_Ignore_Table, - Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table</literal> - </para> - - <para> - The lists of tables that were specified with the - <literal>--replicate-do-table</literal>, - <literal>--replicate-ignore-table</literal>, - <literal>--replicate-wild-do-table</literal>, and - <literal>--replicate-wild-ignore_table</literal> options, if any. - </para> - - <para> - These fields are present beginning with MySQL 4.1.1. - </para></listitem> - - <listitem><para> - <literal>Last_Errno, Last_Error</literal> - </para> - - <para> - The error number and error message returned by the most recently - executed query. An error number of 0 and message of the empty - string mean ``no error.'' If the <literal>Last_Error</literal> - value is not empty, it also appears as a message in the slave's - error log. - </para> - - <para> - For example: - </para> - - <para> + + <listitem> + <para> + <literal>Slave_IO_State</literal> + </para> + + <para> + A copy of the <literal>State</literal> field of the output of + <literal>SHOW PROCESSLIST</literal> for the slave I/O thread. + This tells you if the thread is trying to connect to the + master, waiting for events from the master, reconnecting to + the master, and so on. Possible states are listed in + <xref linkend="replication-implementation-details"/>. Looking + at this field is necessary because, for example, the thread + can be running but unsuccessfully trying to connect to the + master; only this field makes you aware of the connection + problem. The state of the SQL thread is not copied because it + is simpler. If it is running, there is no problem; if it is + not, you can find the error in the + <literal>Last_Error</literal> field (described below). + </para> + </listitem> + + <listitem> + <para> + <literal>Master_Host</literal> + </para> + + <para> + The current master host. + </para> + </listitem> + + <listitem> + <para> + <literal>Master_User</literal> + </para> + + <para> + The current user used to connect to the master. + </para> + </listitem> + + <listitem> + <para> + <literal>Master_Port</literal> + </para> + + <para> + The current master port. + </para> + </listitem> + + <listitem> + <para> + <literal>Connect_Retry</literal> + </para> + + <para> + The current value of the + <literal>--master-connect-retry</literal> option. + </para> + </listitem> + + <listitem> + <para> + <literal>Master_Log_File</literal> + </para> + + <para> + The name of the master binary log file from which the I/O + thread is currently reading. + </para> + </listitem> + + <listitem> + <para> + <literal>Read_Master_Log_Pos</literal> + </para> + + <para> + The position up to which the I/O thread has read in the + current master binary log. + </para> + </listitem> + + <listitem> + <para> + <literal>Relay_Log_File</literal> + </para> + + <para> + The name of the relay log file from which the SQL thread is + currently reading and executing. + </para> + </listitem> + + <listitem> + <para> + <literal>Relay_Log_Pos</literal> + </para> + + <para> + The position up to which the SQL thread has read and executed + in the current relay log. + </para> + </listitem> + + <listitem> + <para> + <literal>Relay_Master_Log_File</literal> + </para> + + <para> + The name of the master binary log file containing the most + recent event executed by the SQL thread. + </para> + </listitem> + + <listitem> + <para> + <literal>Slave_IO_Running</literal> + </para> + + <para> + Whether or not the I/O thread is started. + </para> + </listitem> + + <listitem> + <para> + <literal>Slave_SQL_Running</literal> + </para> + + <para> + Whether or not the SQL thread is started. + </para> + </listitem> + + <listitem> + <para> + <literal>Replicate_Do_DB, Replicate_Ignore_DB</literal> + </para> + + <para> + The lists of databases that were specified with the + <literal>--replicate-do-db</literal> and + <literal>--replicate-ignore-db</literal> options, if any. + </para> + </listitem> + + <listitem> + <para> + <literal>Replicate_Do_Table, Replicate_Ignore_Table, + Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table</literal> + </para> + + <para> + The lists of tables that were specified with the + <literal>--replicate-do-table</literal>, + <literal>--replicate-ignore-table</literal>, + <literal>--replicate-wild-do-table</literal>, and + <literal>--replicate-wild-ignore_table</literal> options, if + any. + </para> + </listitem> + + <listitem> + <para> + <literal>Last_Errno, Last_Error</literal> + </para> + + <para> + The error number and error message returned by the most + recently executed query. An error number of 0 and message of + the empty string mean ``no error.'' If the + <literal>Last_Error</literal> value is not empty, it also + appears as a message in the slave's error log. + </para> + + <para> + For example: <programlisting> Last_Errno: 1051 Last_Error: error 'Unknown table 'z'' on query 'drop table z' </programlisting> - </para> + </para> + + <para> + The message indicates that the table <literal>z</literal> + existed on the master and was dropped there, but it did not + exist on the slave, so <literal>DROP TABLE</literal> failed on + the slave. (This might occur, for example, if you forget to + copy the table to the slave when setting up replication.) + </para> + </listitem> + + <listitem> + <para> + <literal>Skip_Counter</literal> + </para> + + <para> + The most recently used value for + <literal>SQL_SLAVE_SKIP_COUNTER</literal>. + </para> + </listitem> + + <listitem> + <para> + <literal>Exec_Master_Log_Pos</literal> + </para> + + <para> + The position of the last event executed by the SQL thread from + the master's binary log + (<literal>Relay_Master_Log_File</literal>). + (<literal>Relay_Master_Log_File</literal>, + <literal>Exec_Master_Log_Pos</literal>) in the master's binary + log corresponds to (<literal>Relay_Log_File</literal>, + <literal>Relay_Log_Pos</literal>) in the relay log. + </para> + </listitem> + + <listitem> + <para> + <literal>Relay_Log_Space</literal> + </para> + + <para> + The total combined size of all existing relay logs. + </para> + </listitem> + + <listitem> + <para> + <literal>Until_Condition, Until_Log_File, + Until_Log_Pos</literal> + </para> + + <para> + The values specified in the <literal>UNTIL</literal> clause of + the <literal>START SLAVE</literal> statement. + </para> + + <para> + <literal>Until_Condition</literal> has these values: + </para> + + <itemizedlist> + + <listitem> + <para> + <literal>None</literal> if no <literal>UNTIL</literal> + clause was specified + </para> + </listitem> + + <listitem> + <para> + <literal>Master</literal> if the slave is reading until a + given position in the master's binary logs + </para> + </listitem> + + <listitem> + <para> + <literal>Relay</literal> if the slave is reading until a + given position in its relay logs + </para> + </listitem> + + </itemizedlist> + + <para> + <literal>Until_Log_File</literal> and + <literal>Until_Log_Pos</literal> indicate the log filename and + position values that define the point at which the SQL thread + stops executing. + </para> + </listitem> + + <listitem> + <para> + <literal>Master_SSL_Allowed, Master_SSL_CA_File, + Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, + Master_SSL_Key</literal> + </para> + + <para> + These fields show the SSL parameters used by the slave to + connect to the master, if any. + </para> + + <para> + <literal>Master_SSL_Allowed</literal> has these values: + </para> - <para> - The message indicates that the table <literal>z</literal> existed - on the master and was dropped there, but it did not exist on the - slave, so <literal>DROP TABLE</literal> failed on the slave. (This - might occur, for example, if you forget to copy the table to the - slave when setting up replication.) - </para></listitem> - - <listitem><para> - <literal>Skip_Counter</literal> - </para> - - <para> - The last used value for <literal>SQL_SLAVE_SKIP_COUNTER</literal>. - </para></listitem> - - <listitem><para> - <literal>Exec_Master_Log_Pos</literal> - </para> - - <para> - The position of the last event executed by the SQL thread from the - master's binary log (<literal>Relay_Master_Log_File</literal>). - (<literal>Relay_Master_Log_File</literal>, - <literal>Exec_Master_Log_Pos</literal>) in the master's binary log - corresponds to (<literal>Relay_Log_File</literal>, - <literal>Relay_Log_Pos</literal>) in the relay log. - </para></listitem> - - <listitem><para> - <literal>Relay_Log_Space</literal> - </para> - - <para> - The total combined size of all existing relay logs. - </para></listitem> - - <listitem><para> - <literal>Until_Condition, Until_Log_File, Until_Log_Pos</literal> - </para> - - <para> - The values specified in the <literal>UNTIL</literal> clause of the - <literal>START SLAVE</literal> statement. - </para> - - <para> - <literal>Until_Condition</literal> has these values: - </para> - - <para> - <itemizedlist> - - <listitem><para> - <literal>None</literal> if no <literal>UNTIL</literal> clause - was specified - </para></listitem> - - <listitem><para> - <literal>Master</literal> if the slave is reading until a given - position in the master's binary logs - </para></listitem> - - <listitem><para> - <literal>Relay</literal> if the slave is reading until a given - position in its relay logs - </para></listitem> - - </itemizedlist> - </para> - - <para> - <literal>Until_Log_File</literal> and - <literal>Until_Log_Pos</literal> indicate the log filename and - position values that define the point at which the SQL thread - stops executing. - </para> - - <para> - These fields are present beginning with MySQL 4.1.1. - </para></listitem> - - <listitem><para> - <literal>Master_SSL_Allowed, Master_SSL_CA_File, - Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, - Master_SSL_Key</literal> - </para> - - <para> - These fields show the SSL parameters used by the slave to connect - to the master, if any. - </para> - - <para> - <literal>Master_SSL_Allowed</literal> has these values: - </para> - - <para> <itemizedlist> - - <listitem><para> - <literal>Yes</literal> if an SSL connection to the master is - allowed - </para></listitem> - - <listitem><para> - <literal>No</literal> if an SSL connection to the master is not - allowed - </para></listitem> - - <listitem><para> - <literal>Ignored</literal> if an SSL connection is allowed but - the slave server does not have SSL support enabled - </para></listitem> - - </itemizedlist> - </para> - - <para> - The values of the other SSL-related fields correspond to the - values of the <literal>--master-ca</literal>, - <literal>--master-capath</literal>, - <literal>--master-cert</literal>, - <literal>--master-cipher</literal>, and - <literal>--master-key</literal> options. - </para> - - <para> - These fields are present beginning with MySQL 4.1.1. - </para></listitem> - - <listitem><para> - <literal>Seconds_Behind_Master</literal> - </para> - - <para> - This field is present beginning with MySQL 4.1.1. It's been - experimental and has been changed in MySQL 4.1.9. The following - applies to slaves running MySQL 4.1.9 or newer. This field is an - indication of how ``late'' the slave is. When the slave SQL thread - is actively running (processing updates), this field is the number - of seconds that have elapsed since the timestamp of the last - master's event executed by that thread. When that thread has - caught up on the slave I/O thread and goes idle waiting from more - events from the I/O thread this field is zero. To sum up, this - field measures in seconds the time difference between the slave - SQL thread and the slave I/O thread. - </para> - - <para> - If the network connection between master and slave is fast, the - slave I/O thread is very close to the master, so this field is a - good approximation of how late the slave SQL thread is compared to - the master. If the network is slow, this is - <emphasis role="bold">not</emphasis> a good approximation; the - slave SQL thread may quite often be caught up with the - slow-reading slave I/O thread, so - <literal>Seconds_Behind_Master</literal> often shows a value of 0, - even if the I/O thread is late compared to the master. In other - words, <emphasis role="bold">this column is useful only for fast - networks</emphasis>. - </para> - - <para> - This time difference computation works even though your master and - slave don't have identical clocks (the clock difference is - computed when the slave I/O thread starts, and assumed to remain - constant from then on). <literal>Seconds_Behind_Master</literal> - is <literal>NULL</literal> (which means ``unknown'') if the slave - SQL thread is not running, or if the slave I/O thread is not - running or not connected to master. For example if the slave I/O - thread is sleeping for <literal>master-connect-retry</literal> - seconds before reconnecting, <literal>NULL</literal> is shown, as - the slave cannot know what the master is doing, and thus cannot - reliably say how late it is. - </para> - - <para> - This field has one limitation. Indeed the timestamp is preserved - through replication, which means that if your master M1 is itself - a slave of M0, any event from M1's binlog which has its origin in - replication of an event of M0's binlog, has the timestamp of that - last event. This enables MySQL to replicate - <literal>TIMESTAMP</literal> successfully. But the drawback for - <literal>Seconds_Behind_Master</literal> is that if M1 also - receives direct updates from clients, then the value randomly goes - up and down, because sometimes the last M1's event is from M0 and - sometimes it is from a direct update, and so is the last - timestamp. - </para></listitem> - - </itemizedlist> + + <listitem> + <para> + <literal>Yes</literal> if an SSL connection to the master is + permitted + </para> + </listitem> + + <listitem> + <para> + <literal>No</literal> if an SSL connection to the master is + not permitted + </para> + </listitem> + + <listitem> + <para> + <literal>Ignored</literal> if an SSL connection is permitted + but the slave server does not have SSL support enabled + </para> + </listitem> + + </itemizedlist> + + <para> + The values of the other SSL-related fields correspond to the + values of the <literal>--master-ca</literal>, + <literal>--master-capath</literal>, + <literal>--master-cert</literal>, + <literal>--master-cipher</literal>, and + <literal>--master-key</literal> options. + </para> + </listitem> + + <listitem> + <para> + <literal>Seconds_Behind_Master</literal> + </para> + + <para> + This field is an indication of how ``late'' the slave is. When + the slave SQL thread is actively running (processing updates), + this field is the number of seconds that have elapsed since the + timestamp of the most recent event on the master executed by that + thread. When that thread has caught up on the slave I/O thread + and goes idle waiting from more events from the I/O thread this + field is zero. In sum, this field measures in seconds the time + difference between the slave SQL thread and the slave I/O thread. + </para> +<!-- TODO: How fast is "fast"? --> + <para> + If the network connection between master and slave is fast, the + slave I/O thread is very close to the master, so this field is a + good approximation of how late the slave SQL thread is compared + to the master. If the network is slow, this is + <emphasis role="bold">not</emphasis> a good approximation; the + slave SQL thread may quite often be caught up with the + slow-reading slave I/O thread, so + <literal>Seconds_Behind_Master</literal> often shows a value of + 0, even if the I/O thread is late compared to the master. In + other words, <emphasis role="bold">this column is useful only for + fast networks</emphasis>. + </para> + + <para> + This time difference computation works even though the master and + slave don't have identical clocks (the clock difference is + computed when the slave I/O thread starts, and assumed to remain + constant from then on). <literal>Seconds_Behind_Master</literal> + is <literal>NULL</literal> (which means ``unknown'') if the slave + SQL thread is not running, or if the slave I/O thread is not + running or not connected to master. For example if the slave I/O + thread is sleeping for <literal>master-connect-retry</literal> + seconds before reconnecting, <literal>NULL</literal> is shown, as + the slave cannot know what the master is doing, and so cannot say + reliably how late it is. + </para> + + <para> + This field has one limitation. The timestamp is preserved + through replication, which means that, if a master M1 is itself a + slave of M0, any event from M1's binlog which originates in + replicating an event from M0's binlog has the timestamp of that + event. This enables MySQL to replicate + <literal>TIMESTAMP</literal> successfully. However, the drawback + for <literal>Seconds_Behind_Master</literal> is that if M1 also + receives direct updates from clients, then the value randomly + deviates, because sometimes the last M1's event is from M0 and + sometimes it is from a direct update, and so is the most recent + timestamp. + </para> + </listitem> + + </itemizedlist> </section> @@ -16138,89 +16273,90 @@ </programlisting> <para> - <literal>START SLAVE</literal> with no options starts both of the - slave threads. The I/O thread reads queries from the master server - and stores them in the relay log. The SQL thread reads the relay - log and executes the queries. <literal>START SLAVE</literal> - requires the <literal>SUPER</literal> privilege. + <literal>START SLAVE</literal> with no options starts both of the + slave threads. The I/O thread reads queries from the master server + and stores them in the relay log. The SQL thread reads the relay + log and executes the queries. <literal>START SLAVE</literal> + requires the <literal>SUPER</literal> privilege. </para> <para> - If <literal>START SLAVE</literal> succeeds in starting the slave - threads, it returns without any error. However, even in that case, - it might be that the slave threads start and then later stop (for - example, because they don't manage to connect to the master or read - its binary logs, or some other problem). <literal>START - SLAVE</literal> does not warn you about this. You must check your - slave's error log for error messages generated by the slave - threads, or check that they are running fine with <literal>SHOW - SLAVE STATUS</literal>. + If <literal>START SLAVE</literal> succeeds in starting the slave + threads, it returns without any error. However, even in that case, + it might be that the slave threads start and then later stop (for + example, because they don't manage to connect to the master or + read its binary logs, or some other problem). <literal>START + SLAVE</literal> does not warn you about this. You must check the + slave's error log for error messages generated by the slave + threads, or check that they are running fine with <literal>SHOW + SLAVE STATUS</literal>. </para> <!-- end_description_for_help_topic --> <para> - As of MySQL 4.0.2, you can add <literal>IO_THREAD</literal> and - <literal>SQL_THREAD</literal> options to the statement to name - which of the threads to start. + In MySQL 5.0, you can add <literal>IO_THREAD</literal> and + <literal>SQL_THREAD</literal> options to the statement to name + which of the threads to start. </para> <para> - As of MySQL 4.1.1, an <literal>UNTIL</literal> clause may be added - to specify that the slave should start and run until the SQL thread - reaches a given point in the master binary logs or in the slave - relay logs. When the SQL thread reaches that point, it stops. If - the <literal>SQL_THREAD</literal> option is specified in the - statement, it starts only the SQL thread. Otherwise, it starts both - slave threads. If the SQL thread is running, the - <literal>UNTIL</literal> clause is ignored and a warning is issued. + An <literal>UNTIL</literal> clause may be added to specify that + the slave should start and run until the SQL thread + reaches a given point in the master binary logs or in the slave + relay logs. When the SQL thread reaches that point, it stops. If + the <literal>SQL_THREAD</literal> option is specified in the + statement, it starts only the SQL thread. Otherwise, it starts + both slave threads. If the SQL thread is running, the + <literal>UNTIL</literal> clause is ignored and a warning is + issued. </para> <para> - With an <literal>UNTIL</literal> clause, you must specify both a - log filename and position. Do not mix master and relay log options. + For an <literal>UNTIL</literal> clause, you must specify both a + log filename and position. Do not mix master and relay log options. </para> <para> - Any <literal>UNTIL</literal> condition is reset by a subsequent - <literal>STOP SLAVE</literal> statement, a <literal>START - SLAVE</literal> statement that includes no <literal>UNTIL</literal> - clause, or a server restart. + Any <literal>UNTIL</literal> condition is reset by a subsequent + <literal>STOP SLAVE</literal> statement, a <literal>START + SLAVE</literal> statement that includes no + <literal>UNTIL</literal> clause, or a server restart. </para> <para> - The <literal>UNTIL</literal> clause can be useful for debugging - replication, or to cause replication to proceed until just before - the point where you want to avoid having the slave replicate a - statement. For example, if an unwise <literal>DROP TABLE</literal> - statement was executed on the master, you can use - <literal>UNTIL</literal> to tell the slave to execute up to that - point but no farther. To find what the event is, use - <command>mysqlbinlog</command> with the master logs or slave relay - logs, or by using a <literal>SHOW BINLOG EVENTS</literal> - statement. + The <literal>UNTIL</literal> clause can be useful for debugging + replication, or to cause replication to proceed until just before + the point where you want to avoid having the slave replicate a + statement. For example, if an unwise <literal>DROP TABLE</literal> + statement was executed on the master, you can use + <literal>UNTIL</literal> to tell the slave to execute up to that + point but no farther. To find what the event is, use + <command>mysqlbinlog</command> with the master logs or slave relay + logs, or by using a <literal>SHOW BINLOG EVENTS</literal> + statement. </para> <para> - If you are using <literal>UNTIL</literal> to have the slave process - replicated queries in sections, it is recommended that you start - the slave with the <literal>--skip-slave-start</literal> option to - prevent the SQL thread from running when the slave server starts. - It is probably best to use this option in an option file rather - than on the command line, so that an unexpected server restart does - not cause it to be forgotten. + If you are using <literal>UNTIL</literal> to have the slave + process replicated queries in sections, it is recommended that you + start the slave with the <literal>--skip-slave-start</literal> + option to prevent the SQL thread from running when the slave + server starts. It is probably best to use this option in an option + file rather than on the command line, so that an unexpected server + restart does not cause it to be forgotten. </para> <para> - The <literal>SHOW SLAVE STATUS</literal> statement includes output - fields that display the current values of the - <literal>UNTIL</literal> condition. + The <literal>SHOW SLAVE STATUS</literal> statement includes output + fields that display the current values of the + <literal>UNTIL</literal> condition. </para> <para> - This statement is called <literal>SLAVE START</literal> before - MySQL 4.0.5. For the moment, <literal>SLAVE START</literal> is - still accepted for backward compatibility, but is deprecated. + In previous versions of MySQL, this statement was called + <literal>SLAVE START</literal> this usage is still accepted in + MySQL 5.0 for backward compatibility, but is now deprecated. </para> </section> @@ -16242,56 +16378,48 @@ </programlisting> <para> - Stops the slave threads. <literal>STOP SLAVE</literal> requires the - <literal>SUPER</literal> privilege. + Stops the slave threads. <literal>STOP SLAVE</literal> requires + the <literal>SUPER</literal> privilege. </para> <para> - Like <literal>START SLAVE</literal>, as of MySQL 4.0.2, this - statement may be used with the <literal>IO_THREAD</literal> and - <literal>SQL_THREAD</literal> options to name the thread or threads - to stop. + Like <literal>START SLAVE</literal>, this statement may be used + with the <literal>IO_THREAD</literal> and + <literal>SQL_THREAD</literal> options to name the thread or + threads to be stopped. </para> <!-- end_description_for_help_topic --> <para> - This statement is called <literal>SLAVE STOP</literal> before MySQL - 4.0.5. For the moment, <literal>SLAVE STOP</literal> is still - accepted for backward compatibility, but is deprecated. - </para> - -<!-- DISABLED UNTIL IT WORKS (OR UNTIL WE GIVE THIS STRATEGY UP?) --> - -<!-- @node SHOW NEW MASTER, PURGE MASTER LOGS, SHOW BINLOG EVENTS, Replication SQL --> - -<!-- @subsubsection @code{SHOW NEW MASTER FOR SLAVE} --> - -<!-- @code{SHOW NEW MASTER FOR SLAVE --> - -<!-- WITH MASTER_LOG_FILE='@var{logfile}' AND MASTER_LOG_POS=@var{pos} AND --> - -<!-- MASTER_LOG_SEQ=@var{log_seq} AND MASTER_SERVER_ID=@var{server_id}} --> - -<!-- --> - -<!-- This statement is used when a slave of a possibly dead/unavailable master --> - -<!-- needs to be switched to replicate off another slave that has been --> - -<!-- replicating the same master. The statement return recalculated --> - -<!-- replication coordinates (the slave's current binary log file --> - -<!-- name and position within that file). The output can be used in a subsequent --> - -<!-- @code{CHANGE MASTER TO} statement. Normal users should never need to run --> - -<!-- this statement. It is primarily reserved for internal use by the fail-safe --> - -<!-- replication code. We may later change the syntax if we find a more --> - -<!-- intuitive way to describe this operation. --> + In previous versions of MySQL, this statement was called + <literal>SLAVE STOP</literal>. This usage is still accepted in + MySQL 5.0 for backward compatibility, but is now deprecated. + </para> + +<!-- + DISABLED UNTIL IT WORKS (OR UNTIL WE GIVE THIS STRATEGY UP?) + + @node SHOW NEW MASTER, PURGE MASTER LOGS, SHOW BINLOG EVENTS, Replication SQL + + @subsubsection @code{SHOW NEW MASTER FOR SLAVE} + + @code{SHOW NEW MASTER FOR SLAVE + + WITH MASTER_LOG_FILE='@var{logfile}' AND MASTER_LOG_POS=@var{pos} + AND MASTER_LOG_SEQ=@var{log_seq} AND MASTER_SERVER_ID=@var{server_id}} + + This statement is used when a slave of a possibly dead/unavailable + master needs to be switched to replicate off another slave that + has been replicating the same master. The statement returns + recalculated replication coordinates (the slave's current binary + log file name and position within that file). The output can be + used in a subsequent @code{CHANGE MASTER TO} statement. Normal + users should never need to run this statement. It is primarily + reserved for internal use by the fail-safe replication code. We + may later change the syntax if we find a more intuitive way to + describe this operation. +--> </section> @@ -16316,91 +16444,101 @@ </indexterm> <para> - Support for server-side prepared statements was added in MySQL 4.1. - This support takes advantage of the efficient client/server binary - protocol, provided that you use an appropriate client programming - interface. Candidate interfaces include the MySQL C API client - library (for C programs), MySQL Connector/J (for Java programs), and - MySQL Connector/NET. For example, the C API provides a set of - function calls that make up its prepared statement API. See - <xref linkend="c-api-prepared-statements"/>. Other language - interfaces can provide support for prepared statements that use the - binary protocol by linking in the C client library. (The - <ulink url="http://php.net/mysqli">mysqli extension in PHP - 5.0</ulink> does this, for example.) + MySQL 5.0 provides support for server-side prepared statements. This + support takes advantage of the efficient client/server binary + protocol implemented in MySQL 4.1, provided that you use an + appropriate client programming interface. Candidate interfaces + include the MySQL C API client library (for C programs), MySQL + Connector/J (for Java programs), and MySQL Connector/NET. For + example, the C API provides a set of function calls that make up its + prepared statement API. See + <xref linkend="c-api-prepared-statements"/>. Other language + interfaces can provide support for prepared statements that use the + binary protocol by linking in the C client library, one example + being the <ulink url="http://php.net/mysqli">mysqli extension in PHP + 5.0</ulink>. </para> -<!-- TODO: have something (a table?) that summarizes versions when various --> - -<!-- APIs support the binary protocol. Might be better in API chapter, though. --> - -<!-- C: 4.1.0 --> - -<!-- C/J: 3.1.0 --> - -<!-- ODBC: ? --> - -<!-- PHP: mysqli in PHP 5.0.0 --> - -<!-- DBD::mysql: ? --> +<!-- + TODO: have something (a table?) that summarizes versions when various + APIs support the binary protocol. Might be better in API chapter, though. + + C: 4.1.0 + C/J: 3.1.0 + ODBC: ? + PHP: mysqli in PHP 5.0.0 + DBD::mysql: 3.0001_1 (Verify this with PatG!) +--> <para> - Beginning with MySQL 4.1.3, an alternative interface to prepared - statements is available: SQL syntax for prepared statements. This - interface is not as efficient as using the binary protocol through a - prepared statement API, but requires no programming because it is - available directly at the SQL level: + An alternative SQL interface to prepared statements is available. + This interface is not as efficient as using the binary protocol + through a prepared statement API, but requires no programming + because it is available directly at the SQL level: </para> <itemizedlist> - - <listitem><para> - You can use it when no programming interface is available to you. - </para></listitem> - - <listitem><para> - You can use it from any program that allows you to send SQL - statements to the server to be executed, such as the - <command>mysql</command> client program. - </para></listitem> - - <listitem><para> - You can use it even if the client is using an old version of the - client library. The only requirement is that you be able to connect - to a server that is recent enough to support SQL syntax for prepared - statements. - </para></listitem> - + + <listitem> + <para> + You can use it when no programming interface is available to you. + </para> + </listitem> + + <listitem> + <para> + You can use it from any program that allows you to send SQL + statements to the server to be executed, such as the + <command>mysql</command> client program. + </para> + </listitem> + + <listitem> + <para> + You can use it even if the client is using an old version of the + client library. The only requirement is that you be able to + connect to a server that is recent enough to support SQL syntax + for prepared statements. + </para> + </listitem> + </itemizedlist> <para> - SQL syntax for prepared statements is intended to be used for - situations such as these: + SQL syntax for prepared statements is intended to be used for + situations such as these: </para> <itemizedlist> - - <listitem><para> - You may want to test how prepared statements work in your - application before doing the application coding. Or perhaps an - application has a problem executing prepared statements and you want - to determine what the problem is interactively. - </para></listitem> - - <listitem><para> - You want to create a test case that describes a problem you are - having with prepared statements, so that you can file a bug report. - </para></listitem> - - <listitem><para> - You need to use prepared statements but do not have access to a - programming API that supports them. - </para></listitem> - + + <listitem> + <para> + You may want to test how prepared statements work in your + application before doing the application coding. Or perhaps an + application has a problem executing prepared statements and you + want to determine interactively what the problem is. + </para> + </listitem> + + <listitem> + <para> + You want to create a test case that describes a problem you are + having with prepared statements, so that you can file a bug + report. + </para> + </listitem> + + <listitem> + <para> + You need to use prepared statements but do not have access to a + programming API that supports them. + </para> + </listitem> + </itemizedlist> <para> - SQL syntax for prepared statements is based on three SQL statements: + SQL syntax for prepared statements is based on three SQL statements: </para> <programlisting> @@ -16412,78 +16550,79 @@ </programlisting> <para> - The <literal>PREPARE</literal> statement prepares a statement and - assigns it a name, <replaceable>stmt_name</replaceable>, by which to - refer to the statement later. Statement names are not case sensitive. - <replaceable>preparable_stmt</replaceable> is either a string literal - or a user variable that contains the text of the statement. The text - must represent a single SQL statement, not multiple statements. - Within the statement, '<literal>?</literal>' characters can be used - as parameter markers to indicate where data values are to be bound to - the query later when you execute it. The '<literal>?</literal>' - characters should not be enclosed within quotes, even if you intend - to bind them to string values. + The <literal>PREPARE</literal> statement prepares a statement and + assigns it a name, <replaceable>stmt_name</replaceable>, by which to + refer to the statement later. Statement names are not case + sensitive. <replaceable>preparable_stmt</replaceable> is either a + string literal or a user variable that contains the text of the + statement. The text must represent a single SQL statement, not + multiple statements. Within the statement, '<literal>?</literal>' + characters can be used as parameter markers to indicate where data + values are to be bound to the query later when you execute it. The + '<literal>?</literal>' characters should not be enclosed within + quotes, even if you intend to bind them to string values. </para> <para> - If a prepared statement exists with the same name, it is deallocated - implicitly before the new statement is prepared. This means that if - the new statement contains an error and cannot be prepared, an error - is returned and no statement with the given name exists. + If a prepared statement with that name already exists, it is + deallocated implicitly before the new statement is prepared. This + means that if the new statement contains an error and cannot be + prepared, an error is returned and no statement with the given name + exists. </para> <para> - The scope of a prepared statement is the client session within which - it is created. Other clients cannot see it. + The scope of a prepared statement is the client session within which + it is created. Other clients cannot see it. </para> <para> - After preparing a statement, you execute it with an - <literal>EXECUTE</literal> statement that refers to the prepared - statement name. If the prepared statement contains any parameter - markers, you must supply a <literal>USING</literal> clause that lists - user variables containing the values to be bound to the parameters. - Parameter values can be supplied only by user variables, and the - <literal>USING</literal> clause must name exactly as many variables - as the number of parameter markers in the statement. + After preparing a statement, you execute it with an + <literal>EXECUTE</literal> statement that refers to the prepared + statement name. If the prepared statement contains any parameter + markers, you must supply a <literal>USING</literal> clause that + lists user variables containing the values to be bound to the + parameters. Parameter values can be supplied only by user variables, + and the <literal>USING</literal> clause must name exactly as many + variables as the number of parameter markers in the statement. </para> <para> - You can execute a given prepared statement multiple times, passing it - different variables or setting the variables to different values - before each execution. + You can execute a given prepared statement multiple times, passing + different variables to it or setting the variables to different + values before each execution. </para> <para> - To deallocate a prepared statement, use the <literal>DEALLOCATE - PREPARE</literal> statement. Attempting to execute a prepared - statement after deallocating it results in an error. + To deallocate a prepared statement, use the <literal>DEALLOCATE + PREPARE</literal> statement. Attempting to execute a prepared + statement after deallocating it results in an error. </para> <para> - If you terminate a client session without deallocating a previously - prepared statement, the server deallocates it automatically. + If you terminate a client session without deallocating a previously + prepared statement, the server deallocates it automatically. </para> <para> - The following statements can be used as prepared statements: - <literal>CREATE TABLE</literal>, <literal>DELETE</literal>, - <literal>DO</literal>, <literal>INSERT</literal>, - <literal>REPLACE</literal>, <literal>SELECT</literal>, - <literal>SET</literal>, <literal>UPDATE</literal>, and most - <literal>SHOW</literal> statements. Other statements are not yet - supported. + The following SQL statements can be used in prepared statements: + <literal>CREATE TABLE</literal>, <literal>DELETE</literal>, + <literal>DO</literal>, <literal>INSERT</literal>, + <literal>REPLACE</literal>, <literal>SELECT</literal>, + <literal>SET</literal>, <literal>UPDATE</literal>, and most + <literal>SHOW</literal> statements. Other statements are not yet + supported. </para> <para> - The following examples show two equivalent ways of preparing a - statement that computes the hypotenuse of a triangle given the - lengths of the two sides. + The following examples show two equivalent ways of preparing a + statement that computes the hypotenuse of a triangle given the + lengths of the two sides. </para> <para> - The first example shows how to create a prepared statement by using a - string literal to supply the text of the statement: + The first example shows how to create a prepared statement by using + a string literal to supply the text of the statement: </para> <programlisting> @@ -16500,8 +16639,8 @@ </programlisting> <para> - The second example is similar, but supplies the text of the statement - with a user variable: + The second example is similar, but supplies the text of the + statement as a user variable: </para> <programlisting> @@ -16519,25 +16658,25 @@ </programlisting> <para> - SQL syntax for prepared statements cannot be used in nested fashion. - That is, a statement passed to <literal>PREPARE</literal> cannot - itself be a <literal>PREPARE</literal>, <literal>EXECUTE</literal>, - or <literal>DEALLOCATE PREPARE</literal> statement. + SQL syntax for prepared statements cannot be used in nested fashion. + That is, a statement passed to <literal>PREPARE</literal> cannot + itself be a <literal>PREPARE</literal>, <literal>EXECUTE</literal>, + or <literal>DEALLOCATE PREPARE</literal> statement. </para> <para> - Also, SQL syntax for prepared statements is distinct from using - prepared statement API calls. For example, you cannot use the - <literal>mysql_stmt_prepare()</literal> C API function to prepare a - <literal>PREPARE</literal>, <literal>EXECUTE</literal>, or - <literal>DEALLOCATE PREPARE</literal> statement. + Also, SQL syntax for prepared statements is distinct from using + prepared statement API calls. For example, you cannot use the + <literal>mysql_stmt_prepare()</literal> C API function to prepare a + <literal>PREPARE</literal>, <literal>EXECUTE</literal>, or + <literal>DEALLOCATE PREPARE</literal> statement. </para> <!-- Restriction implemented in 5.0.8; may be lifted later --> <para> - SQL syntax for prepared statements cannot be used within stored - procedures and functions. + SQL syntax for prepared statements cannot be used within stored + procedures and functions. </para> </section>
| Thread | ||
|---|---|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.2945) | jon | 7 Jul |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.833 sec. using MySQL 5.1.14-beta-log