| List: | Commits | « Previous MessageNext Message » | |
| From: | jon | Date: | July 23 2008 2:52pm |
| Subject: | svn commit - mysqldoc@docsrva: r11324 - in trunk: dynamic-docs/changelog refman-5.1 | ||
| View as plain text | |||
Author: jstephens Date: 2008-07-23 14:52:52 +0200 (Wed, 23 Jul 2008) New Revision: 11324 Log: Documenting Partitioning bugfixes: Bug #35745, Bug #35931 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 02:38:13 UTC (rev 11323) +++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-07-23 12:52:52 UTC (rev 11324) Changed blocks: 1, Lines Added: 87, Lines Deleted: 0; 2579 bytes @@ -6,6 +6,93 @@ ]> <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 02:38:13 UTC (rev 11323) +++ trunk/refman-5.1/mysql-cluster-limitations.xml 2008-07-23 12:52:52 UTC (rev 11324) 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-issues"/>. + <xref linkend="mysql-cluster-replication-multi-master"/>. </para> </formalpara> Modified: trunk/refman-5.1/mysql-cluster-replication.xml =================================================================== --- trunk/refman-5.1/mysql-cluster-replication.xml 2008-07-23 02:38:13 UTC (rev 11323) +++ trunk/refman-5.1/mysql-cluster-replication.xml 2008-07-23 12:52:52 UTC (rev 11324) Changed blocks: 2, Lines Added: 172, Lines Deleted: 138; 11826 bytes @@ -346,144 +346,6 @@ <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> @@ -2409,6 +2271,178 @@ </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: r11324 - in trunk: dynamic-docs/changelog refman-5.1 | jon | 23 Jul |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.625 sec. using MySQL 5.1.14-beta-log