List:Commits« Previous MessageNext Message »
From:jon Date:January 30 2006 1:48pm
Subject:svn commit - mysqldoc@docsrva: r1121 - trunk/refman-5.1
View as plain text  
Author: jstephens
Date: 2006-01-30 14:48:06 +0100 (Mon, 30 Jan 2006)
New Revision: 1121

Log:

Version-specific fixes in light of RBR, etc. (Thanks, Guilhelm!)



Modified:
   trunk/refman-5.1/replication.xml

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-30 04:32:31 UTC (rev 1120)
+++ trunk/refman-5.1/replication.xml	2006-01-30 13:48:06 UTC (rev 1121)
@@ -1783,7 +1783,9 @@
         <para>
           The <literal>USER()</literal>, <literal>UUID()</literal>, and
           <literal>LOAD_FILE()</literal> functions are replicated
-          without change and thus do not work reliably on the slave.
+          without change and thus do not work reliably on the slave
+          unless row-based replication is enabled. (See 
+          <xref linkend="replication-row-based"/>.)
         </para>
       </listitem>
 
@@ -1809,19 +1811,22 @@
           The <literal>FOREIGN_KEY_CHECKS</literal>,
           <literal>SQL_MODE</literal>, <literal>UNIQUE_CHECKS</literal>,
           and <literal>SQL_AUTO_IS_NULL</literal> variables are all
-          replicated in MySQL &current-series;. The
+          replicated (this has been true since MySQL 5.0). The
           <literal>storage_engine</literal> system variable (also known
-          as <literal>table_type</literal>) is not yet replicated, which
-          is a good thing for replication between different storage
-          engines.
+          as <literal>table_type</literal>) is not yet replicated in
+          MySQL 5.1, which is a good thing for replication between
+          different storage engines.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          Replication works even if the master and slave have different
-          global character set variables, and even if the master and
-          slave have different global timezone variables.
+          Replication works correctly between MySQL 5.0 and 5.1 masters
+          and slaves in any combination, even if the master and slave
+          have different global character set variables, and even if the          
+          master and slave have different global timezone variables.
+          (Note that this is not true in cases where the master, slave,
+          or both are running MySQL 4.1 or earlier.)
         </para>
       </listitem>
 
@@ -1835,14 +1840,18 @@
 
           <listitem>
             <para>
-              You must <emphasis>always</emphasis> use the same
+              If the master uses MySQL 4.1, you must
+              <emphasis>always</emphasis> use the same
               <emphasis>global</emphasis> character set and collation on
-              the master and the slave. (These are controlled by the
+              the master and the slave, regardless of the MySQL version
+              running on the slave. (These are controlled by the
               <option>--character-set-server</option> and
               <option>--collation-server</option> options.) Otherwise,
               you may get duplicate-key errors on the slave, because a
               key that is unique in the master character set might not
-              be unique in the slave character set.
+              be unique in the slave character set. Note that this is
+              not a cause for concern where master and slave are both
+              MySQL 5.0 or later.
             </para>
           </listitem>
 
@@ -1893,28 +1902,27 @@
 
       <listitem>
         <para>
-          The same system time zone should be set for both master and
-          slave. Otherwise some statements will not be replicated
-          properly, such as statements that use the
-          <literal>NOW()</literal> or <literal>FROM_UNIXTIME()</literal>
-          functions. You can set the time zone in which MySQL server
-          runs by using the
+          If the master uses MySQL 4.1, then the same system time zone
+          should be set for both master and slave. Otherwise some
+          statements will not be replicated properly, such as statements
+          that use the <literal>NOW()</literal> or
+          <literal>FROM_UNIXTIME()</literal> functions. You can set the
+          time zone in which MySQL server runs by using the
           <option>--timezone=<replaceable>timezone_name</replaceable></option>
           option of the <filename>mysqld_safe</filename> script or by
           setting the <literal>TZ</literal> environment variable. Both
           master and slave should also have the same default connection
           time zone setting; that is, the
           <option>--default-time-zone</option> parameter should have the
-          same value for both master and slave.
+          same value for both master and slave. Note that this is not
+          necessary where the master is MySQL 5.0 or later.
         </para>
       </listitem>
 
       <listitem>
         <para>
-          <literal>CONVERT_TZ(...,...,@global.time_zone)</literal> is
-          not properly replicated.
           <literal>CONVERT_TZ(...,...,@session.time_zone)</literal> is
-          properly replicated only if the master and slave are from
+          properly replicated only if both master and slave are running
           MySQL 5.0.4 or newer.
         </para>
       </listitem>
@@ -1930,6 +1938,12 @@
           followed by <literal>INSERT INTO mytable
           VALUES(CONVERT_TZ(...,...,@time_zone))</literal>.
         </para>
+        
+        <para>
+          Replication of session variables is not a problem where
+          row-based replication is being used. See 
+          <xref linkend="replication-row-based"/>.
+        </para>
       </listitem>
 
       <listitem>
@@ -1959,11 +1973,11 @@
           Update statements that refer to user-defined variables (that
           is, variables of the form
           <literal>@<replaceable>var_name</replaceable></literal>) are
-          replicated correctly in MySQL &current-series;; however this
-          is not true for versions prior to 4.1. Note that user variable
-          names are case insensitive starting in MySQL 5.0. you should
-          take this into account when setting up replication between
-          MySQL 5.0 and older versions.
+          replicated correctly; however this is not true for versions
+          prior to 4.1. Note that user variable names are case
+          insensitive starting in MySQL 5.0. you should take this into
+          account when setting up replication between MySQL 5.0 and
+          older versions.
         </para>
       </listitem>
 
@@ -1975,20 +1989,22 @@
 
       <listitem>
         <para>
-          There is a global system variable
-          <literal>slave_transaction_retries</literal>: If the
-          replication slave SQL thread fails to execute a transaction
-          because of an <literal>InnoDB</literal> deadlock or because it
-          exceeded the <literal>InnoDB</literal>
-          <literal>innodb_lock_wait_timeout</literal> or the NDBCluster
+          The global system variable
+          <literal>slave_transaction_retries</literal> affects
+          replicaiton as follows: If the replication slave SQL thread
+          fails to execute a transaction because of an
+          <literal>InnoDB</literal> deadlock or because it exceeded the
+          <literal>InnoDB</literal> 
+          <literal>innodb_lock_wait_timeout</literal> value, or the
+          <literal>NDBCluster</literal>
           <literal>TransactionDeadlockDetectionTimeout</literal> or
           <literal>TransactionInactiveTimeout</literal> value, the
-          transaction automatically retries
+          transaction is automatically retried
           <literal>slave_transaction_retries</literal> times before
-          stopping with an error. The default value is 10. Starting from
-          MySQL 5.0.4, the total retry count can be seen in the output
-          of <literal>SHOW STATUS</literal>; see
-          <xref linkend="server-status-variables"/>.
+          stopping with an error. The default value is 10. The total
+          retry count can be seen in the output of <literal>SHOW
+            STATUS</literal>; see 
+          <xref linkend="server-status-variables"/>. 
         </para>
       </listitem>
 
@@ -2016,10 +2032,11 @@
           replication only, not to row-based replication</emphasis>: It
           is possible for the data on the master and slave to become
           different if a query is designed in such a way that the data
-          modification is non-deterministic; that is, left to the will
-          of the query optimizer. (This is in general not a good
-          practice, even outside of replication.) For a detailed
-          explanation of this issue, see <xref linkend="open-bugs"/>.
+          modification is <firstterm>non-deterministic</firstterm>; that
+          is, it is left to the will of the query optimizer. (This is in
+          general not a good practice, even outside of replication.) For
+          a detailed explanation of this issue, see 
+          <xref linkend="open-bugs"/>.
         </para>
       </listitem>
 
@@ -2078,6 +2095,13 @@
 
       <listitem>
         <para>
+          Note that the following item does not apply where row-based
+          replication is in use, as row-based replication does not
+          require that temporary tables be replicated at all. (See 
+          <xref linkend="replication-row-based"/>.)
+        </para>
+        
+        <para>
           Temporary tables are replicated except in the case where you
           shut down the slave server (not just the slave threads) and
           you have replicated temporary tables that are used in updates
@@ -2126,7 +2150,12 @@
           </listitem>
 
         </orderedlist>
-
+        
+        <remark role="note">
+          [js] Ive commented this out, since RBR fixes the problem,
+          correct?
+        </remark>
+<!--
         <remark role="todo">
           [pd] Is this a promise we should make?
         </remark>
@@ -2134,6 +2163,7 @@
         <para>
           We plan to fix this problem in the near future.
         </para>
+-->
       </listitem>
 
       <listitem>
@@ -2219,12 +2249,16 @@
           See <xref linkend="binary-log"/>.
         </para>
 
+        <remark role="todo">
+          [js] Cut next para altogether, since the option was made
+          obsolete in the previous release series?
+        </remark>
+        
         <para>
-          <emphasis
-            role="bold">Note</emphasis>:
+          <emphasis role="bold">Note</emphasis>:
           <option>--innodb-safe-binlog</option> is not needed in MySQL
-          &current-series;, having been made obsolete by the
-          introduction of XA transaction support.
+          5.1, having been made obsolete by the introduction of XA
+          transaction support in MySQL 5.0. See <xref linkend="xa"/>.
         </para>
       </listitem>
 

Thread
svn commit - mysqldoc@docsrva: r1121 - trunk/refman-5.1jon30 Jan