Author: jstephens
Date: 2007-08-13 15:34:50 +0200 (Mon, 13 Aug 2007)
New Revision: 7445
Log:
Remarks on NDB -> non-NDB replication
(Fixes Docs Bug #29569)
Modified:
trunk/refman-5.1/mysql-cluster.xml
trunk/refman-5.2/mysql-cluster.xml
Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml 2007-08-13 13:19:21 UTC (rev 7444)
+++ trunk/refman-5.1/mysql-cluster.xml 2007-08-13 13:34:50 UTC (rev 7445)
Changed blocks: 1, Lines Added: 77, Lines Deleted: 0; 3299 bytes
@@ -19132,6 +19132,83 @@
</formalpara>
</listitem>
+ <listitem>
+ <formalpara>
+
+ <title>Replication from <literal>NDB</literal> to other storage engines</title>
+
+ <para>
+ If you attempt to replicate from a MySQL Cluster to a
+ slave that uses a storage engine that does not handle its
+ own binary logging, the replication process aborts with
+ the error <errortext>Binary logging not possible ...
+ Statement cannot be written atomically since more than one
+ engine involved and at least one engine is
+ self-logging</errortext> (Error
+ <errorcode>1595</errorcode>). It is possible to work
+ around this issue in one of the following ways:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Turn off binary logging on the slave</title>
+
+ <para>
+ This can be accomplished by setting
+ <literal>SQL_BIN_LOG = 0</literal>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Change the storage engine used for the
+ <literal>mysql.ndb_apply_status</literal> table</title>
+
+ <para>
+ Causing this table to use an engine that does not
+ handle its own binary logging can also eliminate
+ the conflict. This can be done by issuing a
+ statement such as <literal>ALTER TABLE
+ mysql.ndb_apply_status ENGINE=MyISAM</literal> on
+ the slave. It is safe to do this when using a
+ non-<literal>NDB</literal> storage engine on the
+ slave, since you do not then need to worry about
+ keeping multiple slave SQL nodes synchronized.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Filter out changes to the <literal>mysql.ndb_apply_status</literal>
+ table on the slave</title>
+
+ <para>
+ This can be done by starting the slave SQL node
+ with the option
+ <option>--replicate-ignore-table=mysql.ndb_apply_status</option>.
+ If you need for other tables to be ignored by
+ replication, you might wish to use an appropriate
+ <option>--replicate-wild-ignore-table</option>
+ option instead.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
</itemizedlist>
</section>
Modified: trunk/refman-5.2/mysql-cluster.xml
===================================================================
--- trunk/refman-5.2/mysql-cluster.xml 2007-08-13 13:19:21 UTC (rev 7444)
+++ trunk/refman-5.2/mysql-cluster.xml 2007-08-13 13:34:50 UTC (rev 7445)
Changed blocks: 1, Lines Added: 77, Lines Deleted: 0; 3299 bytes
@@ -18998,6 +18998,83 @@
</formalpara>
</listitem>
+ <listitem>
+ <formalpara>
+
+ <title>Replication from <literal>NDB</literal> to other storage engines</title>
+
+ <para>
+ If you attempt to replicate from a MySQL Cluster to a
+ slave that uses a storage engine that does not handle its
+ own binary logging, the replication process aborts with
+ the error <errortext>Binary logging not possible ...
+ Statement cannot be written atomically since more than one
+ engine involved and at least one engine is
+ self-logging</errortext> (Error
+ <errorcode>1595</errorcode>). It is possible to work
+ around this issue in one of the following ways:
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <title>Turn off binary logging on the slave</title>
+
+ <para>
+ This can be accomplished by setting
+ <literal>SQL_BIN_LOG = 0</literal>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Change the storage engine used for the
+ <literal>mysql.ndb_apply_status</literal> table</title>
+
+ <para>
+ Causing this table to use an engine that does not
+ handle its own binary logging can also eliminate
+ the conflict. This can be done by issuing a
+ statement such as <literal>ALTER TABLE
+ mysql.ndb_apply_status ENGINE=MyISAM</literal> on
+ the slave. It is safe to do this when using a
+ non-<literal>NDB</literal> storage engine on the
+ slave, since you do not then need to worry about
+ keeping multiple slave SQL nodes synchronized.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Filter out changes to the <literal>mysql.ndb_apply_status</literal>
+ table on the slave</title>
+
+ <para>
+ This can be done by starting the slave SQL node
+ with the option
+ <option>--replicate-ignore-table=mysql.ndb_apply_status</option>.
+ If you need for other tables to be ignored by
+ replication, you might wish to use an appropriate
+ <option>--replicate-wild-ignore-table</option>
+ option instead.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
</itemizedlist>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7445 - in trunk: refman-5.1 refman-5.2 | jon | 13 Aug |
