Author: shinz
Date: 2006-01-04 00:34:28 +0100 (Wed, 04 Jan 2006)
New Revision: 658
Log:
More RBR tweaks based on Mats' feedback, and added --binlog-format option to DBA chapter
Modified:
trunk/refman-5.1/database-administration.xml
trunk/refman-5.1/replication.xml
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-03 20:43:06 UTC (rev 657)
+++ trunk/refman-5.1/database-administration.xml 2006-01-03 23:34:28 UTC (rev 658)
@@ -5924,6 +5924,16 @@
<xref linkend="binary-log"/>.
</para>
</listitem>
+
+ <listitem>
+ <para>
+ <literal>binlog_format</literal>
+ </para>
+ <para>
+ The value of the <option>--binlog-format</option> option
+ (either <literal>row</literal> or <literal>statement</literal>).
+ </para>
+ </listitem>
<listitem>
<para>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-01-03 20:43:06 UTC (rev 657)
+++ trunk/refman-5.1/replication.xml 2006-01-03 23:34:28 UTC (rev 658)
@@ -236,6 +236,12 @@
<section id="replication-row-based">
<title>&title-replication-row-based;</title>
+
+ <para>
+ <remark role="todo">
+ [SH] Provide a definition of row-based replication.
+ </remark>
+ </para>
<para>
With MySQL's classic statement-based replication, there may be
@@ -251,8 +257,9 @@
<para>
If you're building MySQL from source, it must be compiled with the
- <option>- -with-row-based-replication</option> switch to
- <command>configure</command> in order to enable RBR.
+ <option>--with-row-based-replication</option> switch to
+ <command>configure</command> in order to enable row-based
+ replication.
</para>
<para>
@@ -262,7 +269,7 @@
option:
<programlisting>
-- -binlog-format=row
+--binlog-format=row
</programlisting>
This enables row-based replication
@@ -271,6 +278,7 @@
this case.
</para>
+<!-- Remove comment when WL#2712 is implemented
<para>
Setting <option>- -binlog-format=row</option> has the same effect
as setting the dynamic server system variable
@@ -287,13 +295,16 @@
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 2;</userinput>
</programlisting>
</para>
-
+-->
+
<para>
If you want to switch back to statement-based replication, restart
- the server without the <literal>- -binlog-format=row</literal>
+ the server without the <literal>--binlog-format=row</literal>
option (statement-based replication is the default) or by
- specifiying <option>- -binlog-format=statement</option>
- explicitly. Without restarting the server, you can set the dynamic
+ specifiying <option>--binlog-format=statement</option>
+ explicitly.
+<!-- Remove comment when WL#2712 is implemented
+ Without restarting the server, you can set the dynamic
server system variable, like this:
<programlisting>
@@ -305,9 +316,11 @@
<programlisting>
mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
</programlisting>
+-->
</para>
- <para>
+ <para>
+<!-- Remove comment when WL#2712 is implemented
The dynamic server system variable even allows you to set
replication logging on a per-connection basis. To enable
statement-based logging for a thread, rather than server-wide, you
@@ -322,7 +335,7 @@
<programlisting>
mysql> <userinput>SET LOCAL BINLOG_FORMAT = 1;</userinput>
</programlisting>
-
+-->
Here are two reasons why you would want to set replication logging
on a per-connection basis:
@@ -378,7 +391,7 @@
</para>
<para>
- There is another option you can use with RBR:
+ There is another option you can use with row-based replication:
<option>binlog-row-event-max-size</option>. Rows are stored into
the binlog in chunks not exceeding this value, which needs to be a
multiple of 256. If you don't specify that option, the default
@@ -4217,13 +4230,6 @@
<listitem>
<para>
- Faster to replicate, especially over slow network
- installations.
- </para>
- </listitem>
-
- <listitem>
- <para>
Log files contain all statements that made any changes,
which allow them to be used to audit the database.
</para>
@@ -4239,26 +4245,11 @@
<listitem>
<para>
- Less lock time when writing to the binary log. This
- increases concurrency and allows the master server to
- execute more statements per second.
- </para>
- </listitem>
-
- <listitem>
- <para>
Slave may be a newer version of MySQL with a different row
structure.
</para>
</listitem>
- <listitem>
- <para>
- Faster application of logs for update or delete statements
- on tables without primary keys.
- </para>
- </listitem>
-
</itemizedlist>
</para>
@@ -4269,7 +4260,11 @@
<listitem>
<para>
- Not all update statements can be replicated.
+ Not all update statements can be replicated:
+ Any non-deterministic behavior, for example when
+ using random functions in an SQL statement, is
+ hard to replicate when using statement-based
+ replication.
</para>
</listitem>
@@ -4390,20 +4385,28 @@
<listitem>
<para>
Everything can be replicated; safest form of replication.
+ Note that currently, DDL (data definition language)
+ statements such as <literal>CREATE TABLE</literal>
+ are replicated using statement-based replication,
+ while DML (data manipulation language) statements,
+ as well as <literal>GRANT</literal> and
+ <literal>REVOKE</literal> statements, are replicated
+ using row-based-replication.
</para>
</listitem>
<listitem>
<para>
Same technology as most other database management systems
- (easier to explain).
+ (easier to explain to database administrators used to other
+ systems).
</para>
</listitem>
-
+
<listitem>
<para>
- Faster to apply data on the slave on tables with primary
- keys.
+ In many cases, faster to apply data on the slave on tables
+ with primary keys.
</para>
</listitem>
@@ -4465,14 +4468,6 @@
<listitem>
<para>
- DDL statements (data definition language, like
- <literal>CREATE TABLE</literal>) are still replicated as
- statements.
- </para>
- </listitem>
-
- <listitem>
- <para>
Bigger log files (much bigger in some cases).
</para>
</listitem>
@@ -4486,15 +4481,19 @@
<listitem>
<para>
- The potential for concurrency problems exists when writing
- to the binary log for <literal>UPDATE</literal> or
- <literal>DELETE</literal> statements that change a lot of
- rows. (During update of the binary log, all other threads
- that have finished their statements have to wait for the
- binary log to be up to date before they can finish.)
+ When using row-based replication to replicate a statement
+ (for example, an <literal>UPDATE</literal> or
+ <literal>DELETE</literal> statement), each changed row has
+ to 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 a lot of rows,
+ row-based replication may write significantly more data to
+ the binary log. In these cases the binary log will be locked
+ for longer times to write the data, which may cause
+ concurrency problems.
</para>
</listitem>
-
+
<listitem>
<para>
Deterministic UDFs that generate big
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r658 - trunk/refman-5.1 | stefan | 4 Jan |
