Author: paul
Date: 2010-02-04 20:51:04 +0100 (Thu, 04 Feb 2010)
New Revision: 18960
Log:
r49064@frost: paul | 2010-02-04 13:48:18 -0500
Replication general revisions
Modified:
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-5.4/replication-notes.xml
trunk/refman-5.5/replication-notes.xml
trunk/refman-6.0/replication-notes.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:36066
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:49059
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
+ 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:36066
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:49064
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2010-02-04 16:34:12 UTC (rev 18959)
+++ trunk/refman-5.0/replication-notes.xml 2010-02-04 19:51:04 UTC (rev 18960)
Changed blocks: 8, Lines Added: 18, Lines Deleted: 23; 5490 bytes
@@ -181,11 +181,12 @@
it is important to have the same order on the master and
slave, the rows must be ordered before assigning an
<literal>AUTO_INCREMENT</literal> number. Assuming that you
- want to add an <literal>AUTO_INCREMENT</literal> column to
- the table <literal>t1</literal>, the following statements
- produce a new table <literal>t2</literal> identical to
- <literal>t1</literal> but with an
- <literal>AUTO_INCREMENT</literal> column:
+ want to add an <literal>AUTO_INCREMENT</literal> column to a
+ table <literal>t1</literal> that has columns
+ <literal>col1</literal> and <literal>col2</literal>, the
+ following statements produce a new table
+ <literal>t2</literal> identical to <literal>t1</literal> but
+ with an <literal>AUTO_INCREMENT</literal> column:
</para>
<programlisting>
@@ -194,17 +195,11 @@
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</programlisting>
- <para>
- This assumes that the table <literal>t1</literal> has
- columns <literal>col1</literal> and <literal>col2</literal>.
- </para>
-
<important>
<para>
To guarantee the same ordering on both master and slave,
- <emphasis>all</emphasis> columns of <literal>t1</literal>
- must be referenced in the <literal>ORDER BY</literal>
- clause.
+ the <literal>ORDER BY</literal> clause must name
+ <emphasis>all</emphasis> columns of <literal>t1</literal>.
</para>
</important>
</listitem>
@@ -272,8 +267,8 @@
If the master uses MySQL 4.1, you must
<emphasis>always</emphasis> use the same
<emphasis>global</emphasis> character set and collation on
- the master and the slave, regardless of the MySQL version
- running on the slave. (These are controlled by the
+ the master and the slave, regardless of the slave MySQL
+ version. (These are controlled by the
<option role="mysqld">--character-set-server</option> and
<option role="mysqld">--collation-server</option> options.)
Otherwise, you may get duplicate-key errors on the slave,
@@ -314,8 +309,8 @@
you should design your <literal role="stmt">CREATE
TABLE</literal> statements so that tables in those databases
do not implicitly rely on the database default character
- set. A good workaround is to state the character set and
- collation explicitly in <literal role="stmt">CREATE
+ set. A good workaround is to state the table character set
+ and collation explicitly in <literal role="stmt">CREATE
TABLE</literal> statements.
</para>
</listitem>
@@ -1116,7 +1111,7 @@
identifiers on the master that are reserved words in the newer
MySQL version running on the slave. An example of this is using
a table column named <literal>current_user</literal> on a 4.0
- master that is replicating to a 4.1 or higher slave, because
+ master that is replicating to a 4.1 or higher slave because
<literal>CURRENT_USER</literal> is a reserved word beginning in
MySQL 4.1. Replication can fail in such cases with Error 1064
<errortext>You have an error in your SQL syntax...</errortext>,
@@ -1521,7 +1516,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -1560,7 +1555,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -2414,9 +2409,9 @@
updates are concerned. Each server must do the same number
of updates, just as you would have a single server do. The
only difference is that there is a little less lock
- contention, because the updates originating on another
- server are serialized in one slave thread. Even this benefit
- might be offset by network delays.
+ contention because the updates originating on another server
+ are serialized in one slave thread. Even this benefit might
+ be offset by network delays.
</para>
</answer>
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2010-02-04 16:34:12 UTC (rev 18959)
+++ trunk/refman-5.1/replication-notes.xml 2010-02-04 19:51:04 UTC (rev 18960)
Changed blocks: 13, Lines Added: 24, Lines Deleted: 31; 7550 bytes
@@ -145,10 +145,9 @@
<listitem>
<para>
- A stored procedure that uses
+ Prior to MySQL 5.1.12, a stored procedure that uses
<literal role="func">LAST_INSERT_ID()</literal> does not
replicate properly using statement-based binary logging.
- This limitation is lifted in MySQL 5.1.12.
</para>
</listitem>
@@ -175,9 +174,8 @@
<listitem>
<para>
- Table-level <literal>AUTO_INCREMENT</literal> option values
- were not replicated correctly prior to MySQL 5.1.31.
- (Bug#41986)
+ The <literal>AUTO_INCREMENT</literal> table option was not
+ replicated correctly prior to MySQL 5.1.31. (Bug#41986)
</para>
</listitem>
@@ -192,11 +190,12 @@
it is important to have the same order on the master and
slave, the rows must be ordered before assigning an
<literal>AUTO_INCREMENT</literal> number. Assuming that you
- want to add an <literal>AUTO_INCREMENT</literal> column to
- the table <literal>t1</literal>, the following statements
- produce a new table <literal>t2</literal> identical to
- <literal>t1</literal> but with an
- <literal>AUTO_INCREMENT</literal> column:
+ want to add an <literal>AUTO_INCREMENT</literal> column to a
+ table <literal>t1</literal> that has columns
+ <literal>col1</literal> and <literal>col2</literal>, the
+ following statements produce a new table
+ <literal>t2</literal> identical to <literal>t1</literal> but
+ with an <literal>AUTO_INCREMENT</literal> column:
</para>
<programlisting>
@@ -205,17 +204,11 @@
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</programlisting>
- <para>
- This assumes that the table <literal>t1</literal> has
- columns <literal>col1</literal> and <literal>col2</literal>.
- </para>
-
<important>
<para>
To guarantee the same ordering on both master and slave,
- <emphasis>all</emphasis> columns of <literal>t1</literal>
- must be referenced in the <literal>ORDER BY</literal>
- clause.
+ the <literal>ORDER BY</literal> clause must name
+ <emphasis>all</emphasis> columns of <literal>t1</literal>.
</para>
</important>
@@ -279,8 +272,8 @@
If the master uses MySQL 4.1, you must
<emphasis>always</emphasis> use the same
<emphasis>global</emphasis> character set and collation on
- the master and the slave, regardless of the MySQL version
- running on the slave. (These are controlled by the
+ the master and the slave, regardless of the slave MySQL
+ version. (These are controlled by the
<option role="mysqld">--character-set-server</option> and
<option role="mysqld">--collation-server</option> options.)
Otherwise, you may get duplicate-key errors on the slave,
@@ -322,8 +315,8 @@
you should design your <literal role="stmt">CREATE
TABLE</literal> statements so that tables in those databases
do not implicitly rely on the database default character
- set. A good workaround is to state the character set and
- collation explicitly in <literal role="stmt">CREATE
+ set. A good workaround is to state the table character set
+ and collation explicitly in <literal role="stmt">CREATE
TABLE</literal> statements.
</para>
</listitem>
@@ -398,7 +391,7 @@
<para>
<literal role="stmt" condition="create-event">CREATE EVENT IF
NOT EXISTS</literal> is always replicated, whether or not the
- event named in this statement already exists on the master.
+ event named in the statement already exists on the master.
This is true for all MySQL 5.1 releases beginning with MySQL
5.1.6, when this statement was introduced.
</para>
@@ -726,7 +719,7 @@
</programlisting>
The following table definitions would also raise
- Error 1532, because the definition of the extra
+ Error 1532 because the definition of the extra
column on the master appears before the definitions
of the columns common to both versions of the table:
@@ -773,7 +766,7 @@
slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput>
</programlisting>
- The following table definitions fail, because the
+ The following table definitions fail because the
slave's version of the table has additional
columns compared to the master's version, and
the two versions of the table define column
@@ -829,7 +822,7 @@
certain cases, it also possible to replicate from a column
having one data type (on the master) to a column having a
different data type (on the slave); this is sometimes known as
- <firstterm>attribute promotion</firstterm>, because the data
+ <firstterm>attribute promotion</firstterm> because the data
type of the master's version of the column is promoted to
a type that is the same size or larger on the slave.
</para>
@@ -2137,7 +2130,7 @@
identifiers on the master that are reserved words in the newer
MySQL version running on the slave. An example of this is using
a table column named <literal>current_user</literal> on a 4.0
- master that is replicating to a 4.1 or higher slave, because
+ master that is replicating to a 4.1 or higher slave because
<literal>CURRENT_USER</literal> is a reserved word beginning in
MySQL 4.1. Replication can fail in such cases with Error 1064
<errortext>You have an error in your SQL syntax...</errortext>,
@@ -2643,7 +2636,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -3567,9 +3560,9 @@
updates are concerned. Each server must do the same number
of updates, just as you would have a single server do. The
only difference is that there is a little less lock
- contention, because the updates originating on another
- server are serialized in one slave thread. Even this benefit
- might be offset by network delays.
+ contention because the updates originating on another server
+ are serialized in one slave thread. Even this benefit might
+ be offset by network delays.
</para>
</answer>
Modified: trunk/refman-5.4/replication-notes.xml
===================================================================
--- trunk/refman-5.4/replication-notes.xml 2010-02-04 16:34:12 UTC (rev 18959)
+++ trunk/refman-5.4/replication-notes.xml 2010-02-04 19:51:04 UTC (rev 18960)
Changed blocks: 11, Lines Added: 21, Lines Deleted: 26; 6671 bytes
@@ -164,11 +164,12 @@
it is important to have the same order on the master and
slave, the rows must be ordered before assigning an
<literal>AUTO_INCREMENT</literal> number. Assuming that you
- want to add an <literal>AUTO_INCREMENT</literal> column to
- the table <literal>t1</literal>, the following statements
- produce a new table <literal>t2</literal> identical to
- <literal>t1</literal> but with an
- <literal>AUTO_INCREMENT</literal> column:
+ want to add an <literal>AUTO_INCREMENT</literal> column to a
+ table <literal>t1</literal> that has columns
+ <literal>col1</literal> and <literal>col2</literal>, the
+ following statements produce a new table
+ <literal>t2</literal> identical to <literal>t1</literal> but
+ with an <literal>AUTO_INCREMENT</literal> column:
</para>
<programlisting>
@@ -177,17 +178,11 @@
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</programlisting>
- <para>
- This assumes that the table <literal>t1</literal> has
- columns <literal>col1</literal> and <literal>col2</literal>.
- </para>
-
<important>
<para>
To guarantee the same ordering on both master and slave,
- <emphasis>all</emphasis> columns of <literal>t1</literal>
- must be referenced in the <literal>ORDER BY</literal>
- clause.
+ the <literal>ORDER BY</literal> clause must name
+ <emphasis>all</emphasis> columns of <literal>t1</literal>.
</para>
</important>
@@ -251,8 +246,8 @@
If the master uses MySQL 4.1, you must
<emphasis>always</emphasis> use the same
<emphasis>global</emphasis> character set and collation on
- the master and the slave, regardless of the MySQL version
- running on the slave. (These are controlled by the
+ the master and the slave, regardless of the slave MySQL
+ version. (These are controlled by the
<option role="mysqld">--character-set-server</option> and
<option role="mysqld">--collation-server</option> options.)
Otherwise, you may get duplicate-key errors on the slave,
@@ -294,8 +289,8 @@
you should design your <literal role="stmt">CREATE
TABLE</literal> statements so that tables in those databases
do not implicitly rely on the database default character
- set. A good workaround is to state the character set and
- collation explicitly in <literal role="stmt">CREATE
+ set. A good workaround is to state the table character set
+ and collation explicitly in <literal role="stmt">CREATE
TABLE</literal> statements.
</para>
</listitem>
@@ -370,7 +365,7 @@
<para>
<literal role="stmt" condition="create-event">CREATE EVENT IF
NOT EXISTS</literal> is always replicated in MySQL
- ¤t-series;, whether or not the event named in this
+ ¤t-series;, whether or not the event named in the
statement already exists on the master.
</para>
@@ -696,7 +691,7 @@
</programlisting>
The following table definitions would also raise
- Error 1532, because the definition of the extra
+ Error 1532 because the definition of the extra
column on the master appears before the definitions
of the columns common to both versions of the table:
@@ -743,7 +738,7 @@
slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput>
</programlisting>
- The following table definitions fail, because the
+ The following table definitions fail because the
slave's version of the table has additional
columns compared to the master's version, and
the two versions of the table define column
@@ -798,7 +793,7 @@
certain cases, it also possible to replicate from a column
having one data type (on the master) to a column having a
different data type (on the slave); this is sometimes known as
- <firstterm>attribute promotion</firstterm>, because the data
+ <firstterm>attribute promotion</firstterm> because the data
type of the master's version of the column is promoted to
a type that is the same size or larger on the slave.
</para>
@@ -2035,7 +2030,7 @@
identifiers on the master that are reserved words in the newer
MySQL version running on the slave. An example of this is using
a table column named <literal>current_user</literal> on a 4.0
- master that is replicating to a 4.1 or higher slave, because
+ master that is replicating to a 4.1 or higher slave because
<literal>CURRENT_USER</literal> is a reserved word beginning in
MySQL 4.1. Replication can fail in such cases with Error 1064
<errortext>You have an error in your SQL syntax...</errortext>,
@@ -2534,7 +2529,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -3448,9 +3443,9 @@
updates are concerned. Each server must do the same number
of updates, just as you would have a single server do. The
only difference is that there is a little less lock
- contention, because the updates originating on another
- server are serialized in one slave thread. Even this benefit
- might be offset by network delays.
+ contention because the updates originating on another server
+ are serialized in one slave thread. Even this benefit might
+ be offset by network delays.
</para>
</answer>
Modified: trunk/refman-5.5/replication-notes.xml
===================================================================
--- trunk/refman-5.5/replication-notes.xml 2010-02-04 16:34:12 UTC (rev 18959)
+++ trunk/refman-5.5/replication-notes.xml 2010-02-04 19:51:04 UTC (rev 18960)
Changed blocks: 11, Lines Added: 21, Lines Deleted: 26; 6671 bytes
@@ -164,11 +164,12 @@
it is important to have the same order on the master and
slave, the rows must be ordered before assigning an
<literal>AUTO_INCREMENT</literal> number. Assuming that you
- want to add an <literal>AUTO_INCREMENT</literal> column to
- the table <literal>t1</literal>, the following statements
- produce a new table <literal>t2</literal> identical to
- <literal>t1</literal> but with an
- <literal>AUTO_INCREMENT</literal> column:
+ want to add an <literal>AUTO_INCREMENT</literal> column to a
+ table <literal>t1</literal> that has columns
+ <literal>col1</literal> and <literal>col2</literal>, the
+ following statements produce a new table
+ <literal>t2</literal> identical to <literal>t1</literal> but
+ with an <literal>AUTO_INCREMENT</literal> column:
</para>
<programlisting>
@@ -177,17 +178,11 @@
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</programlisting>
- <para>
- This assumes that the table <literal>t1</literal> has
- columns <literal>col1</literal> and <literal>col2</literal>.
- </para>
-
<important>
<para>
To guarantee the same ordering on both master and slave,
- <emphasis>all</emphasis> columns of <literal>t1</literal>
- must be referenced in the <literal>ORDER BY</literal>
- clause.
+ the <literal>ORDER BY</literal> clause must name
+ <emphasis>all</emphasis> columns of <literal>t1</literal>.
</para>
</important>
@@ -251,8 +246,8 @@
If the master uses MySQL 4.1, you must
<emphasis>always</emphasis> use the same
<emphasis>global</emphasis> character set and collation on
- the master and the slave, regardless of the MySQL version
- running on the slave. (These are controlled by the
+ the master and the slave, regardless of the slave MySQL
+ version. (These are controlled by the
<option role="mysqld">--character-set-server</option> and
<option role="mysqld">--collation-server</option> options.)
Otherwise, you may get duplicate-key errors on the slave,
@@ -294,8 +289,8 @@
you should design your <literal role="stmt">CREATE
TABLE</literal> statements so that tables in those databases
do not implicitly rely on the database default character
- set. A good workaround is to state the character set and
- collation explicitly in <literal role="stmt">CREATE
+ set. A good workaround is to state the table character set
+ and collation explicitly in <literal role="stmt">CREATE
TABLE</literal> statements.
</para>
</listitem>
@@ -370,7 +365,7 @@
<para>
<literal role="stmt" condition="create-event">CREATE EVENT IF
NOT EXISTS</literal> is always replicated in MySQL
- ¤t-series;, whether or not the event named in this
+ ¤t-series;, whether or not the event named in the
statement already exists on the master.
</para>
@@ -696,7 +691,7 @@
</programlisting>
The following table definitions would also raise
- Error 1532, because the definition of the extra
+ Error 1532 because the definition of the extra
column on the master appears before the definitions
of the columns common to both versions of the table:
@@ -743,7 +738,7 @@
slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput>
</programlisting>
- The following table definitions fail, because the
+ The following table definitions fail because the
slave's version of the table has additional
columns compared to the master's version, and
the two versions of the table define column
@@ -798,7 +793,7 @@
certain cases, it also possible to replicate from a column
having one data type (on the master) to a column having a
different data type (on the slave); this is sometimes known as
- <firstterm>attribute promotion</firstterm>, because the data
+ <firstterm>attribute promotion</firstterm> because the data
type of the master's version of the column is promoted to
a type that is the same size or larger on the slave.
</para>
@@ -2050,7 +2045,7 @@
identifiers on the master that are reserved words in the newer
MySQL version running on the slave. An example of this is using
a table column named <literal>current_user</literal> on a 4.0
- master that is replicating to a 4.1 or higher slave, because
+ master that is replicating to a 4.1 or higher slave because
<literal>CURRENT_USER</literal> is a reserved word beginning in
MySQL 4.1. Replication can fail in such cases with Error 1064
<errortext>You have an error in your SQL syntax...</errortext>,
@@ -2549,7 +2544,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -3461,9 +3456,9 @@
updates are concerned. Each server must do the same number
of updates, just as you would have a single server do. The
only difference is that there is a little less lock
- contention, because the updates originating on another
- server are serialized in one slave thread. Even this benefit
- might be offset by network delays.
+ contention because the updates originating on another server
+ are serialized in one slave thread. Even this benefit might
+ be offset by network delays.
</para>
</answer>
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2010-02-04 16:34:12 UTC (rev 18959)
+++ trunk/refman-6.0/replication-notes.xml 2010-02-04 19:51:04 UTC (rev 18960)
Changed blocks: 11, Lines Added: 22, Lines Deleted: 28; 6699 bytes
@@ -155,9 +155,8 @@
<listitem>
<para>
- Table-level <literal>AUTO_INCREMENT</literal> option values
- were not replicated correctly prior to MySQL 6.0.10.
- (Bug#41986)
+ The <literal>AUTO_INCREMENT</literal> table option was not
+ replicated correctly prior to MySQL 6.0.10. (Bug#41986)
</para>
</listitem>
@@ -172,11 +171,12 @@
it is important to have the same order on the master and
slave, the rows must be ordered before assigning an
<literal>AUTO_INCREMENT</literal> number. Assuming that you
- want to add an <literal>AUTO_INCREMENT</literal> column to
- the table <literal>t1</literal>, the following statements
- produce a new table <literal>t2</literal> identical to
- <literal>t1</literal> but with an
- <literal>AUTO_INCREMENT</literal> column:
+ want to add an <literal>AUTO_INCREMENT</literal> column to a
+ table <literal>t1</literal> that has columns
+ <literal>col1</literal> and <literal>col2</literal>, the
+ following statements produce a new table
+ <literal>t2</literal> identical to <literal>t1</literal> but
+ with an <literal>AUTO_INCREMENT</literal> column:
</para>
<programlisting>
@@ -185,17 +185,11 @@
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</programlisting>
- <para>
- This assumes that the table <literal>t1</literal> has
- columns <literal>col1</literal> and <literal>col2</literal>.
- </para>
-
<important>
<para>
To guarantee the same ordering on both master and slave,
- <emphasis>all</emphasis> columns of <literal>t1</literal>
- must be referenced in the <literal>ORDER BY</literal>
- clause.
+ the <literal>ORDER BY</literal> clause must name
+ <emphasis>all</emphasis> columns of <literal>t1</literal>.
</para>
</important>
@@ -259,8 +253,8 @@
If the master uses MySQL 4.1, you must
<emphasis>always</emphasis> use the same
<emphasis>global</emphasis> character set and collation on
- the master and the slave, regardless of the MySQL version
- running on the slave. (These are controlled by the
+ the master and the slave, regardless of the slave MySQL
+ version. (These are controlled by the
<option role="mysqld">--character-set-server</option> and
<option role="mysqld">--collation-server</option> options.)
Otherwise, you may get duplicate-key errors on the slave,
@@ -302,8 +296,8 @@
you should design your <literal role="stmt">CREATE
TABLE</literal> statements so that tables in those databases
do not implicitly rely on the database default character
- set. A good workaround is to state the character set and
- collation explicitly in <literal role="stmt">CREATE
+ set. A good workaround is to state the table character set
+ and collation explicitly in <literal role="stmt">CREATE
TABLE</literal> statements.
</para>
</listitem>
@@ -626,7 +620,7 @@
</programlisting>
The following table definitions would also raise
- Error 1532, because the definition of the extra
+ Error 1532 because the definition of the extra
column on the master appears before the definitions
of the columns common to both versions of the table:
@@ -673,7 +667,7 @@
slave> <userinput>CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);</userinput>
</programlisting>
- The following table definitions fail, because the
+ The following table definitions fail because the
slave's version of the table has additional
columns compared to the master's version, and
the two versions of the table define column
@@ -728,7 +722,7 @@
certain cases, it also possible to replicate from a column
having one data type (on the master) to a column having a
different data type (on the slave); this is sometimes known as
- <firstterm>attribute promotion</firstterm>, because the data
+ <firstterm>attribute promotion</firstterm> because the data
type of the master's version of the column is promoted to
a type that is the same size or larger on the slave.
</para>
@@ -1929,7 +1923,7 @@
identifiers on the master that are reserved words in the newer
MySQL version running on the slave. An example of this is using
a table column named <literal>current_user</literal> on a 4.0
- master that is replicating to a 4.1 or higher slave, because
+ master that is replicating to a 4.1 or higher slave because
<literal>CURRENT_USER</literal> is a reserved word beginning in
MySQL 4.1. Replication can fail in such cases with Error 1064
<errortext>You have an error in your SQL syntax...</errortext>,
@@ -2440,7 +2434,7 @@
<literal role="stmt" condition="commit">ROLLBACK</literal>.
However, when a second connection updates the nontransactional
table before the first connection's transaction is complete,
- statements can be logged out of order, because the second
+ statements can be logged out of order because the second
connection's update is written immediately after it is
performed, regardless of the state of the transaction being
performed by the first connection.
@@ -3240,9 +3234,9 @@
updates are concerned. Each server must do the same number
of updates, just as you would have a single server do. The
only difference is that there is a little less lock
- contention, because the updates originating on another
- server are serialized in one slave thread. Even this benefit
- might be offset by network delays.
+ contention because the updates originating on another server
+ are serialized in one slave thread. Even this benefit might
+ be offset by network delays.
</para>
</answer>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r18960 - in trunk: . refman-5.0 refman-5.1 refman-5.4 refman-5.5 refman-6.0 | paul.dubois | 4 Feb |
