Author: jstephens
Date: 2008-08-06 00:01:11 +0200 (Wed, 06 Aug 2008)
New Revision: 11503
Log:
Added new RBR Usage section
(Thanks to MC for the draft and to all who provided comments!)
Modified:
trunk/refman-5.1/replication-configuration.xml
trunk/refman-6.0/replication-configuration.xml
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2008-08-05 18:18:14 UTC (rev 11502)
+++ trunk/refman-5.1/replication-configuration.xml 2008-08-05 22:01:11 UTC (rev 11503)
Changed blocks: 1, Lines Added: 253, Lines Deleted: 0; 10260 bytes
@@ -1864,6 +1864,259 @@
</section>
+ <section id="replication-rbr-usage">
+
+ <title>Usage of Row-based Logging and Row-Based Replication</title>
+
+ <para>
+ Using row-based logging or replication, rather than
+ statement-based logging or replication, can result in major
+ changes in the replication environment and in the behavior of
+ applications. This section describes a number of issues and
+ limitations known to exist when using row-based logging or
+ row-based replication. In addition, this section also discusses
+ some best practices for taking advantage of row-based logging
+ (RBL) and row-based replication (RBR).
+ </para>
+
+ <para>
+ For additional information, see
+ <xref linkend="replication-sbr-rbr"/>, and
+ <xref linkend="replication-formats"/>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <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>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <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.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Latency and binary log size</title>
+
+ <para>
+ Because RBL writes changes for each row to the binary log,
+ the size of the binary log can grow quite rapidly. When
+ used in a replication environment, this can significantly
+ increase the time required for making the changes on the
+ slave that match those on the master. You should be aware
+ of the potential for this delay in your applications.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Reading and recovering from the binary log</title>
+
+ <para>
+ The <command>mysqlbinlog</command> tool is currently not
+ able to format the contents of the binary log in a manner
+ that is easily human-readable. This can cause problems if
+ you want to read or recover from a replication or database
+ failure using the contents of the binary log. We are
+ working to overcome this limitation of
+ <command>mysqlbinlog</command> in a future MySQL release;
+ for more information, see Bug #31455.
+ </para>
+
+ </formalpara>
+
+ <para>
+ In addition, there is no direct relationship between logged
+ changes and the original SQL statement or statements that
+ generated these changes. This makes it difficult to identify
+ a problem statement or perform point-in-time recovery based
+ on the statements that made the changes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Binary log execution errors and <literal>slave_exec_mode</literal></title>
+
+ <para>
+ If you use <literal>slave_exec_mode=IDEMPOTENT</literal>,
+ a failure to apply changes from RBL because the original
+ row cannot be found does not trigger an error, and does
+ not cause replication to fail. This means that it is
+ possible that updates are not applied on the slave, so
+ that the master and slave are no longer synchronized.
+ Latency issues and use of non-transactional tables when
+ using <literal>slave_exec_mode=IDEMPOTENT</literal> and
+ RBR can cause the master and slave to diverge even
+ further. For more information about
+ <literal>slave_exec_mode</literal>, see
+ <xref linkend="server-system-variables"/>.
+ </para>
+
+ </formalpara>
+
+ <note>
+ <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.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Lack of binary log checksums</title>
+
+ <para>
+ No checksums are used for RBL. This means that network,
+ disk, and other errors may not be identified when
+ processing the binary log. To ensure that data is
+ transmitted without network corruption, you may want to
+ consider using SSL, which adds another layer of
+ checksumming, for replication connections. See
+ <xref linkend="secure-connections"/>, for more information
+ about setting up MySQL with SSL.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Filtering based on server ID not supported</title>
+
+ <para>
+ A common practice is to filter out changes on some slaves
+ by using a <literal>WHERE</literal> clause that includes
+ the relation <literal>@server_id <>
+ <replaceable>server-id</replaceable></literal> clause with
+ <literal>UPDATE</literal> and DELETE statements, a simple
+ example of such a clause being <literal>WHERE @server_id
+ <> 1</literal>. This does not work correctly with
+ RBL. If you must use the <literal>server_id</literal>
+ system variable for statement filtering, then you should
+ use <option>--row-format=STATEMENT</option> or
+ <option>--row-format=MIXED</option>. For more information
+ about <literal>server_id</literal>, see
+ <xref linkend="server-system-variables"/>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Database-level replication options</title>
+
+ <para>
+ The effects of the options
+ <option>--replicate-do-db</option>,
+ <option>--replicate-ignore-db</option>, and
+ <option>--replicate-rewrite-db</option> differ
+ considerably depending on whether row-based or
+ statement-based logging is in use. Because of this, we
+ recommend that you avoid the database-level options and
+ use the table-level options such as
+ <option>--replicate-do-table</option> and
+ <option>--replicate-ignore-table</option> instead. For
+ more information about these options and the impact that
+ your choice of replication format has on how they operate,
+ see <xref linkend="replication-options"/>.
+ </para>
+
+ </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>
+
</section>
<section id="replication-options">
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
--- trunk/refman-6.0/replication-configuration.xml 2008-08-05 18:18:14 UTC (rev 11502)
+++ trunk/refman-6.0/replication-configuration.xml 2008-08-05 22:01:11 UTC (rev 11503)
Changed blocks: 1, Lines Added: 253, Lines Deleted: 0; 10260 bytes
@@ -1846,6 +1846,259 @@
</section>
+ <section id="replication-rbr-usage">
+
+ <title>Usage of Row-based Logging and Row-Based Replication</title>
+
+ <para>
+ Using row-based logging or replication, rather than
+ statement-based logging or replication, can result in major
+ changes in the replication environment and in the behavior of
+ applications. This section describes a number of issues and
+ limitations known to exist when using row-based logging or
+ row-based replication. In addition, this section also discusses
+ some best practices for taking advantage of row-based logging
+ (RBL) and row-based replication (RBR).
+ </para>
+
+ <para>
+ For additional information, see
+ <xref linkend="replication-sbr-rbr"/>, and
+ <xref linkend="replication-formats"/>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <formalpara>
+
+ <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>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <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.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Latency and binary log size</title>
+
+ <para>
+ Because RBL writes changes for each row to the binary log,
+ the size of the binary log can grow quite rapidly. When
+ used in a replication environment, this can significantly
+ increase the time required for making the changes on the
+ slave that match those on the master. You should be aware
+ of the potential for this delay in your applications.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Reading and recovering from the binary log</title>
+
+ <para>
+ The <command>mysqlbinlog</command> tool is currently not
+ able to format the contents of the binary log in a manner
+ that is easily human-readable. This can cause problems if
+ you want to read or recover from a replication or database
+ failure using the contents of the binary log. We are
+ working to overcome this limitation of
+ <command>mysqlbinlog</command> in a future MySQL release;
+ for more information, see Bug #31455.
+ </para>
+
+ </formalpara>
+
+ <para>
+ In addition, there is no direct relationship between logged
+ changes and the original SQL statement or statements that
+ generated these changes. This makes it difficult to identify
+ a problem statement or perform point-in-time recovery based
+ on the statements that made the changes.
+ </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Binary log execution errors and <literal>slave_exec_mode</literal></title>
+
+ <para>
+ If you use <literal>slave_exec_mode=IDEMPOTENT</literal>,
+ a failure to apply changes from RBL because the original
+ row cannot be found does not trigger an error, and does
+ not cause replication to fail. This means that it is
+ possible that updates are not applied on the slave, so
+ that the master and slave are no longer synchronized.
+ Latency issues and use of non-transactional tables when
+ using <literal>slave_exec_mode=IDEMPOTENT</literal> and
+ RBR can cause the master and slave to diverge even
+ further. For more information about
+ <literal>slave_exec_mode</literal>, see
+ <xref linkend="server-system-variables"/>.
+ </para>
+
+ </formalpara>
+
+ <note>
+ <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.
+ </para>
+ </note>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Lack of binary log checksums</title>
+
+ <para>
+ No checksums are used for RBL. This means that network,
+ disk, and other errors may not be identified when
+ processing the binary log. To ensure that data is
+ transmitted without network corruption, you may want to
+ consider using SSL, which adds another layer of
+ checksumming, for replication connections. See
+ <xref linkend="secure-connections"/>, for more information
+ about setting up MySQL with SSL.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Filtering based on server ID not supported</title>
+
+ <para>
+ A common practice is to filter out changes on some slaves
+ by using a <literal>WHERE</literal> clause that includes
+ the relation <literal>@server_id <>
+ <replaceable>server-id</replaceable></literal> clause with
+ <literal>UPDATE</literal> and DELETE statements, a simple
+ example of such a clause being <literal>WHERE @server_id
+ <> 1</literal>. This does not work correctly with
+ RBL. If you must use the <literal>server_id</literal>
+ system variable for statement filtering, then you should
+ use <option>--row-format=STATEMENT</option> or
+ <option>--row-format=MIXED</option>. For more information
+ about <literal>server_id</literal>, see
+ <xref linkend="server-system-variables"/>.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Database-level replication options</title>
+
+ <para>
+ The effects of the options
+ <option>--replicate-do-db</option>,
+ <option>--replicate-ignore-db</option>, and
+ <option>--replicate-rewrite-db</option> differ
+ considerably depending on whether row-based or
+ statement-based logging is in use. Because of this, we
+ recommend that you avoid the database-level options and
+ use the table-level options such as
+ <option>--replicate-do-table</option> and
+ <option>--replicate-ignore-table</option> instead. For
+ more information about these options and the impact that
+ your choice of replication format has on how they operate,
+ see <xref linkend="replication-options"/>.
+ </para>
+
+ </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>
+
</section>
<section id="replication-options">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11503 - in trunk: refman-5.1 refman-6.0 | jon | 6 Aug |
