MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:jon Date:January 10 2008 3:34pm
Subject:svn commit - mysqldoc@docsrva: r9549 - in trunk: refman-5.1 refman-6.0
View as plain text  
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&apos;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> &mdash; 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&apos;s effects are
+          <emphasis>not</emphasis> propagated to the slave, and the
+          slave&apos;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&apos;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&apos;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> &mdash; 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&apos;s effects are
+          <emphasis>not</emphasis> propagated to the slave, and the
+          slave&apos;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&apos;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.0jon10 Jan