Author: paul
Date: 2006-01-29 23:55:04 +0100 (Sun, 29 Jan 2006)
New Revision: 1112
Log:
r6876@frost: paul | 2006-01-29 16:54:02 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/replication.xml
trunk/refman-5.0/replication.xml
trunk/refman-5.1/replication.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6875
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6876
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-4.1/replication.xml 2006-01-29 22:55:04 UTC (rev 1112)
@@ -1380,14 +1380,14 @@
</programlisting>
<para>
- The following table shows the maximum length for the string
- options:
+ The following table shows the maximum allowable length for the
+ string-valued options:
</para>
<informaltable>
<tgroup cols="2">
- <colspec colwidth="40*"/>
<colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
<tbody>
<row>
<entry><literal>MASTER_HOST</literal></entry>
@@ -1430,18 +1430,19 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the master, slaves are not able to connect to it.
+ option for the master, slaves cannot connect to it.
</para>
<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
+ option for the slave, you get the following error in the slave's
error log:
</para>
<programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
</programlisting>
<para>
@@ -1457,21 +1458,24 @@
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.
+ the <literal>CHANGE MASTER TO</literal> statement to change
+ replication parameters. The slave will use the values specified in
+ the statement to update the status files automatically.
</para>
<para>
<emphasis role="bold">Note</emphasis>: The content of
- <filename>master.info</filename> overrides some of the options
- specified on the command line or in <filename>my.cnf</filename>.
- See <xref linkend="replication-options"/>, for more details.
+ <filename>master.info</filename> overrides some of the server
+ options specified on the command line or in
+ <filename>my.cnf</filename>. See
+ <xref linkend="replication-options"/>, for more details.
</para>
<para>
- Once you have a snapshot, you can use it to set up other slaves by
- following the slave portion of the procedure just described. You
- do not need to take another snapshot of the master; you can use
- the same one for each slave.
+ Once you have a snapshot of the master, you can use it to set up
+ other slaves by following the slave portion of the procedure just
+ described. You do not need to take another snapshot of the master;
+ you can use the same one for each slave.
</para>
</section>
@@ -1486,11 +1490,12 @@
</para>
<para>
- <emphasis role="bold">Note</emphasis>: You cannot replicate from a
- master that uses a newer binary log format to a slave that uses an
- older format (for example, from MySQL 4.1 to MySQL 3.23.) This has
- significant consequences for upgrading servers in a replication
- setup, as described in <xref linkend="replication-upgrade"/>.
+ <emphasis role="bold">Note</emphasis>: You
+ <emphasis>cannot</emphasis> replicate from a master that uses a
+ newer binary log format to a slave that uses an older format (for
+ example, from MySQL 4.1 to MySQL 3.23.) This has significant
+ consequences for upgrading servers in a replication setup, as
+ described in <xref linkend="replication-upgrade"/>.
</para>
<para>
@@ -1659,10 +1664,9 @@
<listitem>
<para>
- Replication is done correctly with
- <literal>AUTO_INCREMENT</literal>,
+ Replication of <literal>AUTO_INCREMENT</literal>,
<literal>LAST_INSERT_ID()</literal>, and
- <literal>TIMESTAMP</literal> values.
+ <literal>TIMESTAMP</literal> values is done correctly.
</para>
</listitem>
@@ -1670,7 +1674,7 @@
<para>
The <literal>USER()</literal>, <literal>UUID()</literal>, and
<literal>LOAD_FILE()</literal> functions are replicated
- without changes and thus do not work reliably on the slave.
+ without change and thus do not work reliably on the slave.
This is also true for <literal>CONNECTION_ID()</literal> in
slave versions older than 4.1.1. The
<emphasis role="bold">new</emphasis>
@@ -1691,15 +1695,16 @@
<para>
<emphasis>The following restriction applies to statement-based
replication only, not to row-based replication.</emphasis> The
- functions handling user-level locks:
<literal>GET_LOCK()</literal>,
<literal>RELEASE_LOCK()</literal>,
- <literal>IS_FREE_LOCK()</literal>,
- <literal>IS_USED_LOCK()</literal> are replicated without the
- slave knowing the concurrency context on master; so these
- functions should not be used to insert into a master's table
- as the content on slave would differ (i.e. do not do
- <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+ <literal>IS_FREE_LOCK()</literal>, and
+ <literal>IS_USED_LOCK()</literal> functions that handle
+ user-level locks are replicated without the slave knowing the
+ concurrency context on master. Therefore, these functions
+ should not be used to insert into a master's table because the
+ content on the slave would differ. (For example, do not issue
+ a statement such as <literal>INSERT INTO mytable
+ VALUES(GET_LOCK(...))</literal>.)
</para>
</listitem>
@@ -1709,30 +1714,30 @@
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
- replicated in MySQL 4.1 or earlier versions.
+ <literal>storage_engine</literal> (also known as
+ <literal>table_type</literal>) variables are not replicated in
+ MySQL 4.1 or earlier versions.
</para>
</listitem>
<listitem>
<para>
The following applies to replication between MySQL servers
- using different character sets:
+ that use different character sets:
</para>
<orderedlist>
<listitem>
<para>
- You must <emphasis role="bold">always</emphasis> use the
- same <emphasis role="bold">global</emphasis> character set
- and collation (<option>--character-set-server</option>,
- <option>--collation-server</option>) on the master and the
- slave. Otherwise, you may get duplicate-key errors on the
- slave, because a key that is regarded as unique in the
- master's character set may not be unique in the slave's
- character set.
+ You must <emphasis>always</emphasis> use the same
+ <emphasis>global</emphasis> character set and collation on
+ the master and the slave. (These are controlled by the
+ <option>--character-set-server</option> and
+ <option>--collation-server</option> options.) Otherwise,
+ you may get duplicate-key errors on the slave, because a
+ key that is unique in the master character set might not
+ be unique in the slave character set.
</para>
</listitem>
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-5.0/replication.xml 2006-01-29 22:55:04 UTC (rev 1112)
@@ -1311,14 +1311,14 @@
</programlisting>
<para>
- The following table shows the maximum length for the string
- options:
+ The following table shows the maximum allowable length for the
+ string-valued options:
</para>
<informaltable>
<tgroup cols="2">
- <colspec colwidth="40*"/>
<colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
<tbody>
<row>
<entry><literal>MASTER_HOST</literal></entry>
@@ -1361,18 +1361,19 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the master, slaves are not able to connect to it.
+ option for the master, slaves cannot connect to it.
</para>
<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
+ option for the slave, you get the following error in the slave's
error log:
</para>
<programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
</programlisting>
<para>
@@ -1388,21 +1389,24 @@
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.
+ the <literal>CHANGE MASTER TO</literal> statement to change
+ replication parameters. The slave will use the values specified in
+ the statement to update the status files automatically.
</para>
<para>
<emphasis role="bold">Note</emphasis>: The content of
- <filename>master.info</filename> overrides some of the options
- specified on the command line or in <filename>my.cnf</filename>.
- See <xref linkend="replication-options"/>, for more details.
+ <filename>master.info</filename> overrides some of the server
+ options specified on the command line or in
+ <filename>my.cnf</filename>. See
+ <xref linkend="replication-options"/>, for more details.
</para>
<para>
- Once you have a snapshot, you can use it to set up other slaves by
- following the slave portion of the procedure just described. You
- do not need to take another snapshot of the master; you can use
- the same one for each slave.
+ Once you have a snapshot of the master, you can use it to set up
+ other slaves by following the slave portion of the procedure just
+ described. You do not need to take another snapshot of the master;
+ you can use the same one for each slave.
</para>
</section>
@@ -1420,14 +1424,6 @@
</para>
<para>
- <emphasis role="bold">Note</emphasis>: You cannot replicate from a
- master that uses a newer binary log format to a slave that uses an
- older format (for example, from MySQL 5.0 to MySQL 4.1.) This has
- significant consequences for upgrading servers in a replication
- setup, as described in <xref linkend="replication-upgrade"/>.
- </para>
-
- <para>
We recommend using the most recent MySQL version available because
replication capabilities are continually being improved. We also
recommend using the same version for both the master and the
@@ -1440,6 +1436,15 @@
</para>
<para>
+ <emphasis role="bold">Note</emphasis>: You
+ <emphasis>cannot</emphasis> replicate from a master that uses a
+ newer binary log format to a slave that uses an older format (for
+ example, from MySQL 5.0 to MySQL 4.1.) This has significant
+ implications for upgrading replication servers, as described in
+ <xref linkend="replication-upgrade"/>.
+ </para>
+
+ <para>
The preceding information pertains to replication compatibility at
the protocol level. However, there can be other constraints, such
as SQL-level compatibility issues. For example, a ¤t-series;
@@ -1467,8 +1472,8 @@
<para>
This section applies to upgrading replication from MySQL 3.23,
- 4.0, or 4.1 to ¤t-series;. A 4.0 server should be 4.0.3 or
- newer.
+ 4.0, or 4.1 to MySQL ¤t-series;. A 4.0 server should be
+ 4.0.3 or newer.
</para>
<para>
@@ -1497,10 +1502,10 @@
<para>
In other words, there are no measures to take when upgrading to
- ¤t-series;, except that the slaves must be
+ MySQL ¤t-series;, except that the slaves must be MySQL
¤t-series; before you can upgrade the master to
¤t-series;. Note that downgrading from ¤t-series; to
- older versions does not work so simply: you must ensure that any
+ older versions does not work so simply: You must ensure that any
¤t-series; binary logs or relay logs have been fully
processed, so that you can remove them before proceeding with
the downgrade.
@@ -1608,10 +1613,9 @@
<listitem>
<para>
- Replication is done correctly with
- <literal>AUTO_INCREMENT</literal>,
+ Replication of <literal>AUTO_INCREMENT</literal>,
<literal>LAST_INSERT_ID()</literal>, and
- <literal>TIMESTAMP</literal> values.
+ <literal>TIMESTAMP</literal> values is done correctly.
</para>
</listitem>
@@ -1619,7 +1623,7 @@
<para>
The <literal>USER()</literal>, <literal>UUID()</literal>, and
<literal>LOAD_FILE()</literal> functions are replicated
- without changes and thus do not work reliably on the slave.
+ without change and thus do not work reliably on the slave.
</para>
</listitem>
@@ -1627,15 +1631,16 @@
<para>
<emphasis>The following restriction applies to statement-based
replication only, not to row-based replication.</emphasis> The
- functions handling user-level locks:
<literal>GET_LOCK()</literal>,
<literal>RELEASE_LOCK()</literal>,
- <literal>IS_FREE_LOCK()</literal>,
- <literal>IS_USED_LOCK()</literal> are replicated without the
- slave knowing the concurrency context on master; so these
- functions should not be used to insert into a master's table
- as the content on slave would differ (i.e. do not do
- <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+ <literal>IS_FREE_LOCK()</literal>, and
+ <literal>IS_USED_LOCK()</literal> functions that handle
+ user-level locks are replicated without the slave knowing the
+ concurrency context on master. Therefore, these functions
+ should not be used to insert into a master's table because the
+ content on the slave would differ. (For example, do not issue
+ a statement such as <literal>INSERT INTO mytable
+ VALUES(GET_LOCK(...))</literal>.)
</para>
</listitem>
@@ -1645,10 +1650,10 @@
<literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
and <literal>SQL_AUTO_IS_NULL</literal> variables are all
replicated in MySQL ¤t-series;. The
- <literal>TABLE_TYPE</literal>, also known as
- <literal>STORAGE_ENGINE</literal> variable is not yet
- replicated, which is a good thing for replication between
- different storage engines.
+ <literal>storage_engine</literal> system variable (also known
+ as <literal>table_type</literal>) is not yet replicated, which
+ is a good thing for replication between different storage
+ engines.
</para>
</listitem>
@@ -1665,21 +1670,21 @@
<listitem>
<para>
The following applies to replication between MySQL servers
- using different character sets:
+ that use different character sets:
</para>
<orderedlist>
<listitem>
<para>
- You must <emphasis role="bold">always</emphasis> use the
- same <emphasis role="bold">global</emphasis> character set
- and collation (<option>--character-set-server</option>,
- <option>--collation-server</option>) on the master and the
- slave. Otherwise, you may get duplicate-key errors on the
- slave, because a key that is regarded as unique in the
- master's character set may not be unique in the slave's
- character set.
+ You must <emphasis>always</emphasis> use the same
+ <emphasis>global</emphasis> character set and collation on
+ the master and the slave. (These are controlled by the
+ <option>--character-set-server</option> and
+ <option>--collation-server</option> options.) Otherwise,
+ you may get duplicate-key errors on the slave, because a
+ key that is unique in the master character set might not
+ be unique in the slave character set.
</para>
</listitem>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-29 22:54:41 UTC (rev 1111)
+++ trunk/refman-5.1/replication.xml 2006-01-29 22:55:04 UTC (rev 1112)
@@ -1485,14 +1485,14 @@
</programlisting>
<para>
- The following table shows the maximum length for the string
- options:
+ The following table shows the maximum allowable length for the
+ string-valued options:
</para>
<informaltable>
<tgroup cols="2">
- <colspec colwidth="40*"/>
<colspec colwidth="20*"/>
+ <colspec colwidth="20*"/>
<tbody>
<row>
<entry><literal>MASTER_HOST</literal></entry>
@@ -1535,18 +1535,19 @@
<para>
If you have forgotten to set the <literal>server-id</literal>
- value for the master, slaves are not able to connect to it.
+ option for the master, slaves cannot connect to it.
</para>
<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
+ option for the slave, you get the following error in the slave's
error log:
</para>
<programlisting>
-Warning: You should set server-id to a non-0 value if master_host is set;
-we will force server id to 2, but this MySQL server will not act as a slave.
+Warning: You should set server-id to a non-0 value if master_host
+is set; we will force server id to 2, but this MySQL server will
+not act as a slave.
</programlisting>
<para>
@@ -1562,21 +1563,24 @@
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.
+ the <literal>CHANGE MASTER TO</literal> statement to change
+ replication parameters. The slave will use the values specified in
+ the statement to update the status files automatically.
</para>
<para>
<emphasis role="bold">Note</emphasis>: The content of
- <filename>master.info</filename> overrides some of the options
- specified on the command line or in <filename>my.cnf</filename>.
- See <xref linkend="replication-options"/>, for more details.
+ <filename>master.info</filename> overrides some of the server
+ options specified on the command line or in
+ <filename>my.cnf</filename>. See
+ <xref linkend="replication-options"/>, for more details.
</para>
<para>
- Once you have a snapshot, you can use it to set up other slaves by
- following the slave portion of the procedure just described. You
- do not need to take another snapshot of the master; you can use
- the same one for each slave.
+ Once you have a snapshot of the master, you can use it to set up
+ other slaves by following the slave portion of the procedure just
+ described. You do not need to take another snapshot of the master;
+ you can use the same one for each slave.
</para>
</section>
@@ -1593,14 +1597,6 @@
</para>
<para>
- <emphasis role="bold">Note</emphasis>: You cannot replicate from a
- master that uses a newer binary log format to a slave that uses an
- older format (for example, from MySQL 5.0 to MySQL 4.1.) This has
- significant consequences for upgrading servers in a replication
- setup, as described in <xref linkend="replication-upgrade"/>.
- </para>
-
- <para>
We recommend using the most recent MySQL version available because
replication capabilities are continually being improved. We also
recommend using the same version for both the master and the
@@ -1613,6 +1609,15 @@
</para>
<para>
+ <emphasis role="bold">Note</emphasis>: You
+ <emphasis>cannot</emphasis> replicate from a master that uses a
+ newer binary log format to a slave that uses an older format (for
+ example, from MySQL 5.0 to MySQL 4.1.) This has significant
+ implications for upgrading replication servers, as described in
+ <xref linkend="replication-upgrade"/>.
+ </para>
+
+ <para>
The preceding information pertains to replication compatibility at
the protocol level. However, there can be other constraints, such
as SQL-level compatibility issues. For example, a ¤t-series;
@@ -1640,8 +1645,8 @@
<para>
This section applies to upgrading replication from MySQL 3.23,
- 4.0, or 4.1 to ¤t-series;. A 4.0 server should be 4.0.3 or
- newer.
+ 4.0, or 4.1 to MySQL ¤t-series;. A 4.0 server should be
+ 4.0.3 or newer.
</para>
<para>
@@ -1670,20 +1675,20 @@
<para>
In other words, there are no measures to take when upgrading to
- ¤t-series;, except that the slaves must be
+ MySQL ¤t-series;, except that the slaves must be MySQL
¤t-series; before you can upgrade the master to
¤t-series;. Note that downgrading from ¤t-series; to
- older versions does not work so simply: you must ensure that any
+ older versions does not work so simply: You must ensure that any
¤t-series; binary logs or relay logs have been fully
processed, so that you can remove them before proceeding with
the downgrade.
</para>
<para>
- Note that downgrading a replication setup to a previous version
- cannot be done once you've switched from statement-based to
- row-based replication, and after the first row-based statement
- has been written to the binlog. See
+ Downgrading a replication setup to a previous version cannot be
+ done once you've switched from statement-based to row-based
+ replication, and after the first row-based statement has been
+ written to the binlog. See
<xref linkend="replication-row-based"/>.
</para>
@@ -1766,10 +1771,9 @@
<listitem>
<para>
- Replication is done correctly with
- <literal>AUTO_INCREMENT</literal>,
+ Replication of <literal>AUTO_INCREMENT</literal>,
<literal>LAST_INSERT_ID()</literal>, and
- <literal>TIMESTAMP</literal> values.
+ <literal>TIMESTAMP</literal> values is done correctly.
</para>
</listitem>
@@ -1777,7 +1781,7 @@
<para>
The <literal>USER()</literal>, <literal>UUID()</literal>, and
<literal>LOAD_FILE()</literal> functions are replicated
- without changes and thus do not work reliably on the slave.
+ without change and thus do not work reliably on the slave.
</para>
</listitem>
@@ -1785,15 +1789,16 @@
<para>
<emphasis>The following restriction applies to statement-based
replication only, not to row-based replication.</emphasis> The
- functions handling user-level locks:
<literal>GET_LOCK()</literal>,
<literal>RELEASE_LOCK()</literal>,
- <literal>IS_FREE_LOCK()</literal>,
- <literal>IS_USED_LOCK()</literal> are replicated without the
- slave knowing the concurrency context on master; so these
- functions should not be used to insert into a master's table
- as the content on slave would differ (i.e. do not do
- <literal>INSERT INTO mytable VALUES(GET_LOCK(...))</literal>).
+ <literal>IS_FREE_LOCK()</literal>, and
+ <literal>IS_USED_LOCK()</literal> functions that handle
+ user-level locks are replicated without the slave knowing the
+ concurrency context on master. Therefore, these functions
+ should not be used to insert into a master's table because the
+ content on the slave would differ. (For example, do not issue
+ a statement such as <literal>INSERT INTO mytable
+ VALUES(GET_LOCK(...))</literal>.)
</para>
</listitem>
@@ -1803,10 +1808,10 @@
<literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
and <literal>SQL_AUTO_IS_NULL</literal> variables are all
replicated in MySQL ¤t-series;. The
- <literal>TABLE_TYPE</literal>, also known as
- <literal>STORAGE_ENGINE</literal> variable is not yet
- replicated, which is a good thing for replication between
- different storage engines.
+ <literal>storage_engine</literal> system variable (also known
+ as <literal>table_type</literal>) is not yet replicated, which
+ is a good thing for replication between different storage
+ engines.
</para>
</listitem>
@@ -1821,21 +1826,21 @@
<listitem>
<para>
The following applies to replication between MySQL servers
- using different character sets:
+ that use different character sets:
</para>
<orderedlist>
<listitem>
<para>
- You must <emphasis role="bold">always</emphasis> use the
- same <emphasis role="bold">global</emphasis> character set
- and collation (<option>--character-set-server</option>,
- <option>--collation-server</option>) on the master and the
- slave. Otherwise, you may get duplicate-key errors on the
- slave, because a key that is regarded as unique in the
- master's character set may not be unique in the slave's
- character set.
+ You must <emphasis>always</emphasis> use the same
+ <emphasis>global</emphasis> character set and collation on
+ the master and the slave. (These are controlled by the
+ <option>--character-set-server</option> and
+ <option>--collation-server</option> options.) Otherwise,
+ you may get duplicate-key errors on the slave, because a
+ key that is unique in the master character set might not
+ be unique in the slave character set.
</para>
</listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1112 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 29 Jan |
