Author: jstephens
Date: 2008-10-17 14:36:39 +0200 (Fri, 17 Oct 2008)
New Revision: 12086
Log:
More fixes to replication-rbr-usage per email discussion with Mats
Fixed some inconcsistencies between 5.1/6.0 versions
Updated dependencies
Modified:
trunk/refman-5.1/replication-configuration.xml
trunk/refman-6.0/Makefile.depends
trunk/refman-6.0/replication-configuration.xml
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2008-10-16 16:27:25 UTC (rev 12085)
+++ trunk/refman-5.1/replication-configuration.xml 2008-10-17 12:36:39 UTC (rev 12086)
Changed blocks: 7, Lines Added: 45, Lines Deleted: 78; 7530 bytes
@@ -1360,15 +1360,19 @@
<listitem>
<para>
As of MySQL 5.1.8, the binary logging format can be changed in
- real time according to the event being logged when using
- mixed-format logging. When the mixed format is in effect,
- statement-based logging is used by default, but automatically
- switches to row-based logging in particular cases as described
- below. This is sometimes referred to as <firstterm>mixed-based
- replication</firstterm> (abbreviated as
- <firstterm>MBR</firstterm>). For more information, see
- <xref linkend="binary-log-mixed"/>.
+ real time according to the event being logged using
+ <firstterm>mixed-format logging</firstterm>.
</para>
+
+ <para>
+ When the mixed format is in effect, statement-based logging is
+ used by default, but automatically switches to row-based
+ logging in particular cases as described below. Replication
+ using the mixed format is often referred to as
+ <firstterm>mixed-based replication</firstterm> or
+ <firstterm>mixed-format replication</firstterm>. For more
+ information, see <xref linkend="binary-log-mixed"/>.
+ </para>
</listitem>
</itemizedlist>
@@ -1793,13 +1797,6 @@
</para>
</listitem>
- <listitem>
- <para>
- It's possible to add multiple threads to apply data on the
- slave in the future (works better on SMP machines).
- </para>
- </listitem>
-
</itemizedlist>
<para>
@@ -1833,6 +1830,21 @@
<listitem>
<para>
+ When using row-based replication to replicate a statement
+ (for example, an <literal>UPDATE</literal> or
+ <literal>DELETE</literal> statement), each changed row must
+ be written to the binary log. In contrast, when using
+ statement-based replication, only the statement is written
+ to the binary log. If the statement changes many rows,
+ row-based replication may write significantly more data to
+ the binary log. In these cases the binary log will be locked
+ for a longer time to write the data, which may cause
+ concurrency problems.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Deterministic UDFs that generate large
<literal>BLOB</literal> values take longer to replicate.
</para>
@@ -1975,32 +1987,9 @@
<title>RBL and the <literal>BLACKHOLE</literal> storage engine</title>
<para>
- While it is possible to use the
- <literal>BLACKHOLE</literal> storage engine in combination
- with RBL or RBR, you should be aware of the following
- issues:
-
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>DELETE</literal> and
- <literal>UPDATE</literal> statements currently do
- not work with RBL. This is a known issue which we
- are working to correct in a future MySQL release
- (see Bug #38360).
- </para>
- </listitem>
-
- <listitem>
- <para>
- DDL statements are not supported on
- <literal>BLACKHOLE</literal> tables when using RBL.
- This is by design.
- </para>
- </listitem>
-
- </itemizedlist>
+ Prior to MySQL 5.1.29, <literal>DELETE</literal> and
+ <literal>UPDATE</literal> statements did not work with RBL
+ and <literal>BLACKHOLE</literal> tables. (Bug #38360)
</para>
</formalpara>
@@ -2012,21 +2001,16 @@
<title>RBL and synchronization of non-transactional tables</title>
<para>
- When executing a statement on the master that would update
- multiple rows, the table is locked on the master while all
- the affected rows are updated. When using
- non-transactional storage engines, including
- <literal>MyISAM</literal>, the changes to each row are
- written to the binary log as each row is modified. On the
- slave, each RBL statement is executed individually,
- without the table lock that would have been in place on
- the master for the duration of the original statement,
- because it cannot determine that the individual row
- updates were part of a bulk statement. This can cause
- synchronization problems, since <literal>SELECT</literal>
- statements issued on the master and on a slave may return
- different data for individual rows during the execution of
- the original statement.
+ When using row-based replication of a
+ <literal>MyISAM</literal> or other non-transactional
+ table, changed rows are written to the transaction cache.
+ Often, when many rows are affected, the set of changes are
+ split into several events; when the statement commits, all
+ of these events are written to the binary log. When
+ executing on the slave, a table lock is taken on all
+ tables involved, then the rows are applied in batch mode.
+ (This may or may not be effective, depending on the engine
+ used for the slave's copy of the table).
</para>
</formalpara>
@@ -2096,9 +2080,11 @@
<para>
<literal>slave_exec_mode=IDEMPOTENT</literal> is generally
useful only for circular replication or multi-master
- replication with MySQL Cluster. For other scenarios, the
- default value (<literal>slave_exec_mode=STRICT</literal>)
- is normally sufficient.
+ replication with MySQL Cluster (see
+ <xref linkend="mysql-cluster-replication"/>). For other
+ scenarios, the default value
+ (<literal>slave_exec_mode=STRICT</literal>) is normally
+ sufficient.
</para>
</note>
</listitem>
@@ -2169,25 +2155,6 @@
</formalpara>
</listitem>
- <listitem>
- <formalpara>
-
- <title><literal>MyISAM</literal> performance and RBL</title>
-
- <para>
- When using row-based logging, changes to rows are written
- to disk as soon as they are applied on the slave. When
- performing an update on <literal>MyISAM</literal> tables,
- the slave writes each row change separately to disk. This
- means that an <literal>UPDATE</literal> statement that
- affects many <literal>MyISAM</literal> tables may take
- longer to be applied on the slave when using row-based
- logging than when using statement-based logging.
- </para>
-
- </formalpara>
- </listitem>
-
</itemizedlist>
</section>
Modified: trunk/refman-6.0/Makefile.depends
===================================================================
--- trunk/refman-6.0/Makefile.depends 2008-10-16 16:27:25 UTC (rev 12085)
+++ trunk/refman-6.0/Makefile.depends 2008-10-17 12:36:39 UTC (rev 12086)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 0; 627 bytes
@@ -1993,6 +1993,7 @@
replication_configuration_IMAGES =
replication_configuration_SOURCES = replication-configuration.xml $(replication_configuration_INCLUDES)
replication_configuration_IDMAPS = \
+ ../refman-5.1/metadata/mysql-cluster.idmap \
../refman-6.0/metadata/backup.idmap \
../refman-6.0/metadata/dba-core.idmap \
../refman-6.0/metadata/errors-problems.idmap \
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
--- trunk/refman-6.0/replication-configuration.xml 2008-10-16 16:27:25 UTC (rev 12085)
+++ trunk/refman-6.0/replication-configuration.xml 2008-10-17 12:36:39 UTC (rev 12086)
Changed blocks: 7, Lines Added: 37, Lines Deleted: 69; 6822 bytes
@@ -402,8 +402,8 @@
of a more complex replication topology (for example, where the
slave acts as a master to other slaves).
-<!--
- For more information, see <xref linkend="replication-topology"/>.
+<!--
+ For more information, see <xref linkend="replication-topology"/>.
-->
</para>
@@ -1360,15 +1360,19 @@
<listitem>
<para>
The binary logging format can be changed in real time
- according to the event being logged when using mixed-format
- logging. When the mixed format is in effect, statement-based
- logging is used by default, but automatically switches to
- row-based logging in particular cases as described below. This
- is sometimes referred to as associated <firstterm>mixed-based
- replication</firstterm> (abbreviated as
- <firstterm>MBR</firstterm>). For more information, see
- <xref linkend="binary-log-mixed"/>.
+ according to the event being logged using
+ <firstterm>mixed-format logging</firstterm>.
</para>
+
+ <para>
+ When the mixed format is in effect, statement-based logging is
+ used by default, but automatically switches to row-based
+ logging in particular cases as described below. Replication
+ using the mixed format is often referred to as
+ <firstterm>mixed-based replication</firstterm> or
+ <firstterm>mixed-format replication</firstterm>. For more
+ information, see <xref linkend="binary-log-mixed"/>.
+ </para>
</listitem>
</itemizedlist>
@@ -1386,6 +1390,14 @@
</para>
<para>
+ You must have the <literal>SUPER</literal> privilege to set the
+ binary logging format on the global level. Starting with MySQL
+ 6.0.7, you must also have the <literal>SUPER</literal> privilege
+ to set the binary logging format for the current session. (Bug
+ #39106)
+ </para>
+
+ <para>
The statement-based and row-based replication formats have
different issues and limitations. For a comparison of their
relative advantages and disadvantages, see
@@ -1939,30 +1951,9 @@
<title>RBL and the <literal>BLACKHOLE</literal> storage engine</title>
<para>
- While it is possible to use the
- <literal>BLACKHOLE</literal> storage engine in combination
- with RBL or RBR, you should be aware of the following
- issues:
-
- <itemizedlist>
-
- <listitem>
- <para>
- Prior to MySQL 6.0.7, <literal>DELETE</literal> and
- <literal>UPDATE</literal> statements did not work
- with RBL (Bug #38360).
- </para>
- </listitem>
-
- <listitem>
- <para>
- DDL statements are not supported on
- <literal>BLACKHOLE</literal> tables when using RBL.
- This is by design.
- </para>
- </listitem>
-
- </itemizedlist>
+ Prior to MySQL 6.0.7, <literal>DELETE</literal> and
+ <literal>UPDATE</literal> statements did not work with RBL
+ and <literal>BLACKHOLE</literal> tables (Bug #38360).
</para>
</formalpara>
@@ -1974,21 +1965,16 @@
<title>RBL and synchronization of non-transactional tables</title>
<para>
- When executing a statement on the master that would update
- multiple rows, the table is locked on the master while all
- the affected rows are updated. When using
- non-transactional storage engines, including
- <literal>MyISAM</literal>, the changes to each row are
- written to the binary log as each row is modified. On the
- slave, each RBL statement is executed individually,
- without the table lock that would have been in place on
- the master for the duration of the original statement,
- because it cannot determine that the individual row
- updates were part of a bulk statement. This can cause
- synchronization problems, since <literal>SELECT</literal>
- statements issued on the master and on a slave may return
- different data for individual rows during the execution of
- the original statement.
+ When using row-based replication of a
+ <literal>MyISAM</literal> or other non-transactional
+ table, changed rows are written to the transaction cache.
+ Often, when many rows are affected, the set of changes are
+ split into several events; when the statement commits, all
+ of these events are written to the binary log. When
+ executing on the slave, a table lock is taken on all
+ tables involved, then the rows are applied in batch mode.
+ (This may or may not be effective, depending on the engine
+ used for the slave's copy of the table).
</para>
</formalpara>
@@ -2069,7 +2055,8 @@
wishing to upgrade from MySQL 5.0 should instead migrate
to MySQL Cluster NDB 6.2 or 6.3; these are based on MySQL
5.1 but contain the latest improvements and fixes for
- <literal>NDBCLUSTER</literal>.
+ <literal>NDBCLUSTER</literal>. For more information, see
+ <xref linkend="refman-5.1:mysql-cluster"/>.
</para>
</note>
</listitem>
@@ -2140,25 +2127,6 @@
</formalpara>
</listitem>
- <listitem>
- <formalpara>
-
- <title><literal>MyISAM</literal> performance and RBL</title>
-
- <para>
- When using row-based logging, changes to rows are written
- to disk as soon as they are applied on the slave. When
- performing an update on <literal>MyISAM</literal> tables,
- the slave writes each row change separately to disk. This
- means that an <literal>UPDATE</literal> statement that
- affects many <literal>MyISAM</literal> tables may take
- longer to be applied on the slave when using row-based
- logging than when using statement-based logging.
- </para>
-
- </formalpara>
- </listitem>
-
</itemizedlist>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12086 - in trunk: refman-5.1 refman-6.0 | jon | 17 Oct |
