Author: jstephens
Date: 2008-07-23 14:57:58 +0200 (Wed, 23 Jul 2008)
New Revision: 11325
Log:
Undoing previous commit, with not-ready/unrelated changes
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/refman-5.1/mysql-cluster-limitations.xml
trunk/refman-5.1/mysql-cluster-replication.xml
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2008-07-23 12:52:52 UTC (rev 11324)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-07-23 12:57:58 UTC (rev 11325)
Changed blocks: 1, Lines Added: 0, Lines Deleted: 87; 2579 bytes
@@ -6,93 +6,6 @@
]>
<changelog>
- <logentry entrytype="bug">
-
- <tags>
- <highlight type="partitioning"/>
- <manual type="PARTITION BY LIST"/>
- <manual type="NOT IN"/>
- <manual type="MyISAM"/>
- </tags>
-
- <bugs>
- <fixes bugid="35931"/>
- </bugs>
-
- <versions>
- <version ver="5.1.28"/>
- <version ver="6.0.7"/>
- </versions>
-
- <message>
-
- <para>
- A <literal>LIST</literal> partitioned <literal>MyISAM</literal>
- table returned erroneous results when an index was present on a
- column in the <literal>WHERE</literal> clause and <literal>NOT
- IN</literal> was used on that column.
- </para>
-
- <para>
- Searches using the index were also much slower then if the index
- were not present.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
- <highlight type="partitioning"/>
- <manual type="storage engines"/>
- <manual type="COUNT()"/>
- </tags>
-
- <bugs>
- <fixes bugid="35745"/>
- </bugs>
-
- <versions>
- <version ver="5.1.28"/>
- <version ver="6.0.7"/>
- </versions>
-
- <message>
-
- <para>
- <literal>SELECT COUNT(*)</literal> was not correct for some
- partitioned tables using a storage engine that did not support
- <literal>HA_STATS_RECORDS_IS_EXACT</literal>. Tables using the
- <literal>ARCHIVE</literal> storage engine were known to be
- affected.
- </para>
-
- <para>
- This was because <literal>ha_partition::records()</literal> was
- not implemented, and so the default
- <literal>handler::records()</literal> was used in its place.
- However, this is not correct behavior if the storage engine does
- not support <literal>HA_STATS_RECORDS_IS_EXACT</literal>.
- </para>
-
- <para>
- The solution was to implement
- <literal>ha_partition::records()</literal> as a wrapper around
- the underlying partition records.
- </para>
-
- <para>
- As a result of this fix, the rows column in the output of
- <literal>EXPLAIN PARTITIONS</literal> now includes the total
- number of records in the partitioned table.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="feature">
<tags>
Modified: trunk/refman-5.1/mysql-cluster-limitations.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations.xml 2008-07-23 12:52:52 UTC (rev 11324)
+++ trunk/refman-5.1/mysql-cluster-limitations.xml 2008-07-23 12:57:58 UTC (rev 11325)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 631 bytes
@@ -1635,7 +1635,7 @@
<para>
Circular replication is supported for MySQL Cluster
beginning with MySQL 5.1.18. See
- <xref linkend="mysql-cluster-replication-multi-master"/>.
+ <xref linkend="mysql-cluster-replication-issues"/>.
</para>
</formalpara>
Modified: trunk/refman-5.1/mysql-cluster-replication.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication.xml 2008-07-23 12:52:52 UTC (rev 11324)
+++ trunk/refman-5.1/mysql-cluster-replication.xml 2008-07-23 12:57:58 UTC (rev 11325)
Changed blocks: 2, Lines Added: 138, Lines Deleted: 172; 11826 bytes
@@ -346,6 +346,144 @@
<listitem>
<formalpara>
+ <title>Circular replication</title>
+
+ <indexterm>
+ <primary>circular replication</primary>
+ <secondary>in MySQL Cluster</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>replication</primary>
+ <secondary>circular</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>MySQL Cluster replication</primary>
+ <secondary>and circular replication</secondary>
+ </indexterm>
+
+ <para>
+ Prior to MySQL 5.1.18, circular replication was not
+ supported with MySQL Cluster replication, due to the fact
+ that all log events created in a particular MySQL Cluster
+ were wrongly tagged with the server ID of the MySQL server
+ used as master and not with the server ID of the originating
+ server.
+ </para>
+
+ </formalpara>
+
+ <para>
+ Beginning with MySQL 5.1.18, this limitation is lifted, as
+ discussed in the next few paragraphs, in which we consider the
+ example of a replication setup involving three MySQL Clusters
+ numbered 1, 2, and 3, in which Cluster 1 acts as the
+ replication master for Cluster 2, Cluster 2 acts as the master
+ for Cluster 3, and Cluster 3 acts as the master for Cluster 1.
+ Each cluster has two SQL nodes, with SQL nodes A and B
+ belonging to Cluster 1, SQL nodes C and D belonging to Cluster
+ 2, and SQL nodes E and F belonging to Cluster 3.
+ </para>
+
+ <para>
+ Circular replication using these clusters is supported as long
+ as:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ the SQL nodes on all masters and slaves are the same
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ All SQL nodes acting as replication masters and slaves
+ are started using the
+ <option>--log-slave-updates</option> option
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ This type of circular replication setup is shown in the
+ following diagram:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="../refman-common/images/published/cluster-circular-replication-1.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Cluster circular replication scheme in
+ which all master SQL nodes are also slaves.</phrase>
+ </textobject>
+ </mediaobject>
+
+ In this scenario, SQL node A in Cluster 1 replicates to SQL
+ node C in Cluster 2; SQL node C replicates to SQL node E in
+ Cluster 3; SQL node E replicates to SQL node A. In other
+ words, the replication line (indicated by the red arrows in
+ the diagram) directly connects all SQL nodes used as
+ replication masters and slaves.
+ </para>
+
+ <para>
+ It should also be possible to set up circular replication in
+ which not all master SQL nodes are also slaves, as shown here:
+
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="../refman-common/images/published/cluster-circular-replication-2.png" format="PNG"/>
+ </imageobject>
+ <textobject>
+ <phrase lang="en">Cluster circular replication scheme in
+ which all master SQL nodes are not also necessarily
+ slaves.</phrase>
+ </textobject>
+ </mediaobject>
+
+ In this case, different SQL nodes in each cluster are used as
+ replication masters and slaves. However, you must
+ <emphasis>not</emphasis> start any of the SQL nodes using
+ <option>--log-slave-updates</option> (see the
+ <link linkend="option_mysqld_log-slave-updates">description of
+ this option</link> for more information). This type of
+ circular replication scheme for MySQL Cluster, in which the
+ line of replication (again indicated by the red arrows in the
+ diagram) is discontinuous, should be possible, but it should
+ be noted that it has not yet been thoroughly tested and must
+ therefore still be considered experimental.
+ </para>
+
+ <important>
+ <para>
+ Beginning with MySQL 5.1.24, you should execute the
+ following statement before starting circular replication:
+
+<programlisting>
+mysql> <userinput>SET GLOBAL SLAVE_EXEC_MODE = 'IDEMPOTENT';</userinput>
+</programlisting>
+
+ This is necessary to suppress duplicate-key and other errors
+ that otherwise break circular replication of MySQL Cluster.
+ <literal>IDEMPOTENT</literal> mode is also required for
+ multi-master replication when using MySQL Cluster. (Bug
+ #31609)
+ </para>
+
+ <para>
+ See
+ <link linkend="option_mysqld_slave_exec_mode"><literal>Slave_exec_mode</literal></link>,
+ for more information.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
<title>DDL statements</title>
<indexterm>
@@ -2271,178 +2409,6 @@
</section>
- <section id="mysql-cluster-replication-multi-master">
-
- <title>Multi-Master and Circular Replication</title>
-
- <para>
- Beginning with MySQL 5.1.18, it is possible to use MySQL Cluster
- in multi-master replication, including circular replication
- between a number of MySQL Clusters.
- </para>
-
- <note>
- <para>
- Prior to MySQL 5.1.18, multi-master replication including
- circular replication was not supported with MySQL Cluster
- replication. This was because log events created in a particular
- MySQL Cluster were wrongly tagged with the server ID of the
- master rather than the server ID of the originating server.
- </para>
- </note>
-
- <formalpara>
-
- <title>Circular replication example</title>
-
- <para>
- In the next few paragraphs we consider the example of a
- replication setup involving three MySQL Clusters numbered 1, 2,
- and 3, in which Cluster 1 acts as the replication master for
- Cluster 2, Cluster 2 acts as the master for Cluster 3, and
- Cluster 3 acts as the master for Cluster 1. Each cluster has two
- SQL nodes, with SQL nodes A and B belonging to Cluster 1, SQL
- nodes C and D belonging to Cluster 2, and SQL nodes E and F
- belonging to Cluster 3.
- </para>
-
- </formalpara>
-
- <para>
- Circular replication using these clusters is supported as long as:
-
- <itemizedlist>
-
- <listitem>
- <para>
- The SQL nodes on all masters and slaves are the same
- </para>
- </listitem>
-
- <listitem>
- <para>
- All SQL nodes acting as replication masters and slaves are
- started using the <option>--log-slave-updates</option>
- option
- </para>
- </listitem>
-
- </itemizedlist>
-
- This type of circular replication setup is shown in the following
- diagram:
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="../refman-common/images/published/cluster-circular-replication-1.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">Cluster circular replication scheme in which
- all master SQL nodes are also slaves.</phrase>
- </textobject>
- </mediaobject>
-
- In this scenario, SQL node A in Cluster 1 replicates to SQL node C
- in Cluster 2; SQL node C replicates to SQL node E in Cluster 3;
- SQL node E replicates to SQL node A. In other words, the
- replication line (indicated by the red arrows in the diagram)
- directly connects all SQL nodes used as replication masters and
- slaves.
- </para>
-
- <para>
- It should also be possible to set up circular replication in which
- not all master SQL nodes are also slaves, as shown here:
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="../refman-common/images/published/cluster-circular-replication-2.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="en">Cluster circular replication scheme in which
- all master SQL nodes are not also necessarily slaves.</phrase>
- </textobject>
- </mediaobject>
-
- In this case, different SQL nodes in each cluster are used as
- replication masters and slaves. However, you must
- <emphasis>not</emphasis> start any of the SQL nodes using
- <option>--log-slave-updates</option> (see the
- <link linkend="option_mysqld_log-slave-updates">description of
- this option</link> for more information). This type of circular
- replication scheme for MySQL Cluster, in which the line of
- replication (again indicated by the red arrows in the diagram) is
- discontinuous, should be possible, but it should be noted that it
- has not yet been thoroughly tested and must therefore still be
- considered experimental.
- </para>
-
- <important>
- <para>
- Beginning with MySQL 5.1.24, you should execute the following
- statement before starting circular replication:
-
-<programlisting>
-mysql> <userinput>SET GLOBAL SLAVE_EXEC_MODE = 'IDEMPOTENT';</userinput>
-</programlisting>
-
- This is necessary to suppress duplicate-key and other errors
- that otherwise break circular replication of MySQL Cluster.
- <literal>IDEMPOTENT</literal> mode is also required for
- multi-master replication when using MySQL Cluster. (Bug #31609)
- </para>
-
- <para>
- See
- <link linkend="option_mysqld_slave_exec_mode"><literal>Slave_exec_mode</literal></link>,
- for more information.
- </para>
- </important>
-
- <formalpara>
-
- <title>Multi-master failover example</title>
-
- <para>
- In this section, we discuss failing over between replication
- masters in a multi-master MySQL Cluster replication environment,
- shown here:
-
- <mediaobject>
- <imageobject>
- <imagedata fileref="../refman-common/images/published/cluster-replication-multi-master.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="EN">Multi-master MySQL Cluster replication
- setup, with three MySQL Clusters</phrase>
- </textobject>
- </mediaobject>
- </para>
-
- </formalpara>
-
- <para>
- <mediaobject>
- <imageobject>
- <imagedata fileref="../refman-common/images/published/cluster-replication-log-slave-updates.png" format="PNG"/>
- </imageobject>
- <textobject>
- <phrase lang="EN">Multi-master MySQL Cluster replication
- setup, detail with MySQL Servers</phrase>
- </textobject>
- </mediaobject>
- </para>
-
- <note>
- <para>
- Replication slaves must be run with the
- <option>--log-slave-updates</option> option. Using this option
- has no effect on servers not being run as replication slaves.
- </para>
- </note>
-
- </section>
-
<section id="mysql-cluster-replication-conflict-resolution">
<title>MySQL Cluster Replication Conflict Resolution</title>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11325 - in trunk: dynamic-docs/changelog refman-5.1 | jon | 23 Jul |
