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&gt; <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 &hellip; 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 &hellip; 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 &current-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 &hellip; 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 &hellip; 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&gt; <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>

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.