Author: jstephens
Date: 2008-10-21 00:34:22 +0200 (Tue, 21 Oct 2008)
New Revision: 12107
Log:
Bug #40023/CSC#30326
Part I: Rewrite of replication-compatibility
Modified:
trunk/refman-4.1/replication.xml
trunk/refman-5.0/Makefile.depends
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-6.0/replication-notes.xml
trunk/topic-guides/topics-5.0/Makefile.depends
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/refman-4.1/replication.xml 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 1, Lines Added: 27, Lines Deleted: 15; 3526 bytes
@@ -1185,43 +1185,55 @@
<title>Replication Compatibility Between MySQL Versions</title>
<para>
- The original binary log format was developed in MySQL 3.23. It was
- changed in MySQL 4.0.
+ MySQL supports replication from one major version to the next
+ higher major version. For example, you can replicate from a master
+ running MySQL 4.0 to a slave running MySQL 4.1, from a master
+ running MySQL 4.1 to a slave running MySQL 5.0, and so on.
</para>
<note>
<para>
+ The original binary log format was developed in MySQL 3.23. It
+ was changed in MySQL 4.0.
+ </para>
+
+ <para>
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"/>.
+ format — for example, from MySQL 4.1 to MySQL 3.23. (In
+ general, MySQL does not support replication from newer masters
+ to older slaves.) This also has significant consequences for
+ upgrading servers in a replication setup, as described in
+ <xref linkend="replication-upgrade"/>.
</para>
</note>
<para>
- As far as replication is concerned, the binary log format for any
- MySQL 4.1.x version and any 4.0.x version is identical. However,
- replication from a 4.1 master to a 4.0 slave is unsupported, has
- not been tested thoroughly, and no further development or bug
+ As far as replication is concerned, the binary log format used by
+ all MySQL 4.0 and MySQL 4.1 releases is identical. However,
+ replication from a 4.1 master to a 4.0 slave is unsupported; it
+ has not been tested thoroughly, and no further development or bug
fixing is planned for this master/slave combination. Although the
binary log format is the same for 4.0 and 4.1, there are other
constraints, such as SQL-level compatibility issues. For example,
a 4.1 master cannot replicate to a 4.0 slave if the replicated
statements use SQL features available in 4.1 but not 4.0. In
addition, there are known issues with trying to replicate from a
- 4.0 master to a 5.1 slave (Bug #31240). These and other issues are
- discussed in <xref linkend="replication-features"/>.
+ 4.0 or 4.1 master to a 5.1 slave (Bug #31240).
</para>
<para>
As a general rule, we recommended using recent MySQL versions,
- because replication capabilities are continually being improved.
- We also recommend using the same version for both the master and
- the slave. We recommend upgrading masters and slaves running alpha
- or beta versions to new versions.
+ because replication (and other) capabilities are continually being
+ improved. We also recommend upgrading masters and slaves running
+ alpha or beta releases to GA (production) releases.
</para>
+ <para>
+ For more information on potential replication issues, see
+ <xref linkend="replication-features"/>.
+ </para>
+
</section>
<section id="replication-upgrade">
Modified: trunk/refman-5.0/Makefile.depends
===================================================================
--- trunk/refman-5.0/Makefile.depends 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/refman-5.0/Makefile.depends 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 0; 1058 bytes
@@ -2879,6 +2879,7 @@
../refman-5.0/metadata/sql-syntax-data-definition.idmap \
../refman-5.0/metadata/sql-syntax-server-administration.idmap \
../refman-5.0/metadata/stored-programs-views.idmap \
+ ../refman-5.1/metadata/replication-configuration.idmap \
../refman-common/metadata/bug-reports.idmap
replication-notes.validpure: $(replication_notes_SOURCES)
replication-notes.titles: $(replication_notes_SOURCES)
@@ -2961,6 +2962,7 @@
../refman-5.0/metadata/sql-syntax-replication.idmap \
../refman-5.0/metadata/sql-syntax-server-administration.idmap \
../refman-5.0/metadata/stored-programs-views.idmap \
+ ../refman-5.1/metadata/replication-configuration.idmap \
../refman-common/metadata/bug-reports.idmap
replication.validpure: $(replication_SOURCES)
replication.titles: $(replication_SOURCES)
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/refman-5.0/replication-notes.xml 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 1, Lines Added: 104, Lines Deleted: 36; 6460 bytes
@@ -1071,53 +1071,121 @@
<section id="replication-compatibility">
+
+
<title>Replication Compatibility Between MySQL Versions</title>
-
+
<para>
- The binary log format as implemented in MySQL ¤t-series; is
- considerably different from that used in previous versions. Major
- changes were made in MySQL 5.0.3 (for improvements to handling of
- character sets and <literal>LOAD DATA INFILE</literal>) and 5.0.4
- (for improvements to handling of time zones).
+ MySQL supports replication from one major version to the next
+ higher major version. For example, you can replicate from a master
+ running MySQL 4.1 to a slave running MySQL 5.0, from a master
+ running MySQL 5.0 to a slave running MySQL 5.1, and so on.
</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
- slave. We recommend upgrading masters and slaves running alpha or
- beta versions to new (production) versions. Replication from a
- 5.0.3 master to a 5.0.2 slave will fail; from a 5.0.4 master to a
- 5.0.3 slave will also fail.
+ In some cases, it is also possible to replicate between a master
+ and a slave that is more than one major version newer than the
+ master. However, there are known issues with trying to replicate
+ from a master running MySQL 4.1 or earlier to a slave running
+ MySQL 5.1 or later (Bug #31240). In such cases, you can insert a
+ MySQL server running an intermediate version between the two; for
+ example, rather than replicating directly from a MySQL 4.1 master
+ to a MySQL 5.1 slave, it is possible to replicate from a MySQL 4.1
+ server to a MySQL 5.0 server, and then from the MySQL 5.0 server
+ to a MySQL 5.1 server.
</para>
-
- <para>
- In general (but not always), slaves running MySQL
- ¤t-series;.x may be used with older masters, but not the
- reverse. For more information on potential issues, see
- <xref linkend="replication-features"/>.
- </para>
-
+
<note>
<para>
- 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"/>.
+ We recommend using the most recent release available within a
+ given MySQL major version because replication (and other)
+ capabilities are continually being improved. We also recommend
+ upgrading masters and slaves running alpha or beta releases of a
+ major version of MySQL to GA (production) releases when these
+ become available for that major version.
</para>
</note>
-
+
<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;
- master cannot replicate to a &previous-series; slave if the
- replicated statements use SQL features available in
- ¤t-series; but not in &previous-series;. These and other
- issues are discussed in <xref linkend="replication-features"/>.
+ Replication from newer masters to older slaves may be possible,
+ but is generally not supported. This is due to a number of
+ factors:
</para>
-
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Binary log format changes</title>
+
+ <para>
+ The binary log format can change between major releases.
+ While we attempt to maintain backwards compatiblity, this is
+ not always possible. Major changes were made in MySQL 5.0.3 (for
+ improvements to handling of character sets and <literal>LOAD DATA
+ INFILE</literal>) and 5.0.4 (for improvements to handling of time
+ zones). Because of these changes, replication from a MySQL 5.0.3 or
+ later master to a MySQL 5.0.2 or earlier slave is not supported.
+ This also means that replication from a MySQL 5.0.3 (or
+ later) master to any MySQL 4.1 (or earlier) slave is generally not
+ supported.
+ </para>
+
+ </formalpara>
+
+ <para>
+ This also has significant implications for upgrading replication
+ servers; see <xref linkend="replication-upgrade"/>, for more
+ information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Use of row-based replication</title>
+
+ <para>
+ You cannot replicate using row-based replication from a
+ MySQL 5.1.5 or later master to a slave running an earlier
+ version of MySQL, since MySQL versions prior to 5.1.5 do not
+ support RBR.
+ </para>
+
+ </formalpara>
+
+ <note>
+ <para>
+ Row-based replication is not available in MySQL ¤t-series;.
+ For more information about row-based replication in MySQL 5.1, see
+ <xref linkend="refman-5.1:replication-formats"/>.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>SQL incompatiblities</title>
+
+ <para>
+ You cannot replicate from a newer master to an older slave
+ using statement-based replication if the statements to be
+ replicated use SQL features available on the master but not
+ on the slave.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For more information on potential replication issues, see
+ <xref linkend="replication-features"/>.
+ </para>
+
</section>
<section id="replication-upgrade">
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/refman-5.1/replication-notes.xml 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 2, Lines Added: 89, Lines Deleted: 41; 6685 bytes
@@ -1980,59 +1980,107 @@
<title>Replication Compatibility Between MySQL Versions</title>
<para>
- The binary log format as implemented in MySQL ¤t-series; is
- considerably different from that used in previous versions,
- especially with regard to handling of character sets,
- <literal>LOAD DATA INFILE</literal>, and time zones.
+ MySQL supports replication from one major version to the next
+ higher major version. For example, you can replicate from a master
+ running MySQL 4.1 to a slave running MySQL 5.0, from a master
+ running MySQL 5.0 to a slave running MySQL 5.1, and so on.
</para>
<para>
- As a general rule, you should set up replication only between
- masters and slaves running the same major versions (5.1, 5.0 or
- 4.1) of MySQL. If you must execute replication between different
- major versions, ensure that your client is at a version equal to
- or higher than that of the master. For example, a master of 4.1.23
- and a slave of 5.0.24 should work together.
+ In some cases, it is also possible to replicate between a master
+ and a slave that is more than one major version newer than the
+ master. However, there are known issues with trying to replicate
+ from a master running MySQL 4.1 or earlier to a slave running
+ MySQL 5.1 or later (Bug #31240). In such cases, you can insert a
+ MySQL server running an intermediate version between the two; for
+ example, rather than replicating directly from a MySQL 4.1 master
+ to a MySQL 5.1 slave, it is possible to replicate from a MySQL 4.1
+ server to a MySQL 5.0 server, and then from the MySQL 5.0 server
+ to a MySQL 5.1 server.
</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
- slave. We recommend upgrading masters and slaves running alpha or
- beta versions to new (production) versions. In many cases,
- replication from a newer master to an older slave will fail.
- </para>
-
- <para>
- In general (but not always), slaves running MySQL
- ¤t-series;.x can be used with older masters, but not the
- reverse. However, there are known issues with trying to replicate
- from a 4.0 or earlier master to a 5.1 or later slave (Bug #31240).
- For more information on potential issues, see
- <xref linkend="replication-features"/>.
- </para>
-
<note>
<para>
- 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"/>.
+ We recommend using the most recent release available within a
+ given MySQL major version because replication (and other)
+ capabilities are continually being improved. We also recommend
+ upgrading masters and slaves running alpha or beta releases of a
+ major version of MySQL to GA (production) releases when these
+ become available for that major version.
</para>
</note>
<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;
- master cannot replicate to a &previous-series; slave if the
- replicated statements use SQL features available in
- ¤t-series; but not in &previous-series;. These and other
- issues are discussed in <xref linkend="replication-features"/>.
+ Replication from newer masters to older slaves may be possible,
+ but is generally not supported. This is due to a number of
+ factors:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Binary log format changes</title>
+
+ <para>
+ The binary log format can change between major releases.
+ While we attempt to maintain backwards compatiblity, this is
+ not always possible. For example, the binary log format
+ implemented in MySQL 5.0 changed considerably from that used
+ in previous versions, especially with regard to handling of
+ character sets, <literal>LOAD DATA INFILE</literal>, and
+ time zones. This means that replication from a
+ MySQL 5.0 (or later) master to a MySQL 4.1 (or earlier)
+ slave is generally not supported.
+ </para>
+
+ </formalpara>
+
+ <para>
+ This also has significant implications for upgrading replication
+ servers; see <xref linkend="replication-upgrade"/>, for more
+ information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Use of row-based replication</title>
+
+ <para>
+ You cannot replicate using row-based replication from a
+ MySQL 5.1.5 or later master to a slave running an earlier
+ version of MySQL, since MySQL versions prior to 5.1.5 do not
+ support RBR.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>SQL incompatiblities</title>
+
+ <para>
+ You cannot replicate from a newer master to an older slave
+ using statement-based replication if the statements to be
+ replicated use SQL features available on the master but not
+ on the slave.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For more information on potential replication issues, see
+ <xref linkend="replication-features"/>.
+ </para>
+
</section>
<section id="replication-upgrade">
@@ -2088,7 +2136,7 @@
<para>
Downgrading a replication setup to a previous version cannot be
- done once you've switched from statement-based to row-based
+ done once you have 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-formats"/>.
</para>
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/refman-6.0/replication-notes.xml 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 1, Lines Added: 102, Lines Deleted: 40; 6881 bytes
@@ -1802,59 +1802,121 @@
<title>Replication Compatibility Between MySQL Versions</title>
<para>
- The binary log format as implemented in MySQL ¤t-series; is
- considerably different from that used in older versions,
- especially with regard to handling of character sets,
- <literal>LOAD DATA INFILE</literal>, and time zones.
+ MySQL supports replication from one major version to the next
+ higher major version. For example, you can replicate from a master
+ running MySQL 5.0 to a slave running MySQL 5.1, from a master
+ running MySQL 5.1 to a slave running MySQL 6.0, and so on.
</para>
<para>
- As a general rule, you should set up replication only between
- masters and slaves running the same major versions (5.1, 5.0 or
- 4.1) of MySQL. If you must execute replication between different
- major versions, ensure that your client is at a version equal to
- or higher than that of the master. For example, a master of 4.1.23
- and a slave of 5.0.24 should work together.
+ In some cases, it is also possible to replicate between a master
+ and a slave that is more than one major version newer than the
+ master. However, there are known issues with trying to replicate
+ from a master running MySQL 4.1 or earlier to a slave running
+ MySQL 5.1 or later (Bug #31240). In such cases, you can insert a
+ MySQL server running an intermediate version between the two; for
+ example, rather than replicating directly from a MySQL 4.1 master
+ to a MySQL 5.1 slave, it is possible to replicate from a MySQL 4.1
+ server to a MySQL 5.0 server, and then from the MySQL 5.0 server
+ to a MySQL 5.1 server.
</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
- slave. We recommend upgrading masters and slaves running alpha or
- beta versions to new (production) versions. In many cases,
- replication from a newer master to an older slave will fail.
- </para>
-
- <para>
- In general (but not always), slaves running MySQL
- ¤t-series;.x can be used with older masters, but not the
- reverse. However, there are known issues with trying to replicate
- from a 4.0 or earlier master to a 5.1 or later slave (Bug #31240).
- For more information on potential issues, see
- <xref linkend="replication-features"/>.
- </para>
-
<note>
<para>
- 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"/>.
+ We recommend using the most recent release available within a
+ given MySQL major version because replication (and other)
+ capabilities are continually being improved. We also recommend
+ upgrading masters and slaves running alpha or beta releases of a
+ major version of MySQL to GA (production) releases when these
+ become available for that major version.
</para>
</note>
<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;
- master cannot replicate to a &previous-series; slave if the
- replicated statements use SQL features available in
- ¤t-series; but not in &previous-series;. These and other
- issues are discussed in <xref linkend="replication-features"/>.
+ Replication from newer masters to older slaves may be possible,
+ but is generally not supported. This is due to a number of
+ factors:
</para>
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Binary log format changes</title>
+
+ <para>
+ The binary log format can change between major releases.
+ While we attempt to maintain backwards compatiblity, this is
+ not always possible. For example, the binary log format
+ implemented in MySQL 5.0 changed considerably from that used
+ in previous versions, especially with regard to handling of
+ character sets, <literal>LOAD DATA INFILE</literal>, and
+ time zones. This means that replication from a MySQL 5.0 (or
+ later) master to a MySQL 4.1 (or earlier) slave is generally
+ not supported.
+ </para>
+
+ </formalpara>
+
+ <para>
+ This also has significant implications for upgrading
+ replication servers; see
+ <xref linkend="replication-upgrade"/>, for more information.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Use of row-based replication</title>
+
+ <para>
+ You cannot replicate using row-based replication from any
+ MySQL 6.0 or later master to a slave running MySQL 5.1.4 or
+ earlier, since MySQL versions prior to 5.1.5 do not support
+ RBR.
+ </para>
+
+ </formalpara>
+
+ <para>
+ For more information about row-based replication, see
+ <xref linkend="replication-formats"/>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>SQL incompatiblities</title>
+
+ <para>
+ You cannot replicate from a newer master to an older slave
+ using statement-based replication if the statements to be
+ replicated use SQL features available on the master but not
+ on the slave.
+ </para>
+
+ </formalpara>
+
+ <para>
+ However, if both the master and the slave support row-based
+ replication, and there are no data definition statements to be
+ replicated that depend on SQL features found on the master but
+ not on the slave, then you can use row-based replication to
+ replicate the effects of data modification statements even if
+ the DDL run on the master is not supported on the slave.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ <para>
+ For more information on potential replication issues, see
+ <xref linkend="replication-features"/>.
+ </para>
+
</section>
<section id="replication-upgrade">
Modified: trunk/topic-guides/topics-5.0/Makefile.depends
===================================================================
--- trunk/topic-guides/topics-5.0/Makefile.depends 2008-10-20 19:50:18 UTC (rev 12106)
+++ trunk/topic-guides/topics-5.0/Makefile.depends 2008-10-20 22:34:22 UTC (rev 12107)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 0; 754 bytes
@@ -306,6 +306,7 @@
../../refman-5.0/metadata/sql-syntax-replication.idmap \
../../refman-5.0/metadata/sql-syntax-server-administration.idmap \
../../refman-5.0/metadata/stored-programs-views.idmap \
+ ../../refman-5.1/metadata/replication-configuration.idmap \
../../refman-common/metadata/bug-reports.idmap
mysql-replication-excerpt.validpure: $(mysql_replication_excerpt_SOURCES)
mysql-replication-excerpt.titles: $(mysql_replication_excerpt_SOURCES)
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12107 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-6.0 topic-guides/topics-5.0 | jon | 21 Oct |
