Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul 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.3463 05/09/02 17:49:31 paul@stripped +8 -0
Slight rewording.
refman/replication.xml
1.29 05/09/02 17:49:27 paul@stripped +43 -38
Slight rewording.
refman/mysql-database-administration.xml
1.71 05/09/02 17:49:26 paul@stripped +6 -5
Slight rewording.
refman-5.1/replication.xml
1.20 05/09/02 17:49:26 paul@stripped +40 -35
Sync.
refman-5.1/mysql-database-administration.xml
1.31 05/09/02 17:49:26 paul@stripped +4 -4
Sync.
refman-5.0/replication.xml
1.20 05/09/02 17:49:26 paul@stripped +40 -35
Sync.
refman-5.0/mysql-database-administration.xml
1.32 05/09/02 17:49:26 paul@stripped +4 -4
Sync.
refman-4.1/replication.xml
1.27 05/09/02 17:49:25 paul@stripped +57 -52
Sync.
refman-4.1/mysql-database-administration.xml
1.60 05/09/02 17:49:25 paul@stripped +7 -7
Sync.
# 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: paul
# Host: frost.snake.net
# Root: /Volumes/frost2/MySQL/bk/mysqldoc
--- 1.30/refman-5.1/mysql-database-administration.xml 2005-08-31 11:15:20 -05:00
+++ 1.31/refman-5.1/mysql-database-administration.xml 2005-09-02 17:49:26 -05:00
@@ -22741,10 +22741,10 @@
</para>
<para>
- The rules for logging or ignoring updates to the binary log are
- evaluated according to the following rules. Observe that there
- is an exception for <literal>CREATE DATABASE</literal>,
- <literal>ALTER DATABASE</literal>, and <literal>DROP
+ The server evaluates the options for logging or ignoring updates
+ to the binary log according to the following rules. Observe that
+ there is an exception for
+ <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
DATABASE</literal> statements. In those cases, the database
being <emphasis>created, altered, or dropped</emphasis> replaces
the current database in the rules below.
--- 1.19/refman-5.1/replication.xml 2005-09-02 13:22:48 -05:00
+++ 1.20/refman-5.1/replication.xml 2005-09-02 17:49:26 -05:00
@@ -1186,15 +1186,15 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <command><literal>InnoDB</literal> Hot
- Backup</command> tool, which takes a consistent snapshot
- without acquiring any locks on the master server, and records
- the log name and offset corresponding to the snapshot to be
- later used on the slave. <command>Hot Backup</command> is an
- additional non-free (commercial) tool that is not included in
- the standard MySQL distribution. See the
- <command><literal>InnoDB</literal> Hot Backup</command> home
- page at <ulink url="http://www.innodb.com/manual.php"/> for
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
detailed information.
</para>
@@ -1429,7 +1429,7 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in the slave's
+ value for the slave, you get the following error in the slave's
error log:
</para>
@@ -1448,9 +1448,9 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. Do <emphasis>not</emphasis> remove or edit these files
- unless you know exactly what you are doing and fully understand
- the implications. Even in that case, it is preferred that you use
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
the <literal>CHANGE MASTER TO</literal> statement.
</para>
@@ -1900,7 +1900,7 @@
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (This is in general not a good
+ of the query optimizer. (This is in general not a good
practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
@@ -2052,18 +2052,18 @@
</programlisting>
<para>
- Server IDs are encoded in binary log events, so server A knows
- when an event that it reads was originally created by itself
- and does not execute the event (unless server A was started
- with the <option>--replicate-same-server-id</option> option,
- which is meaningful only in rare cases). Thus, there are no
- infinite loops. This type of circular setup works only if
- you perform no conflicting updates between the tables. In
- other words, if you insert data in both A and C, you should
- never insert a row in A that may have a key that conflicts
- with a row inserted in C. You should also not update the same
- rows on two servers if the order in which the updates are
- applied is significant.
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if you
+ perform no conflicting updates between the tables. In other
+ words, if you insert data in both A and C, you should never
+ insert a row in A that may have a key that conflicts with a
+ row inserted in C. You should also not update the same rows on
+ two servers if the order in which the updates are applied is
+ significant.
</para>
</listitem>
@@ -3066,9 +3066,9 @@
</itemizedlist>
<para>
- The <option>--replicate-*</option> rules are evaluated as follows
- to determine whether a statement is executed by the slave or
- ignored:
+ The slave server evaluates the <option>--replicate-*</option>
+ rules as follows to determine whether to execute or ignore a
+ statement:
</para>
<orderedlist>
@@ -3094,14 +3094,16 @@
<listitem>
<para>
- Ignore the statement: Ignore it and exit.
+ An <quote>ignore</quote> rule matched: Ignore the
+ statement and exit.
</para>
</listitem>
<listitem>
<para>
- Execute the statement: Do not execute it immediately;
- defer the decision; proceed to the next step.
+ A <quote>do</quote> rule matched: Do not execute the
+ statement immediately; defer the decision; proceed to
+ the next step.
</para>
</listitem>
@@ -3154,8 +3156,10 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Proceed to the next step. Only
- tables that are to be updated are compared to the rules
+ <emphasis>Yes</emphasis>: Proceed to the next step and
+ begin evaluating the table rules in the order shown (first
+ the non-wild rules, and then the wild rules). Only tables
+ that are to be updated are compared to the rules
(<literal>INSERT INTO sales SELECT * FROM
prices</literal>: only <literal>sales</literal> is
compared to the rules). If several tables are to be
@@ -3354,7 +3358,8 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: There were <quote>do</quote>
+ rules but no match. Ignore the query and exit.
</para>
</listitem>
--- 1.59/refman-4.1/mysql-database-administration.xml 2005-08-31 09:24:13 -05:00
+++ 1.60/refman-4.1/mysql-database-administration.xml 2005-09-02 17:49:25 -05:00
@@ -20959,13 +20959,13 @@
</para>
<para>
- The rules for logging or ignoring updates to the binary log are
- evaluated according to the following rules. Observe that there
- is an exception for
- <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP</literal>
- <literal>DATABASE</literal> statements. In those cases, the
- database being <emphasis>created, altered, or dropped</emphasis>
- replaces the current database in the rules below.
+ The server evaluates the options for logging or ignoring updates
+ to the binary log according to the following rules. Observe that
+ there is an exception for
+ <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
+ DATABASE</literal> statements. In those cases, the database
+ being <emphasis>created, altered, or dropped</emphasis> replaces
+ the current database in the rules below.
</para>
<orderedlist>
--- 1.26/refman-4.1/replication.xml 2005-09-02 13:22:48 -05:00
+++ 1.27/refman-4.1/replication.xml 2005-09-02 17:49:25 -05:00
@@ -1168,15 +1168,15 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <command><literal>InnoDB</literal> Hot
- Backup</command> tool, which takes a consistent snapshot
- without acquiring any locks on the master server, and records
- the log name and offset corresponding to the snapshot to be
- later used on the slave. <command>Hot Backup</command> is an
- additional non-free (commercial) tool that is not included in
- the standard MySQL distribution. See the
- <command><literal>InnoDB</literal> Hot Backup</command> home
- page at <ulink url="http://www.innodb.com/manual.php"/> for
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
detailed information.
</para>
@@ -1412,7 +1412,7 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in the slave's
+ value for the slave, you get the following error in the slave's
error log:
</para>
@@ -1431,9 +1431,9 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. Do <emphasis>not</emphasis> remove or edit these files
- unless you know exactly what you are doing and fully understand
- the implications. Even in that case, it is preferred that you use
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
the <literal>CHANGE MASTER TO</literal> statement.
</para>
@@ -1699,9 +1699,9 @@
The <literal>FOREIGN_KEY_CHECKS</literal> variable is
replicated as of MySQL 4.0.14. The
<literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
- <literal>SQL_AUTO_IS_NULL</literal>,
- and <literal>TABLE_TYPE</literal> (same as
- <literal>STORAGE_ENGINE</literal>) variables are not
+ <literal>SQL_AUTO_IS_NULL</literal>, and
+ <literal>TABLE_TYPE</literal> (same as
+ <literal>STORAGE_ENGINE</literal>) variables are not
replicated in MySQL 4.1 or earlier versions.
</para>
</listitem>
@@ -1841,8 +1841,8 @@
<listitem>
<para>
- Starting from MySQL 4.1.11, there is a global system variable
- <literal>slave_transaction_retries</literal>: If the
+ Starting from MySQL 4.1.11, there is a global system variable
+ <literal>slave_transaction_retries</literal>: If the
replication slave SQL thread fails to execute a transaction
because of an <literal>InnoDB</literal> deadlock or exceeded
InnoDB's <literal>innodb_lock_wait_timeout</literal> or
@@ -1851,8 +1851,8 @@
<literal>TransactionInactiveTimeout</literal>, it
automatically retries
<literal>slave_transaction_retries</literal> times before
- stopping with an error. The default value is 0 in MySQL 4.1.
- Starting from MySQL 4.1.11, the total count of retries can be
+ stopping with an error. The default value is 0 in MySQL 4.1.
+ Starting from MySQL 4.1.11, the total count of retries can be
seen in <literal>SHOW STATUS</literal>; see
<xref linkend="server-status-variables"/>.
</para>
@@ -1883,7 +1883,7 @@
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (This is in general not a good
+ of the query optimizer. (This is in general not a good
practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
@@ -1891,12 +1891,12 @@
<listitem>
<para>
- If on the master a <literal>LOAD DATA INFILE</literal> is
- interrupted (for example, by a integrity constraint violation
- or a killed connection), the slave skips this <literal>LOAD
- DATA INFILE</literal> entirely. This means that if this
- command permanently inserted or updated table records before
- being interrupted, these modifications are
+ If on the master a <literal>LOAD DATA INFILE</literal> is
+ interrupted (for example, by a integrity constraint violation
+ or a killed connection), the slave skips this <literal>LOAD
+ DATA INFILE</literal> entirely. This means that if this
+ command permanently inserted or updated table records before
+ being interrupted, these modifications are
<emphasis>not</emphasis> replicated to the slave.
</para>
</listitem>
@@ -1932,7 +1932,7 @@
<listitem>
<para>
- MySQL 4.1 and earlier support only replication scenarios
+ MySQL 4.1 and earlier support only replication scenarios
involving one master and many slaves.
</para>
</listitem>
@@ -2030,18 +2030,18 @@
</programlisting>
<para>
- Server IDs are encoded in binary log events, so server A knows
- when an event that it reads was originally created by itself
- and does not execute the event (unless server A was started
- with the <option>--replicate-same-server-id</option> option,
- which is meaningful only in rare cases). Thus, there are no
- infinite loops. This type of circular setup works only if
- you perform no conflicting updates between the tables. In
- other words, if you insert data in both A and C, you should
- never insert a row in A that may have a key that conflicts
- with a row inserted in C. You should also not update the same
- rows on two servers if the order in which the updates are
- applied is significant.
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if you
+ perform no conflicting updates between the tables. In other
+ words, if you insert data in both A and C, you should never
+ insert a row in A that may have a key that conflicts with a
+ row inserted in C. You should also not update the same rows on
+ two servers if the order in which the updates are applied is
+ significant.
</para>
</listitem>
@@ -2759,7 +2759,7 @@
or not it should be replicated (for example, if you are using
multiple-table <literal>DELETE</literal> or multiple-table
<literal>UPDATE</literal> statements that go across multiple
- databases). It is also faster to check only the default
+ databases). It is also faster to check only the default
database rather than all databases if there is no need.
</para>
</listitem>
@@ -3141,9 +3141,9 @@
</itemizedlist>
<para>
- The <option>--replicate-*</option> rules are evaluated as follows
- to determine whether a statement is executed by the slave or
- ignored:
+ The slave server evaluates the <option>--replicate-*</option>
+ rules as follows to determine whether to execute or ignore a
+ statement:
</para>
<orderedlist>
@@ -3169,14 +3169,16 @@
<listitem>
<para>
- Ignore the statement: Ignore it and exit.
+ An <quote>ignore</quote> rule matched: Ignore the
+ statement and exit.
</para>
</listitem>
<listitem>
<para>
- Execute the statement: Do not execute it immediately;
- defer the decision; proceed to the next step.
+ A <quote>do</quote> rule matched: Do not execute the
+ statement immediately; defer the decision; proceed to
+ the next step.
</para>
</listitem>
@@ -3207,8 +3209,10 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Proceed to the next step. Only
- tables that are to be updated are compared to the rules
+ <emphasis>Yes</emphasis>: Proceed to the next step and
+ begin evaluating the table rules in the order shown (first
+ the non-wild rules, and then the wild rules). Only tables
+ that are to be updated are compared to the rules
(<literal>INSERT INTO sales SELECT * FROM
prices</literal>: only <literal>sales</literal> is
compared to the rules). If several tables are to be
@@ -3407,7 +3411,8 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: There were <quote>do</quote>
+ rules but no match. Ignore the query and exit.
</para>
</listitem>
@@ -3809,8 +3814,8 @@
just described are able to take advantage of a master/slave
configuration, even one involving multiple slaves. The code is a
lot easier to maintain, and adding troubleshooting options is
- trivial. You need modify only one or two functions; for example,
- to log how long each statement took, or which statement among
+ trivial. You need modify only one or two functions; for example,
+ to log how long each statement took, or which statement among
those issued gave you an error.
</para>
--- 1.70/refman/mysql-database-administration.xml 2005-08-31 09:24:15 -05:00
+++ 1.71/refman/mysql-database-administration.xml 2005-09-02 17:49:26 -05:00
@@ -23413,12 +23413,13 @@
</para>
<para>
- The rules for logging or ignoring updates to the binary log are
- evaluated according to the following rules. Observe that there
- is an exception for <literal>CREATE/ALTER/DROP
+ The server evaluates the options for logging or ignoring updates
+ to the binary log according to the following rules. Observe that
+ there is an exception for
+ <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
DATABASE</literal> statements. In those cases, the database
- being <emphasis>created/altered/dropped</emphasis> replace the
- current database in the rules below.
+ being <emphasis>created, altered, or dropped</emphasis> replaces
+ the current database in the rules below.
</para>
<orderedlist>
--- 1.28/refman/replication.xml 2005-09-02 13:22:48 -05:00
+++ 1.29/refman/replication.xml 2005-09-02 17:49:27 -05:00
@@ -1257,15 +1257,15 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <command><literal>InnoDB</literal> Hot
- Backup</command> tool, which takes a consistent snapshot
- without acquiring any locks on the master server, and records
- the log name and offset corresponding to the snapshot to be
- later used on the slave. <command>Hot Backup</command> is an
- additional non-free (commercial) tool that is not included in
- the standard MySQL distribution. See the
- <command><literal>InnoDB</literal> Hot Backup</command> home
- page at <ulink url="http://www.innodb.com/manual.php"/> for
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
detailed information.
</para>
@@ -1501,7 +1501,7 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in the slave's
+ value for the slave, you get the following error in the slave's
error log:
</para>
@@ -1520,9 +1520,9 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. Do <emphasis>not</emphasis> remove or edit these files
- unless you know exactly what you are doing and fully understand
- the implications. Even in that case, it is preferred that you use
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
the <literal>CHANGE MASTER TO</literal> statement.
</para>
@@ -2072,7 +2072,7 @@
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (This is in general not a good
+ of the query optimizer. (This is in general not a good
practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
@@ -2224,18 +2224,18 @@
</programlisting>
<para>
- Server IDs are encoded in binary log events, so server A knows
- when an event that it reads was originally created by itself
- and does not execute the event (unless server A was started
- with the <option>--replicate-same-server-id</option> option,
- which is meaningful only in rare cases). Thus, there are no
- infinite loops. This type of circular setup works only if
- you perform no conflicting updates between the tables. In
- other words, if you insert data in both A and C, you should
- never insert a row in A that may have a key that conflicts
- with a row inserted in C. You should also not update the same
- rows on two servers if the order in which the updates are
- applied is significant.
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if you
+ perform no conflicting updates between the tables. In other
+ words, if you insert data in both A and C, you should never
+ insert a row in A that may have a key that conflicts with a
+ row inserted in C. You should also not update the same rows on
+ two servers if the order in which the updates are applied is
+ significant.
</para>
</listitem>
@@ -2954,7 +2954,7 @@
or not it should be replicated (for example, if you are using
multiple-table <literal>DELETE</literal> or multiple-table
<literal>UPDATE</literal> statements that go across multiple
- databases). It is also faster to check only the default
+ databases). It is also faster to check only the default
database rather than all databases if there is no need.
</para>
</listitem>
@@ -3336,9 +3336,9 @@
</itemizedlist>
<para>
- The <option>--replicate-*</option> rules are evaluated as follows
- to determine whether a statement is executed by the slave or
- ignored:
+ The slave server evaluates the <option>--replicate-*</option>
+ rules as follows to determine whether to execute or ignore a
+ statement:
</para>
<orderedlist>
@@ -3364,14 +3364,16 @@
<listitem>
<para>
- Ignore the statement: Ignore it and exit.
+ An <quote>ignore</quote> rule matched: Ignore the
+ statement and exit.
</para>
</listitem>
<listitem>
<para>
- Execute the statement: Do not execute it immediately;
- defer the decision; proceed to the next step.
+ A <quote>do</quote> rule matched: Do not execute the
+ statement immediately; defer the decision; proceed to
+ the next step.
</para>
</listitem>
@@ -3424,8 +3426,10 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Proceed to the next step. Only
- tables that are to be updated are compared to the rules
+ <emphasis>Yes</emphasis>: Proceed to the next step and
+ begin evaluating the table rules in the order shown (first
+ the non-wild rules, and then the wild rules). Only tables
+ that are to be updated are compared to the rules
(<literal>INSERT INTO sales SELECT * FROM
prices</literal>: only <literal>sales</literal> is
compared to the rules). If several tables are to be
@@ -3624,7 +3628,8 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: There were <quote>do</quote>
+ rules but no match. Ignore the query and exit.
</para>
</listitem>
@@ -4026,8 +4031,8 @@
just described are able to take advantage of a master/slave
configuration, even one involving multiple slaves. The code is a
lot easier to maintain, and adding troubleshooting options is
- trivial. You need modify only one or two functions; for example,
- to log how long each statement took, or which statement among
+ trivial. You need modify only one or two functions; for example,
+ to log how long each statement took, or which statement among
those issued gave you an error.
</para>
--- 1.31/refman-5.0/mysql-database-administration.xml 2005-08-31 11:15:19 -05:00
+++ 1.32/refman-5.0/mysql-database-administration.xml 2005-09-02 17:49:26 -05:00
@@ -22762,10 +22762,10 @@
</para>
<para>
- The rules for logging or ignoring updates to the binary log are
- evaluated according to the following rules. Observe that there
- is an exception for <literal>CREATE DATABASE</literal>,
- <literal>ALTER DATABASE</literal>, and <literal>DROP
+ The server evaluates the options for logging or ignoring updates
+ to the binary log according to the following rules. Observe that
+ there is an exception for
+ <literal>CREATE</literal>/<literal>ALTER</literal>/<literal>DROP
DATABASE</literal> statements. In those cases, the database
being <emphasis>created, altered, or dropped</emphasis> replaces
the current database in the rules below.
--- 1.19/refman-5.0/replication.xml 2005-09-02 13:22:48 -05:00
+++ 1.20/refman-5.0/replication.xml 2005-09-02 17:49:26 -05:00
@@ -1186,15 +1186,15 @@
<para>
If you are using <literal>InnoDB</literal> tables, ideally you
- should use the <command><literal>InnoDB</literal> Hot
- Backup</command> tool, which takes a consistent snapshot
- without acquiring any locks on the master server, and records
- the log name and offset corresponding to the snapshot to be
- later used on the slave. <command>Hot Backup</command> is an
- additional non-free (commercial) tool that is not included in
- the standard MySQL distribution. See the
- <command><literal>InnoDB</literal> Hot Backup</command> home
- page at <ulink url="http://www.innodb.com/manual.php"/> for
+ should use the <command><literal>InnoDB</literal> Hot
+ Backup</command> tool, which takes a consistent snapshot
+ without acquiring any locks on the master server, and records
+ the log name and offset corresponding to the snapshot to be
+ later used on the slave. <command>Hot Backup</command> is an
+ additional non-free (commercial) tool that is not included in
+ the standard MySQL distribution. See the
+ <command><literal>InnoDB</literal> Hot Backup</command> home
+ page at <ulink url="http://www.innodb.com/manual.php"/> for
detailed information.
</para>
@@ -1429,7 +1429,7 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the slave, you get the following error in the slave's
+ value for the slave, you get the following error in the slave's
error log:
</para>
@@ -1448,9 +1448,9 @@
one file named <filename>master.info</filename> and another named
<filename>relay-log.info</filename>. The slave uses these two
files to keep track of how much of the master's binary log it has
- processed. Do <emphasis>not</emphasis> remove or edit these files
- unless you know exactly what you are doing and fully understand
- the implications. Even in that case, it is preferred that you use
+ processed. Do <emphasis>not</emphasis> remove or edit these files
+ unless you know exactly what you are doing and fully understand
+ the implications. Even in that case, it is preferred that you use
the <literal>CHANGE MASTER TO</literal> statement.
</para>
@@ -1891,7 +1891,7 @@
is possible for the data on the master and slave to become
different if a query is designed in such a way that the data
modification is non-deterministic; that is, left to the will
- of the query optimizer. (This is in general not a good
+ of the query optimizer. (This is in general not a good
practice, even outside of replication.) For a detailed
explanation of this issue, see <xref linkend="open-bugs"/>.
</para>
@@ -2043,18 +2043,18 @@
</programlisting>
<para>
- Server IDs are encoded in binary log events, so server A knows
- when an event that it reads was originally created by itself
- and does not execute the event (unless server A was started
- with the <option>--replicate-same-server-id</option> option,
- which is meaningful only in rare cases). Thus, there are no
- infinite loops. This type of circular setup works only if
- you perform no conflicting updates between the tables. In
- other words, if you insert data in both A and C, you should
- never insert a row in A that may have a key that conflicts
- with a row inserted in C. You should also not update the same
- rows on two servers if the order in which the updates are
- applied is significant.
+ Server IDs are encoded in binary log events, so server A knows
+ when an event that it reads was originally created by itself
+ and does not execute the event (unless server A was started
+ with the <option>--replicate-same-server-id</option> option,
+ which is meaningful only in rare cases). Thus, there are no
+ infinite loops. This type of circular setup works only if you
+ perform no conflicting updates between the tables. In other
+ words, if you insert data in both A and C, you should never
+ insert a row in A that may have a key that conflicts with a
+ row inserted in C. You should also not update the same rows on
+ two servers if the order in which the updates are applied is
+ significant.
</para>
</listitem>
@@ -3057,9 +3057,9 @@
</itemizedlist>
<para>
- The <option>--replicate-*</option> rules are evaluated as follows
- to determine whether a statement is executed by the slave or
- ignored:
+ The slave server evaluates the <option>--replicate-*</option>
+ rules as follows to determine whether to execute or ignore a
+ statement:
</para>
<orderedlist>
@@ -3085,14 +3085,16 @@
<listitem>
<para>
- Ignore the statement: Ignore it and exit.
+ An <quote>ignore</quote> rule matched: Ignore the
+ statement and exit.
</para>
</listitem>
<listitem>
<para>
- Execute the statement: Do not execute it immediately;
- defer the decision; proceed to the next step.
+ A <quote>do</quote> rule matched: Do not execute the
+ statement immediately; defer the decision; proceed to
+ the next step.
</para>
</listitem>
@@ -3145,8 +3147,10 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Proceed to the next step. Only
- tables that are to be updated are compared to the rules
+ <emphasis>Yes</emphasis>: Proceed to the next step and
+ begin evaluating the table rules in the order shown (first
+ the non-wild rules, and then the wild rules). Only tables
+ that are to be updated are compared to the rules
(<literal>INSERT INTO sales SELECT * FROM
prices</literal>: only <literal>sales</literal> is
compared to the rules). If several tables are to be
@@ -3345,7 +3349,8 @@
<listitem>
<para>
- <emphasis>Yes</emphasis>: Ignore the query and exit.
+ <emphasis>Yes</emphasis>: There were <quote>do</quote>
+ rules but no match. Ignore the query and exit.
</para>
</listitem>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (paul:1.3463) | paul | 3 Sep |
