List:Commits« Previous MessageNext Message »
From:jon.stephens Date:September 3 2009 10:30am
Subject:svn commit - mysqldoc@docsrva: r16418 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-5.4
View as plain text  
Author: jstephens
Date: 2009-09-03 12:30:11 +0200 (Thu, 03 Sep 2009)
New Revision: 16418

Log:

Fixes Docs Bug #47084 (Susanne -- CSC#40011)



Modified:
   trunk/refman-4.1/replication.xml
   trunk/refman-5.0/replication-notes.xml
   trunk/refman-5.1/replication-notes.xml
   trunk/refman-5.4/replication-notes.xml


Modified: trunk/refman-4.1/replication.xml
===================================================================
--- trunk/refman-4.1/replication.xml	2009-09-03 07:17:25 UTC (rev 16417)
+++ trunk/refman-4.1/replication.xml	2009-09-03 10:30:11 UTC (rev 16418)
Changed blocks: 2, Lines Added: 9, Lines Deleted: 5; 1812 bytes

@@ -1878,11 +1878,15 @@
           can set the time zone in which MySQL server runs by using the
           <option role="mysqld_safe">--timezone=<replaceable>timezone_name</replaceable></option>
           option of the <filename>mysqld_safe</filename> script or by
-          setting the <literal>TZ</literal> environment variable. Also
-          starting from version 4.1.3 both master and slave should have
+          setting the <literal>TZ</literal> environment variable.
+        </para>
+
+        <para>
+          Starting with MySQL 4.1.3, both master and slave should have
           the same default connection time zone set, that is the
           <option role="mysqld">--default-time-zone</option> parameter
-          should have the same value for both master and slave.
+          should have the same value for both master and slave. However,
+          if the master runs MySQL 5.0 or later, this is not necessary.
         </para>
       </listitem>
 

@@ -2615,8 +2619,8 @@
         <para>
           In 3.23, <literal role="func">RAND()</literal> in updates does
           not replicate properly. Use
-          <literal role="func">RAND(some_non_rand_expr)</literal> if you
-          are replicating updates with
+          <literal role="func">RAND(<replaceable>determinstic_expression</replaceable>)</literal>
+          if you are replicating updates with
           <literal role="func">RAND()</literal>. You can, for example,
           use <literal role="func">UNIX_TIMESTAMP()</literal> as the
           argument to <literal role="func">RAND()</literal>.


Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml	2009-09-03 07:17:25 UTC (rev 16417)
+++ trunk/refman-5.0/replication-notes.xml	2009-09-03 10:30:11 UTC (rev 16418)
Changed blocks: 3, Lines Added: 71, Lines Deleted: 10; 5005 bytes

@@ -651,10 +651,63 @@
         <listitem>
           <para>
             For <literal role="func">NOW()</literal>, the binary log
-            includes the timestamp and replicates correctly.
+            includes the timestamp. This means that the value
+            <emphasis>as returned by the call to this function on the
+            master</emphasis> is replicated to the slave. This can lead
+            to a possibly unexpected result when replicating between
+            MySQL servers in different time zones. For example, suppose
+            that the master is located in New York, the slave is located
+            in Stockholm, and both servers are using local time. Suppose
+            further that, on the master, you create a table
+            <literal>mytable</literal>, perform an
+            <literal role="stmt">INSERT</literal> statement on this
+            table, and then select from the table, as shown here:
           </para>
 
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE mytable (mycol TEXT);</userinput>
+Query OK, 0 rows affected (0.06 sec)
+
+mysql&gt; <userinput>INSERT INTO mytable VALUES ( NOW() );</userinput>
+Query OK, 1 row affected (0.00 sec)
+
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
           <para>
+            Local time in Stockholm is 6 hours later than in New York;
+            so, if you issue <literal>SELECT NOW()</literal> on the
+            slave at that exact same instant, the value
+            <literal>2009-09-01 18:00:00</literal> is returned. For this
+            reason, if you select from the slave&apos;s copy of
+            <literal>mytable</literal> after the
+            <literal role="stmt">CREATE TABLE</literal> and
+            <literal role="stmt">INSERT</literal> statements just shown
+            have been replicated, you might expect
+            <literal>mycol</literal> to contain the value
+            <literal>2009-09-01 18:00:00</literal>. However, this is not
+            the case; when you select from the slave&apos;s copy of
+            <literal>mytable</literal>, you obtain exactly the same
+            result as on the master:
+          </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+          <para>
             As of MySQL 5.0.13, the
             <literal role="func">SYSDATE()</literal> function is no
             longer equivalent to <literal role="func">NOW()</literal>.

@@ -667,6 +720,10 @@
             option to cause <literal role="func">SYSDATE()</literal> to
             be an alias for <literal role="func">NOW()</literal>.
           </para>
+
+          <para>
+            See also <xref linkend="replication-features-timezone"/>.
+          </para>
         </listitem>
 
         <listitem>

@@ -1347,20 +1404,24 @@
       </indexterm>
 
       <para>
-        If the master uses MySQL 4.1, 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 role="func">NOW()</literal> or
+        The same system time zone should be set for both master and
+        slave. Otherwise statements depending on the local time on the
+        master are not replicated properly, such as statements that use
+        the <literal role="func">NOW()</literal> or
         <literal role="func">FROM_UNIXTIME()</literal> functions. You
         can set the time zone in which MySQL server runs by using the
         <option role="mysqld_safe">--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
+        setting the <literal>TZ</literal> environment variable. See also
+        <xref linkend="replication-features-functions"/>.
+      </para>
+
+      <para>
+        If the master is MySQL 4.1 or earlier, then both master and
+        slave should also have the same default connection time zone
+        setting; that is, the
         <option role="mysqld">--default-time-zone</option> parameter
-        should have the same value for both master and slave. Note that
-        this is not necessary when the master is MySQL 5.0 or later.
+        should have the same value for both master and slave.
       </para>
 
       <para>


Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml	2009-09-03 07:17:25 UTC (rev 16417)
+++ trunk/refman-5.1/replication-notes.xml	2009-09-03 10:30:11 UTC (rev 16418)
Changed blocks: 3, Lines Added: 71, Lines Deleted: 10; 5026 bytes

@@ -1481,10 +1481,63 @@
         <listitem>
           <para>
             For <literal role="func">NOW()</literal>, the binary log
-            includes the timestamp and replicates correctly.
+            includes the timestamp. This means that the value
+            <emphasis>as returned by the call to this function on the
+            master</emphasis> is replicated to the slave. This can lead
+            to a possibly unexpected result when replicating between
+            MySQL servers in different time zones. For example, suppose
+            that the master is located in New York, the slave is located
+            in Stockholm, and both servers are using local time. Suppose
+            further that, on the master, you create a table
+            <literal>mytable</literal>, perform an
+            <literal role="stmt">INSERT</literal> statement on this
+            table, and then select from the table, as shown here:
           </para>
 
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE mytable (mycol TEXT);</userinput>
+Query OK, 0 rows affected (0.06 sec)
+
+mysql&gt; <userinput>INSERT INTO mytable VALUES ( NOW() );</userinput>
+Query OK, 1 row affected (0.00 sec)
+
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
           <para>
+            Local time in Stockholm is 6 hours later than in New York;
+            so, if you issue <literal>SELECT NOW()</literal> on the
+            slave at that exact same instant, the value
+            <literal>2009-09-01 18:00:00</literal> is returned. For this
+            reason, if you select from the slave&apos;s copy of
+            <literal>mytable</literal> after the
+            <literal role="stmt">CREATE TABLE</literal> and
+            <literal role="stmt">INSERT</literal> statements just shown
+            have been replicated, you might expect
+            <literal>mycol</literal> to contain the value
+            <literal>2009-09-01 18:00:00</literal>. However, this is not
+            the case; when you select from the slave&apos;s copy of
+            <literal>mytable</literal>, you obtain exactly the same
+            result as on the master:
+          </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+          <para>
             Unlike <literal role="func">NOW()</literal>, the
             <literal role="func">SYSDATE()</literal> function is not
             replication-safe because it is not affected by <literal>SET

@@ -1496,6 +1549,10 @@
             cause <literal role="func">SYSDATE()</literal> to be an
             alias for <literal role="func">NOW()</literal>.
           </para>
+
+          <para>
+            See also <xref linkend="replication-features-timezone"/>.
+          </para>
         </listitem>
 
         <listitem>

@@ -2212,20 +2269,24 @@
       </indexterm>
 
       <para>
-        If the master uses MySQL 4.1, 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 role="func">NOW()</literal> or
+        The same system time zone should be set for both master and
+        slave. Otherwise statements depending on the local time on the
+        master are not replicated properly, such as statements that use
+        the <literal role="func">NOW()</literal> or
         <literal role="func">FROM_UNIXTIME()</literal> functions. You
         can set the time zone in which MySQL server runs by using the
         <option role="mysqld_safe">--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
+        setting the <literal>TZ</literal> environment variable. See also
+        <xref linkend="replication-features-functions"/>.
+      </para>
+
+      <para>
+        If the master is MySQL 4.1 or earlier, then both master and
+        slave should also have the same default connection time zone
+        setting; that is, the
         <option role="mysqld">--default-time-zone</option> parameter
-        should have the same value for both master and slave. Note that
-        this is not necessary when the master is MySQL 5.0 or later.
+        should have the same value for both master and slave.
       </para>
 
       <para>


Modified: trunk/refman-5.4/replication-notes.xml
===================================================================
--- trunk/refman-5.4/replication-notes.xml	2009-09-03 07:17:25 UTC (rev 16417)
+++ trunk/refman-5.4/replication-notes.xml	2009-09-03 10:30:11 UTC (rev 16418)
Changed blocks: 3, Lines Added: 71, Lines Deleted: 10; 5026 bytes

@@ -1435,10 +1435,63 @@
         <listitem>
           <para>
             For <literal role="func">NOW()</literal>, the binary log
-            includes the timestamp and replicates correctly.
+            includes the timestamp. This means that the value
+            <emphasis>as returned by the call to this function on the
+            master</emphasis> is replicated to the slave. This can lead
+            to a possibly unexpected result when replicating between
+            MySQL servers in different time zones. For example, suppose
+            that the master is located in New York, the slave is located
+            in Stockholm, and both servers are using local time. Suppose
+            further that, on the master, you create a table
+            <literal>mytable</literal>, perform an
+            <literal role="stmt">INSERT</literal> statement on this
+            table, and then select from the table, as shown here:
           </para>
 
+<programlisting>
+mysql&gt; <userinput>CREATE TABLE mytable (mycol TEXT);</userinput>
+Query OK, 0 rows affected (0.06 sec)
+
+mysql&gt; <userinput>INSERT INTO mytable VALUES ( NOW() );</userinput>
+Query OK, 1 row affected (0.00 sec)
+
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
           <para>
+            Local time in Stockholm is 6 hours later than in New York;
+            so, if you issue <literal>SELECT NOW()</literal> on the
+            slave at that exact same instant, the value
+            <literal>2009-09-01 18:00:00</literal> is returned. For this
+            reason, if you select from the slave&apos;s copy of
+            <literal>mytable</literal> after the
+            <literal role="stmt">CREATE TABLE</literal> and
+            <literal role="stmt">INSERT</literal> statements just shown
+            have been replicated, you might expect
+            <literal>mycol</literal> to contain the value
+            <literal>2009-09-01 18:00:00</literal>. However, this is not
+            the case; when you select from the slave&apos;s copy of
+            <literal>mytable</literal>, you obtain exactly the same
+            result as on the master:
+          </para>
+
+<programlisting>
+mysql&gt; <userinput>SELECT * FROM mytable;</userinput>
++---------------------+
+| mycol               |
++---------------------+
+| 2009-09-01 12:00:00 |
++---------------------+
+1 row in set (0.00 sec)
+</programlisting>
+
+          <para>
             Unlike <literal role="func">NOW()</literal>, the
             <literal role="func">SYSDATE()</literal> function is not
             replication-safe because it is not affected by <literal>SET

@@ -1450,6 +1503,10 @@
             cause <literal role="func">SYSDATE()</literal> to be an
             alias for <literal role="func">NOW()</literal>.
           </para>
+
+          <para>
+            See also <xref linkend="replication-features-timezone"/>.
+          </para>
         </listitem>
 
         <listitem>

@@ -2139,20 +2196,24 @@
       </indexterm>
 
       <para>
-        If the master uses MySQL 4.1, 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 role="func">NOW()</literal> or
+        The same system time zone should be set for both master and
+        slave. Otherwise statements depending on the local time on the
+        master are not replicated properly, such as statements that use
+        the <literal role="func">NOW()</literal> or
         <literal role="func">FROM_UNIXTIME()</literal> functions. You
         can set the time zone in which MySQL server runs by using the
         <option role="mysqld_safe">--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
+        setting the <literal>TZ</literal> environment variable. See also
+        <xref linkend="replication-features-functions"/>.
+      </para>
+
+      <para>
+        If the master is MySQL 4.1 or earlier, then both master and
+        slave should also have the same default connection time zone
+        setting; that is, the
         <option role="mysqld">--default-time-zone</option> parameter
-        should have the same value for both master and slave. Note that
-        this is not necessary when the master is MySQL 5.0 or later.
+        should have the same value for both master and slave.
       </para>
 
       <para>


Thread
svn commit - mysqldoc@docsrva: r16418 - in trunk: refman-4.1 refman-5.0 refman-5.1 refman-5.4jon.stephens3 Sep