Author: jstephens
Date: 2008-01-10 16:34:33 +0100 (Thu, 10 Jan 2008)
New Revision: 9549
Log:
Updated info about db-filtering rules in SBR vs RBR
Fixes Docs Bug #32605
(Thanks, Mats!)
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-01-10 15:30:41 UTC (rev 9548)
+++ trunk/refman-5.1/replication-configuration.xml 2008-01-10 15:34:33 UTC (rev 9549)
Changed blocks: 4, Lines Added: 165, Lines Deleted: 39; 10726 bytes
@@ -2612,17 +2612,29 @@
</para>
<para>
- Tell the slave to restrict replication to statements where the
- default database (that is, the one selected by
- <literal>USE</literal>) is <replaceable>db_name</replaceable>.
- To specify more than one database, use this option multiple
- times, once for each database. Note that this does not
- replicate cross-database statements such as <literal>UPDATE
- <replaceable>some_db.some_table</replaceable> SET
- foo='bar'</literal> while having selected a different database
- or no database.
+ The effects of this option depend on whether statement-based
+ or row-based replication is in use.
</para>
+ <formalpara>
+
+ <title>Statement-based replication</title>
+
+ <para>
+ Tell the slave to restrict replication to statements where
+ the default database (that is, the one selected by
+ <literal>USE</literal>) is
+ <replaceable>db_name</replaceable>. To specify more than one
+ database, use this option multiple times, once for each
+ database. Note that this does not replicate cross-database
+ statements such as <literal>UPDATE
+ <replaceable>some_db.some_table</replaceable> SET
+ foo='bar'</literal> while having selected a different
+ database or no database.
+ </para>
+
+ </formalpara>
+
<warning>
<para>
To specify multiple databases you <emphasis>must</emphasis>
@@ -2634,19 +2646,18 @@
</warning>
<para>
- An example of what does not work as you might expect: If the
- slave is started with <option>--replicate-do-db=sales</option>
- and you issue the following statements on the master, the
+ An example of what does not work as you might expect when
+ using statement-based replication: If the slave is started
+ with <option>--replicate-do-db=sales</option> and you issue
+ the following statements on the master, the
<literal>UPDATE</literal> statement is
<emphasis>not</emphasis> replicated:
- </para>
<programlisting>
USE prices;
UPDATE sales.january SET amount=amount+1000;
</programlisting>
- <para>
The main reason for this <quote>just check the default
database</quote> behavior is that it is difficult from the
statement alone to know whether it should be replicated (for
@@ -2657,7 +2668,86 @@
database rather than all databases if there is no need.
</para>
+ <formalpara>
+
+ <title>Row-based replication</title>
+
+ <para>
+ Tell the slave to restrict replication to database
+ <replaceable>db_name</replaceable>. Only tables belonging to
+ <replaceable>db_name</replaceable> are changed; the current
+ database has no effect on this. For example, suppose that
+ the slave is started with
+ <option>--replicate-do-db=sales</option> and row-based
+ replication is in effect; then the following statements are
+ run on the master:
+
+<programlisting>
+USE prices;
+UPDATE sales.february SET amount=amount+100;
+</programlisting>
+
+ The <literal>february</literal> table in the
+ <literal>sales</literal> database on the slave is changed in
+ accordance with the <literal>UPDATE</literal> statement, and
+ this takes place whether or not the <literal>USE</literal>
+ statement was issued. However, issuing the following
+ statements on the master has no effect on the slave when
+ using row-based replication and
+ <option>--replicate-do-db=sales</option>:
+
+<programlisting>
+USE prices;
+UPDATE prices.march SET amount=amount-25;
+</programlisting>
+
+ Even if the statement <literal>USE prices</literal> were
+ changed to <literal>USE sales</literal>, the
+ <literal>UPDATE</literal> statement's effects would
+ still not be replicated.
+ </para>
+
+ </formalpara>
+
<para>
+ Another importance difference in how
+ <option>--replicate-do-db</option> is handled in
+ statement-based replication as opposed to row-based
+ replication occurs with regard to statements that refer to
+ multiple databases. Suppose the slave is started with
+ <option>--replicate-do-db=db1</option>, and the following
+ statements are executed on the master:
+
+<programlisting>
+USE db1;
+UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
+</programlisting>
+
+ If you are using statement-based replication, then both tables
+ are updated on the slave. However, when using row-based
+ replication, only <literal>table1</literal> is effected on the
+ slave; since <literal>table2</literal> is in a different
+ database, it is not changed by the <literal>UPDATE</literal>.
+ Now suppose that, instead of the <literal>USE db1</literal>
+ statement, a <literal>USE db4</literal> statement was used:
+
+<programlisting>
+USE db4;
+UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
+</programlisting>
+
+ In this case, the <literal>UPDATE</literal> statement would
+ have no effect on the slave when using statement-based
+ replication. However, if using row-based replication, the
+ <literal>UPDATE</literal> would change
+ <literal>table1</literal> on the slave, but not
+ <literal>table2</literal> — in other words, only tables
+ in the database named by <option>--replicate-do-db</option>
+ are changed, and the choice of current database has no effect
+ on this behavior.
+ </para>
+
+ <para>
If you need cross-database updates to work, use
<option>--replicate-wild-do-table=<replaceable>db_name</replaceable>.%</option>
instead. See <xref linkend="replication-rules"/>.
@@ -2705,42 +2795,78 @@
</para>
<para>
- Tells the slave to not replicate any statement where the
- default database (that is, the one selected by
- <literal>USE</literal>) is <replaceable>db_name</replaceable>.
- To specify more than one database to ignore, use this option
- multiple times, once for each database. You should not use
- this option if you are using cross-database updates and you do
- not want these updates to be replicated. See
- <xref linkend="replication-rules"/>.
+ As with <option>--replicate-do-db</option>, the effects of
+ this option depend on whether statement-based or row-based
+ replication is in use.
</para>
+ <formalpara>
+
+ <title>Statement-based replication</title>
+
+ <para>
+ Tells the slave to not replicate any statement where the
+ default database (that is, the one selected by
+ <literal>USE</literal>) is
+ <replaceable>db_name</replaceable>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Row-based replication</title>
+
+ <para>
+ Tells the slave not to update any tables in the database
+ <replaceable>db_name</replaceable>. The current database has
+ no effect.
+ </para>
+
+ </formalpara>
+
<para>
- An example of what does not work as you might expect: If the
- slave is started with
- <option>--replicate-ignore-db=sales</option> and you issue the
- following statements on the master, the
- <literal>UPDATE</literal> statement <emphasis>is</emphasis>
- replicated:
- </para>
+ When using statement-based replication, the following example
+ does not work as you might expect. Suppose that the slave is
+ started with <option>--replicate-ignore-db=sales</option> and
+ you issue the following statements on the master:
<programlisting>
USE prices;
UPDATE sales.january SET amount=amount+1000;
</programlisting>
- <note>
- <para>
- In the preceding example the statement is replicated because
- <option>--replicate-ignore-db</option> only applies to the
- default database (set through the <literal>USE</literal>
- statement). Because the <literal>sales</literal> database
- was specified explicitly in the statement, the statement has
- not been filtered.
- </para>
- </note>
+ The <literal>UPDATE</literal> statement
+ <emphasis>is</emphasis> replicated in such a case because
+ <option>--replicate-ignore-db</option> applies only to the
+ default database (determined by the <literal>USE</literal>
+ statement). Because the <literal>sales</literal> database was
+ specified explicitly in the statement, the statement has not
+ been filtered. However, when using row-based replication, the
+ <literal>UPDATE</literal> statement's effects are
+ <emphasis>not</emphasis> propagated to the slave, and the
+ slave's copy of the <literal>sales.january</literal>
+ table is unchanged; in this instance,
+ <option>--replicate-ignore-db=sales</option> causes
+ <emphasis>all</emphasis> changes made to tables in the
+ master's copy of the <literal>sales</literal> database to
+ be ignored by the slave.
+ </para>
<para>
+ To specify more than one database to ignore, use this option
+ multiple times, once for each database. Because database names
+ can contain commas, if you supply a comma separated list then
+ the list will be treated as the name of a single database.
+ </para>
+
+ <para>
+ You should not use this option if you are using cross-database
+ updates and you do not want these updates to be replicated.
+ See <xref linkend="replication-rules"/>.
+ </para>
+
+ <para>
If you need cross-database updates to work, use
<option>--replicate-wild-ignore-table=<replaceable>db_name</replaceable>.%</option>
instead. See <xref linkend="replication-rules"/>.
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
--- trunk/refman-6.0/replication-configuration.xml 2008-01-10 15:30:41 UTC (rev 9548)
+++ trunk/refman-6.0/replication-configuration.xml 2008-01-10 15:34:33 UTC (rev 9549)
Changed blocks: 4, Lines Added: 165, Lines Deleted: 39; 10726 bytes
@@ -2585,17 +2585,29 @@
</para>
<para>
- Tell the slave to restrict replication to statements where the
- default database (that is, the one selected by
- <literal>USE</literal>) is <replaceable>db_name</replaceable>.
- To specify more than one database, use this option multiple
- times, once for each database. Note that this does not
- replicate cross-database statements such as <literal>UPDATE
- <replaceable>some_db.some_table</replaceable> SET
- foo='bar'</literal> while having selected a different database
- or no database.
+ The effects of this option depend on whether statement-based
+ or row-based replication is in use.
</para>
+ <formalpara>
+
+ <title>Statement-based replication</title>
+
+ <para>
+ Tell the slave to restrict replication to statements where
+ the default database (that is, the one selected by
+ <literal>USE</literal>) is
+ <replaceable>db_name</replaceable>. To specify more than one
+ database, use this option multiple times, once for each
+ database. Note that this does not replicate cross-database
+ statements such as <literal>UPDATE
+ <replaceable>some_db.some_table</replaceable> SET
+ foo='bar'</literal> while having selected a different
+ database or no database.
+ </para>
+
+ </formalpara>
+
<warning>
<para>
To specify multiple databases you <emphasis>must</emphasis>
@@ -2607,19 +2619,18 @@
</warning>
<para>
- An example of what does not work as you might expect: If the
- slave is started with <option>--replicate-do-db=sales</option>
- and you issue the following statements on the master, the
+ An example of what does not work as you might expect when
+ using statement-based replication: If the slave is started
+ with <option>--replicate-do-db=sales</option> and you issue
+ the following statements on the master, the
<literal>UPDATE</literal> statement is
<emphasis>not</emphasis> replicated:
- </para>
<programlisting>
USE prices;
UPDATE sales.january SET amount=amount+1000;
</programlisting>
- <para>
The main reason for this <quote>just check the default
database</quote> behavior is that it is difficult from the
statement alone to know whether it should be replicated (for
@@ -2630,7 +2641,86 @@
database rather than all databases if there is no need.
</para>
+ <formalpara>
+
+ <title>Row-based replication</title>
+
+ <para>
+ Tell the slave to restrict replication to database
+ <replaceable>db_name</replaceable>. Only tables belonging to
+ <replaceable>db_name</replaceable> are changed; the current
+ database has no effect on this. For example, suppose that
+ the slave is started with
+ <option>--replicate-do-db=sales</option> and row-based
+ replication is in effect; then the following statements are
+ run on the master:
+
+<programlisting>
+USE prices;
+UPDATE sales.february SET amount=amount+100;
+</programlisting>
+
+ The <literal>february</literal> table in the
+ <literal>sales</literal> database on the slave is changed in
+ accordance with the <literal>UPDATE</literal> statement, and
+ this takes place whether or not the <literal>USE</literal>
+ statement was issued. However, issuing the following
+ statements on the master has no effect on the slave when
+ using row-based replication and
+ <option>--replicate-do-db=sales</option>:
+
+<programlisting>
+USE prices;
+UPDATE prices.march SET amount=amount-25;
+</programlisting>
+
+ Even if the statement <literal>USE prices</literal> were
+ changed to <literal>USE sales</literal>, the
+ <literal>UPDATE</literal> statement's effects would
+ still not be replicated.
+ </para>
+
+ </formalpara>
+
<para>
+ Another importance difference in how
+ <option>--replicate-do-db</option> is handled in
+ statement-based replication as opposed to row-based
+ replication occurs with regard to statements that refer to
+ multiple databases. Suppose the slave is started with
+ <option>--replicate-do-db=db1</option>, and the following
+ statements are executed on the master:
+
+<programlisting>
+USE db1;
+UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
+</programlisting>
+
+ If you are using statement-based replication, then both tables
+ are updated on the slave. However, when using row-based
+ replication, only <literal>table1</literal> is effected on the
+ slave; since <literal>table2</literal> is in a different
+ database, it is not changed by the <literal>UPDATE</literal>.
+ Now suppose that, instead of the <literal>USE db1</literal>
+ statement, a <literal>USE db4</literal> statement was used:
+
+<programlisting>
+USE db4;
+UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
+</programlisting>
+
+ In this case, the <literal>UPDATE</literal> statement would
+ have no effect on the slave when using statement-based
+ replication. However, if using row-based replication, the
+ <literal>UPDATE</literal> would change
+ <literal>table1</literal> on the slave, but not
+ <literal>table2</literal> — in other words, only tables
+ in the database named by <option>--replicate-do-db</option>
+ are changed, and the choice of current database has no effect
+ on this behavior.
+ </para>
+
+ <para>
If you need cross-database updates to work, use
<option>--replicate-wild-do-table=<replaceable>db_name</replaceable>.%</option>
instead. See <xref linkend="replication-rules"/>.
@@ -2678,42 +2768,78 @@
</para>
<para>
- Tells the slave to not replicate any statement where the
- default database (that is, the one selected by
- <literal>USE</literal>) is <replaceable>db_name</replaceable>.
- To specify more than one database to ignore, use this option
- multiple times, once for each database. You should not use
- this option if you are using cross-database updates and you do
- not want these updates to be replicated. See
- <xref linkend="replication-rules"/>.
+ As with <option>--replicate-do-db</option>, the effects of
+ this option depend on whether statement-based or row-based
+ replication is in use.
</para>
+ <formalpara>
+
+ <title>Statement-based replication</title>
+
+ <para>
+ Tells the slave to not replicate any statement where the
+ default database (that is, the one selected by
+ <literal>USE</literal>) is
+ <replaceable>db_name</replaceable>.
+ </para>
+
+ </formalpara>
+
+ <formalpara>
+
+ <title>Row-based replication</title>
+
+ <para>
+ Tells the slave not to update any tables in the database
+ <replaceable>db_name</replaceable>. The current database has
+ no effect.
+ </para>
+
+ </formalpara>
+
<para>
- An example of what does not work as you might expect: If the
- slave is started with
- <option>--replicate-ignore-db=sales</option> and you issue the
- following statements on the master, the
- <literal>UPDATE</literal> statement <emphasis>is</emphasis>
- replicated:
- </para>
+ When using statement-based replication, the following example
+ does not work as you might expect. Suppose that the slave is
+ started with <option>--replicate-ignore-db=sales</option> and
+ you issue the following statements on the master:
<programlisting>
USE prices;
UPDATE sales.january SET amount=amount+1000;
</programlisting>
- <note>
- <para>
- In the preceding example the statement is replicated because
- <option>--replicate-ignore-db</option> only applies to the
- default database (set through the <literal>USE</literal>
- statement). Because the <literal>sales</literal> database
- was specified explicitly in the statement, the statement has
- not been filtered.
- </para>
- </note>
+ The <literal>UPDATE</literal> statement
+ <emphasis>is</emphasis> replicated in such a case because
+ <option>--replicate-ignore-db</option> applies only to the
+ default database (determined by the <literal>USE</literal>
+ statement). Because the <literal>sales</literal> database was
+ specified explicitly in the statement, the statement has not
+ been filtered. However, when using row-based replication, the
+ <literal>UPDATE</literal> statement's effects are
+ <emphasis>not</emphasis> propagated to the slave, and the
+ slave's copy of the <literal>sales.january</literal>
+ table is unchanged; in this instance,
+ <option>--replicate-ignore-db=sales</option> causes
+ <emphasis>all</emphasis> changes made to tables in the
+ master's copy of the <literal>sales</literal> database to
+ be ignored by the slave.
+ </para>
<para>
+ To specify more than one database to ignore, use this option
+ multiple times, once for each database. Because database names
+ can contain commas, if you supply a comma separated list then
+ the list will be treated as the name of a single database.
+ </para>
+
+ <para>
+ You should not use this option if you are using cross-database
+ updates and you do not want these updates to be replicated.
+ See <xref linkend="replication-rules"/>.
+ </para>
+
+ <para>
If you need cross-database updates to work, use
<option>--replicate-wild-ignore-table=<replaceable>db_name</replaceable>.%</option>
instead. See <xref linkend="replication-rules"/>.
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r9549 - in trunk: refman-5.1 refman-6.0 | jon | 10 Jan |
