Author: shinz
Date: 2006-02-27 19:07:29 +0100 (Mon, 27 Feb 2006)
New Revision: 1452
Log:
Edits around binlog_format = statement/row/mixed (Lars)
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-02-27 16:52:05 UTC (rev 1451)
+++ trunk/refman-5.1/database-administration.xml 2006-02-27 18:07:29 UTC (rev 1452)
@@ -3709,7 +3709,7 @@
is set by the <option>--binlog-format</option> option at
startup, or by the <literal>binlog_format</literal>
variable at runtime (you need the <literal>SUPER</literal>
- privilege to set this globally). See
+ privilege to set this variable). See
<xref linkend="replication-row-based"/>. The startup
variable was added in MySQL 5.1.5, and the runtime
variable in MySQL 5.1.7. <literal>MIXED</literal> was
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2006-02-27 16:52:05 UTC (rev 1451)
+++ trunk/refman-5.1/replication.xml 2006-02-27 18:07:29 UTC (rev 1452)
@@ -244,27 +244,27 @@
<para>
Replication capabilities in MySQL originally were based on
propagation of SQL statements from master to slave. This is called
- <firstterm>statement-based replication</firstterm> (SBR). As of
- MySQL 5.1.5, another basis for replication is available. This is
- called <firstterm>row-based replication</firstterm> (RBR). Instead
- of sending SQL statements to the slave, the master writes events
- to its binary log that indicate how individual table rows are
- effected. As of MySQL 5.1.7, a third option is available: mixed.
- This will use statement-based replication by default, and only
- switch to row-based replication in particular cases as described
- below.
+ <emphasis>statement-based replication</emphasis>. As of MySQL
+ 5.1.5, another basis for replication is available. This is called
+ <emphasis>row-based replication</emphasis>. Instead of sending SQL
+ statements to the slave, the master writes events to its binary
+ log that indicate how individual table rows are effected. As of
+ MySQL 5.1.7, a third option is available: mixed. This will use
+ statement-based replication by default, and only switch to
+ row-based replication in particular cases as described below.
</para>
<para>
For a comparison that shows the advantages and disadvantages of
- SBR and RBR, see <xref linkend="replication-sbr-rbr"/>.
+ statement-based and row-based replication, see
+ <xref linkend="replication-sbr-rbr"/>.
</para>
<para>
With MySQL's classic statement-based replication, there may be
issues with replicating stored routines or triggers. You can avoid
- these issues by using MySQL's row-based replication (RBR) instead.
- For a detailed list of issues, see
+ these issues by using MySQL's row-based replication instead. For a
+ detailed list of issues, see
<xref linkend="stored-procedure-logging"/>.
</para>
@@ -331,12 +331,15 @@
<para>
Individual clients can control the logging format for their own
statements by setting the session value of
- <literal>binlog_format</literal>. For example:
+ <literal>binlog_format</literal>. Note that you need the
+ <literal>SUPER</literal> privilege for setting the session
+ variable. For example:
</para>
<programlisting>
mysql> <userinput>SET SESSION binlog_format = 'STATEMENT';</userinput>
mysql> <userinput>SET SESSION binlog_format = 'ROW';</userinput>
+mysql> <userinput>SET SESSION binlog_format = 'MIXED';</userinput>
</programlisting>
<para>
@@ -398,39 +401,20 @@
</para>
<para>
- Row-based replication causes <emphasis>most</emphasis> changes to
- be written to the binary log using the row-based format. Some
- changes, however, must be written to the binary log as statements:
+ With the binlog format set to <literal>ROW</literal>, many changes
+ are written to the binary log using the row-based format. Some
+ changes, however, still use the statement-based format. Examples
+ include all DDL (data definition language) statements such as
+ <literal>CREATE TABLE</literal>, <literal>ALTER TABLE</literal>,
+ or <literal>DROP TABLE</literal>.
</para>
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>ANALYZE TABLE</literal>
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>REPAIR TABLE</literal>
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>OPTIMIZE TABLE</literal>
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
- The <option>--binlog-row-event-max-size</option> is available for
- servers that are capabile of row-based replication. Rows are
- stored into the binary log in chunks having a size in bytes not
- exceeding the value of this option. The value must be a multiple
- of 256. The default value is 1024.
+ The <option>--binlog-row-event-max-size</option> option is
+ available for servers that are capable of row-based replication.
+ Rows are stored into the binary log in chunks having a size in
+ bytes not exceeding the value of this option. The value must be a
+ multiple of 256. The default value is 1024.
</para>
</section>
@@ -1811,8 +1795,8 @@
<para>
With MySQL's classic statement-based replication, there may be
issues with replicating stored routines or triggers. You can avoid
- these issues by using MySQL's row-based replication (RBR) instead.
- For a detailed list of issues, see
+ these issues by using MySQL's row-based replication instead. For a
+ detailed list of issues, see
<xref linkend="stored-procedure-logging"/>. For a description of
row-based replication, see
<xref linkend="replication-row-based"/>.
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1452 - trunk/refman-5.1 | stefan | 27 Feb |
