Author: shinz
Date: 2005-12-20 16:55:16 +0100 (Tue, 20 Dec 2005)
New Revision: 602
Log:
Removal of RBR in 4.1 manual (forgot to press CTRL+S in editor)
Modified:
trunk/refman-4.1/replication.xml
trunk/refman-5.0/replication.xml
trunk/refman-5.1/replication.xml
Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml 2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-4.1/replication.xml 2005-12-20 15:55:16 UTC (rev 602)
@@ -1514,16 +1514,6 @@
and the version to which you are upgrading.
</para>
-<!-- Remove the comment when we have RBR in place.
- <para>
- Note that downgrading a replication setup to a previous version
- cannot be done once you've switched from statement-based to
- row-based replication, and after the first row-based statement
- has been written to the binlog. See
- <xref linkend="replication-row-based"/>.
- </para>
--->
-
<section id="replication-upgrade-4-0">
<title>&title-replication-upgrade-4-0;</title>
@@ -4155,258 +4145,8 @@
create your own monitoring tools.
</para>
-<!-- Remove the comment when we have RBR in place.
- <para>
- <emphasis role="bold">Q</emphasis>:
- How do I tell which format I'm currently running (row-based or
- statement-based)?
- </para>
- <para>
- <emphasis role="bold">A</emphasis>:
- By issuing this statement:
- </para>
-<programlisting>
-mysql> <userinput>SHOW VARIABLES LIKE "%binlog_format%";</userinput>
-</programlisting>
-
- <para>
- <emphasis role="bold">Q</emphasis>:
- How do I tell the slave to use row-based replication?
- </para>
- <para>
- <emphasis role="bold">A</emphasis>:
- The slave automatically knows which format it should use.
- </para>
--->
-
</section>
-<!-- Remove comment when we have RBR in place
- <section id="replication-sbr-rbr">
- <title>&title-replication-sbr-rbr;</title>
-
- <para>
- Advantages of statement-based replication are:
- <itemizedlist>
- <listitem><para>
- Proven technology (existed in MySQL since 3.23).
- </para></listitem>
- <listitem><para>
- Smaller log files (when using updates or deletes that affects
- many rows, much smaller log files). Because log files are
- smaller, they take up less storage space and are faster to
- back up.
- </para></listitem>
- <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></listitem>
- <listitem><para>
- Log files don't contain statements that were rolled back
- (when using only transactional tables).
- </para></listitem>
- <listitem><para>
- Log files can be used for point-in-time recovery, not just for
- replication purposes.
- See <xref linkend="point-in-time-recovery"/>.
- </para></listitem>
- <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>
- One can use different storage engines for tables on master and
- slave.
- See <xref linkend="storage-engines"/>.
- </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>
- <listitem><para>
- Circular replication (especially with incremental updates) can
- be done without conflicts. With row level replication, this is
- impossible to do in some cases.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Disadvantages of statement-based replication are:
- <itemizedlist>
- <listitem><para>
- Not all update statements can be replicated.
- </para></listitem>
- <listitem><para>
- Statements that use a UDF (user defined function) which is
- non-deterministic (value depends on other things than the
- given parameters) cannot be replicated properly.
- </para></listitem>
- <listitem><para>
- Statements that use one of the following functions cannot
- be replicated properly:
- <itemizedlist>
- <listitem><para>
- <literal>LOAD_FILE()</literal>
- </para></listitem>
- <listitem><para>
- <literal>UUID()</literal>
- </para></listitem>
- <listitem><para>
- <literal>USER()</literal>
- </para></listitem>
- <listitem><para>
- <literal>FOUND_ROWS()</literal>
- </para></listitem>
- All other functions are replicated correctly
- (including <literal>RAND()</literal>,
- <literal>NOW()</literal>,
- <literal>LOAD DATA INFILE</literal>, an so forth).
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <literal>INSERT … SELECT</literal> requires more
- row-level locks than with row-level replication.
- </para></listitem>
- <listitem><para>
- <literal>UPDATE</literal> statements that require a table scan
- (that is don't use indexes in the <literal>WHERE</literal>
- clause) have to lock more rows than with row-level replication.
- </para></listitem>
- <listitem><para>
- For InnoDB: An <literal>INSERT</literal> statement that uses
- <literal>auto_increment</literal> will block other
- non-conflicting <literal>INSERT</literal> statements.
- </para></listitem>
- <listitem><para>
- Slower to apply data on slave for complex queries.
- </para></listitem>
- <listitem><para>
- <literal>INSERT</literal> statements that use only constants
- are slightly slower to apply (probably barely measurable).
- </para></listitem>
- <listitem><para>
- Stored functions (not stored procedures) will execute with the
- same <literal>NOW()</literal> value as the calling statement.
- (This may be regarded both as a bad and a good thing.)
- </para></listitem>
- <listitem><para>
- Stored functions must be replicated to the slave.
- </para></listitem>
- <listitem><para>
- Deterministic UDFs (user-defined functions) must be applied on
- the slaves.
- </para></listitem>
- <listitem><para>
- You can only use one thread to apply data on the slave
- (slow with many disks, CPUs).
- </para></listitem>
- <listitem><para>
- When getting something wrong on the slave, the difference
- between master and slave will grow with time.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Advantages of row-level replication are:
- <itemizedlist>
- <listitem><para>
- Everything can be replicated; safest form of replication.
- </para></listitem>
- <listitem><para>
- Same technology as most other database management systems
- (easier to explain).
- </para></listitem>
- <listitem><para>
- Faster to apply data on the slave on tables with primary keys.
- </para></listitem>
- <listitem><para>
- Less locks needed (thus higher concurrency) on the master for:
- <itemizedlist>
- <listitem><para>
- <literal>INSERT … SELECT</literal>
- </para></listitem>
- <listitem><para>
- <literal>INSERT</literal> statements with
- <literal>auto_increment</literal>
- </para></listitem>
- <listitem><para>
- <literal>UPDATE</literal> or <literal>DELETE</literal>
- statements with <literal>WHERE</literal> clauses that don't
- use keys or don't change most of the examined rows.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- Less locks on the slave for any <literal>INSERT</literal>,
- <literal>UPDATE</literal>, or <literal>DELETE</literal>
- statement.
- </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>
-
- <para>
- Disadvantages of row-level replication are:
- <itemizedlist>
- <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>
- <listitem><para>
- Binary log will contain data for large statements that were
- rolled back.
- </para></listitem>
- <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.)
- </para></listitem>
- <listitem><para>
- Deterministic UDFs that generate big <literal>BLOB</literal>s
- will be notably slower to replicate.
- </para></listitem>
- <listitem><para>
- Interlaced updates (will be used for updates/deletes that change a lot of rows) will require more resources to apply.
- </para></listitem>
- <listitem><para>
- Tables have to be (almost) identical on master and slave.
- </para></listitem>
- <listitem><para>
- It can be much slower to apply changes to tables without a
- primary key.
- </para></listitem>
- <listitem><para>
- One can't examine the logs to see what statements were executed.
- </para></listitem>
- <listitem><para>
- One can't see on the slave what statements were received from
- the master and executed.
- </para></listitem>
- </itemizedlist>
- </para>
--->
-
<section id="replication-problems">
<title>&title-replication-problems;</title>
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-5.0/replication.xml 2005-12-20 15:55:16 UTC (rev 602)
@@ -91,38 +91,7 @@
updates that they make to tables on the slave.
</para>
-<!-- Remove the previous paragraph and replace it with the following
- one when we have RBR in place:
<para>
- Note that when you are using replication, all updates to the
- tables that are replicated should be performed on the master
- server. Otherwise, you must always be careful to avoid conflicts
- between updates that users make to tables on the master and
- updates that they make to tables on the slave.
- When performing updates on the slaves's side you should also keep
- in mind that these might work with statement-based replication,
- but not with row-based replication. Consider the following
- scenario, where a record is inserted on the slave, followed by a
- statement on the master's side that should empty the table:
- <programlisting>
- slave> INSERT INTO tbl VALUES (1);
- master> DELETE FROM tbl;
-</programlisting>
- The master doesn't know about the <literal>INSERT</literal>
- operation on the slave server, but with statement-based
- replication, <literal>tbl</literal> will still be empty on both
- master and slave as soon as the slave catches up with the master,
- because the slave simply echoes the master's
- <literal>DELETE</literal> statement.
- With row-based replication, however, the master will write to its
- binlog the rows that were deleted in the master's table, and
- because it doesn't know about the slave's operations, this will
- <emphasis>not</emphasis> include the record inserted on the slave.
- As a consequence, replication will break.
- </para>
- -->
-
- <para>
One-way replication has benefits for robustness, speed, and system
administration:
</para>
@@ -237,129 +206,6 @@
</section>
-<!-- Uncomment when RBR is in place
- Remember to uncomment the - -binlog-format item in
- database-administration.xml, too!
- <section id="replication-row-based">
- <title>
- &title-replication-row-based;
- </title>
- <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 <xref linkend="stored-procedure-logging"/>.
- </para>
- <para>
- Note that in MySQL ¤t-series; RBR is only available in the
- <literal>-max</literal> builds.
- </para>
- <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.
- </para>
- <para>
- Even with row-based replication enabled, MySQL will still default
- to using statement-based replication. If you want to use row-based
- replication instead, you have to start the MySQL server with this
- option:
-<programlisting>
-- -binlog-format=row
-</programlisting>
- This enables row-based replication
- <emphasis>server-wide</emphasis>, and automatically turns on
- <option>innodb_locks_unsafe_for_binlog</option> as it is safe in
- this case.
- </para>
- <para>
- Setting <option>- -binlog-format=row</option> has the same effect
- as setting the dynamic server system variable
- <literal>BINLOG_FORMAT</literal> to a value of
- <literal>ROW</literal>, like this:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'ROW';</userinput>
-</programlisting>
- Alternatively, you can set it to a value of <literal>2</literal>:
-<programlisting>
-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> 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 server
- system variable, like this:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 'STMT';</userinput>
-</programlisting>
- Alternatively, you can set it to a value of <literal>1</literal>:
-<programlisting>
-mysql> <userinput>SET GLOBAL BINLOG_FORMAT = 1;</userinput>
-</programlisting>
- </para>
- <para>
- 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 would issue:
-<programlisting>
-mysql> <userinput>SET LOCAL BINLOG_FORMAT = 'STMT';</userinput>
-</programlisting>
- Alternatively, you can set it to a value of <literal>1</literal>:
-<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:
- <itemizedlist>
- <listitem>
- <para>
- A thread that does a lot of small changes to the database might
- want to use row-based logging, while a thread that does a lot of
- heavy-duty searching might want to use statement-based logging.
- </para>
- </listitem>
- <listitem>
- <para>
- Some statements require a lot of execution on the master, but
- create a small result set. It might therefore be beneficial to
- replicated them row-based.
- </para>
- </listitem>
- </itemizedlist>
- </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, will
- still be written into the binary log as statements:
- <itemizedlist>
- <listitem><para>
- <literal>ANALYZE</literal>
- </para></listitem>
- <listitem><para>
- <literal>REPAIR</literal>
- </para></listitem>
- <listitem><para>
- <literal>OPTIMIZE</literal>
- </para></listitem>
- </itemizedlist>
- </para>
- <para>
- There is another option you can use with RBR:
- <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
- value will be 1024.
- </para>
- </section>
--->
-
<section id="replication-implementation-details">
<title>&title-replication-implementation-details;</title>
@@ -1644,16 +1490,6 @@
the downgrade.
</para>
-<!-- Remove the comment when we have RBR in place.
- <para>
- Note that downgrading a replication setup to a previous version
- cannot be done once you've switched from statement-based to
- row-based replication, and after the first row-based statement
- has been written to the binlog. See
- <xref linkend="replication-row-based"/>.
- </para>
--->
-
</section>
</section>
@@ -1714,19 +1550,6 @@
described in <xref linkend="stored-procedure-logging"/>.
</para>
-<!-- Remove the previous paragraph and replace it with the following
- one when we have RBR in place:
- <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 <xref linkend="stored-procedure-logging"/>.
- For a description of row-based replication, see
- <xref linkend="replication-row-based"/>.
- </para>
--->
-
<itemizedlist>
<listitem>
@@ -4186,232 +4009,6 @@
</section>
-<!-- Remove comment when we have RBR in place
- <section id="replication-sbr-rbr">
- <title>&title-replication-sbr-rbr;</title>
-
- <para>
- Advantages of statement-based replication are:
- <itemizedlist>
- <listitem><para>
- Proven technology (existed in MySQL since 3.23).
- </para></listitem>
- <listitem><para>
- Smaller log files (when using updates or deletes that affects
- many rows, much smaller log files). Because log files are
- smaller, they take up less storage space and are faster to
- back up.
- </para></listitem>
- <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></listitem>
- <listitem><para>
- Log files don't contain statements that were rolled back
- (when using only transactional tables).
- </para></listitem>
- <listitem><para>
- Log files can be used for point-in-time recovery, not just for
- replication purposes.
- See <xref linkend="point-in-time-recovery"/>.
- </para></listitem>
- <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>
- One can use different storage engines for tables on master and
- slave.
- See <xref linkend="storage-engines"/>.
- </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>
- <listitem><para>
- Circular replication (especially with incremental updates) can
- be done without conflicts. With row level replication, this is
- impossible to do in some cases.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Disadvantages of statement-based replication are:
- <itemizedlist>
- <listitem><para>
- Not all update statements can be replicated.
- </para></listitem>
- <listitem><para>
- Statements that use a UDF (user defined function) which is
- non-deterministic (value depends on other things than the
- given parameters) cannot be replicated properly.
- </para></listitem>
- <listitem><para>
- Statements that use one of the following functions cannot
- be replicated properly:
- <itemizedlist>
- <listitem><para>
- <literal>LOAD_FILE()</literal>
- </para></listitem>
- <listitem><para>
- <literal>UUID()</literal>
- </para></listitem>
- <listitem><para>
- <literal>USER()</literal>
- </para></listitem>
- <listitem><para>
- <literal>FOUND_ROWS()</literal>
- </para></listitem>
- All other functions are replicated correctly
- (including <literal>RAND()</literal>,
- <literal>NOW()</literal>,
- <literal>LOAD DATA INFILE</literal>, an so forth).
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- <literal>INSERT … SELECT</literal> requires more
- row-level locks than with row-level replication.
- </para></listitem>
- <listitem><para>
- <literal>UPDATE</literal> statements that require a table scan
- (that is don't use indexes in the <literal>WHERE</literal>
- clause) have to lock more rows than with row-level replication.
- </para></listitem>
- <listitem><para>
- For InnoDB: An <literal>INSERT</literal> statement that uses
- <literal>auto_increment</literal> will block other
- non-conflicting <literal>INSERT</literal> statements.
- </para></listitem>
- <listitem><para>
- Slower to apply data on slave for complex queries.
- </para></listitem>
- <listitem><para>
- <literal>INSERT</literal> statements that use only constants
- are slightly slower to apply (probably barely measurable).
- </para></listitem>
- <listitem><para>
- Stored functions (not stored procedures) will execute with the
- same <literal>NOW()</literal> value as the calling statement.
- (This may be regarded both as a bad and a good thing.)
- </para></listitem>
- <listitem><para>
- Stored functions must be replicated to the slave.
- </para></listitem>
- <listitem><para>
- Deterministic UDFs (user-defined functions) must be applied on
- the slaves.
- </para></listitem>
- <listitem><para>
- You can only use one thread to apply data on the slave
- (slow with many disks, CPUs).
- </para></listitem>
- <listitem><para>
- When getting something wrong on the slave, the difference
- between master and slave will grow with time.
- </para></listitem>
- </itemizedlist>
- </para>
-
- <para>
- Advantages of row-level replication are:
- <itemizedlist>
- <listitem><para>
- Everything can be replicated; safest form of replication.
- </para></listitem>
- <listitem><para>
- Same technology as most other database management systems
- (easier to explain).
- </para></listitem>
- <listitem><para>
- Faster to apply data on the slave on tables with primary keys.
- </para></listitem>
- <listitem><para>
- Less locks needed (thus higher concurrency) on the master for:
- <itemizedlist>
- <listitem><para>
- <literal>INSERT … SELECT</literal>
- </para></listitem>
- <listitem><para>
- <literal>INSERT</literal> statements with
- <literal>auto_increment</literal>
- </para></listitem>
- <listitem><para>
- <literal>UPDATE</literal> or <literal>DELETE</literal>
- statements with <literal>WHERE</literal> clauses that don't
- use keys or don't change most of the examined rows.
- </para></listitem>
- </itemizedlist>
- </para></listitem>
- <listitem><para>
- Less locks on the slave for any <literal>INSERT</literal>,
- <literal>UPDATE</literal>, or <literal>DELETE</literal>
- statement.
- </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>
-
- <para>
- Disadvantages of row-level replication are:
- <itemizedlist>
- <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>
- <listitem><para>
- Binary log will contain data for large statements that were
- rolled back.
- </para></listitem>
- <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.)
- </para></listitem>
- <listitem><para>
- Deterministic UDFs that generate big <literal>BLOB</literal>s
- will be notably slower to replicate.
- </para></listitem>
- <listitem><para>
- Interlaced updates (will be used for updates/deletes that change a lot of rows) will require more resources to apply.
- </para></listitem>
- <listitem><para>
- Tables have to be (almost) identical on master and slave.
- </para></listitem>
- <listitem><para>
- It can be much slower to apply changes to tables without a
- primary key.
- </para></listitem>
- <listitem><para>
- One can't examine the logs to see what statements were executed.
- </para></listitem>
- <listitem><para>
- One can't see on the slave what statements were received from
- the master and executed.
- </para></listitem>
- </itemizedlist>
- </para>
--->
-
<section id="replication-problems">
<title>&title-replication-problems;</title>
@@ -4661,30 +4258,6 @@
with as much information as possible.
</para>
-<!-- Uncomment when RBR is in place
- <para>
- <emphasis role="bold">Q</emphasis>:
- How do I tell which format I'm currently running (row-based or
- statement-based)?
- </para>
- <para>
- <emphasis role="bold">A</emphasis>:
- By issuing this statement:
- </para>
-<programlisting>
-mysql> <userinput>SHOW VARIABLES LIKE "%binlog_format%";</userinput>
-</programlisting>
-
- <para>
- <emphasis role="bold">Q</emphasis>:
- How do I tell the slave to use row-based replication?
- </para>
- <para>
- <emphasis role="bold">A</emphasis>:
- The slave automatically knows which format it should use.
- </para>
--->
-
</section>
<section id="replication-auto-increment">
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2005-12-20 14:42:37 UTC (rev 601)
+++ trunk/refman-5.1/replication.xml 2005-12-20 15:55:16 UTC (rev 602)
@@ -92,7 +92,7 @@
</para>
<!-- Remove the previous paragraph and replace it with the following
- one when we have RBR in place:
+ one when we have RBR in place:
<para>
Note that when you are using replication, all updates to the
tables that are replicated should be performed on the master
@@ -104,9 +104,9 @@
but not with row-based replication. Consider the following
scenario, where a record is inserted on the slave, followed by a
statement on the master's side that should empty the table:
- <programlisting>
- slave> INSERT INTO tbl VALUES (1);
- master> DELETE FROM tbl;
+<programlisting>
+slave> INSERT INTO tbl VALUES (1);
+master> DELETE FROM tbl;
</programlisting>
The master doesn't know about the <literal>INSERT</literal>
operation on the slave server, but with statement-based
@@ -1640,8 +1640,8 @@
the downgrade.
</para>
-<!-- Remove the comment when we have RBR in place.
- <para>
+<!-- Uncomment when RBR is in place
+ <para>
Note that downgrading a replication setup to a previous version
cannot be done once you've switched from statement-based to
row-based replication, and after the first row-based statement
@@ -4179,8 +4179,8 @@
</section>
-<!-- Remove comment when we have RBR in place
- <section id="replication-sbr-rbr">
+<!-- Uncomment when RBR is in place
+ <section id="replication-sbr-rbr">
<title>&title-replication-sbr-rbr;</title>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r602 - in trunk: refman-4.1 refman-5.0 refman-5.1 | stefan | 20 Dec |
