List:Commits« Previous MessageNext Message »
From:jon.stephens Date:February 10 2011 11:11am
Subject:svn commit - mysqldoc@docsrva: r25046 - in trunk: refman-5.0 refman-5.1 refman-5.5
View as plain text  
Author: jstephens
Date: 2011-02-10 12:11:03 +0100 (Thu, 10 Feb 2011)
New Revision: 25046

Log:

Fixes Docs BUG#59262 (TIMESTAMP(N) and cross-version replication/restore issues)



Modified:
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/installing-updowngrade.xml
   trunk/refman-5.0/replication-notes.xml
   trunk/refman-5.1/data-types.xml
   trunk/refman-5.1/installing-updowngrade.xml
   trunk/refman-5.1/replication-notes.xml
   trunk/refman-5.5/data-types.xml
   trunk/refman-5.5/installing-updowngrade.xml
   trunk/refman-5.5/replication-notes.xml


Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.0/data-types.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 2, Lines Added: 18, Lines Deleted: 10; 2051 bytes

@@ -3450,16 +3450,6 @@
 
         <title><literal role="type">TIMESTAMP</literal> Properties</title>
 
-        <note>
-          <para>
-            In older versions of MySQL (prior to 4.1), the properties of
-            the <literal role="type">TIMESTAMP</literal> data type
-            differ significantly in several ways from what is described
-            in this section. See the <citetitle>MySQL 3.23, 4.0, 4.1
-            Reference Manual</citetitle> for details.
-          </para>
-        </note>
-
         <para>
           <literal role="type">TIMESTAMP</literal> columns are displayed
           in the same format as <literal role="type">DATETIME</literal>

@@ -3468,6 +3458,24 @@
           HH:MM:SS'</literal>.
         </para>
 
+        <note>
+          <para>
+            In older versions of MySQL (prior to 4.1), the properties of
+            the <literal role="type">TIMESTAMP</literal> data type
+            differed significantly in several ways from what is
+            described in this section (see the <citetitle>MySQL 3.23,
+            4.0, 4.1 Reference Manual</citetitle> for details); these
+            include syntax extensions which are deprecated in MySQL 5.1,
+            and no longer supported in MySQL 5.5. This has implications
+            for performing a dump and restore or replicating between
+            MySQL Server versions. If you are using columns that are
+            defined using the old
+            <literal role="type">TIMESTAMP(N)</literal> syntax, see
+            <xref linkend="upgrading-from-previous-series"/>,
+            prior to upgrading to MySQL 5.1 or later.
+          </para>
+        </note>
+
         <para>
           <literal role="type">TIMESTAMP</literal> values are converted
           from the current time zone to UTC for storage, and converted


Modified: trunk/refman-5.0/installing-updowngrade.xml
===================================================================
--- trunk/refman-5.0/installing-updowngrade.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.0/installing-updowngrade.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 116, Lines Deleted: 0; 5795 bytes

@@ -666,6 +666,122 @@
 
         <listitem>
           <para>
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and replication</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>logs</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and logs</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>between MySQL server versions</secondary>
+            </indexterm>
+
+            <emphasis role="bold">Incompatible change</emphasis>: In
+            very old versions of MySQL (prior to 4.1), the
+            <literal role="type">TIMESTAMP</literal> data type supported
+            a display width, which was silenty ignored beginning with
+            MySQL 4.1. This is deprecated in MySQL 5.1, and removed
+            altogether in MySQL 5.5. These changes in behavior can lead
+            to two problem scenarios when trying to use
+            <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+            columns with a MySQL 5.5 or later server:
+          </para>
+
+          <itemizedlist>
+
+            <listitem>
+              <para>
+                When importing a dump file (for example, one created
+                using <command>mysqldump</command>) created in a MySQL
+                5.0 or earlier server into a server from a newer release
+                series, a <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the import to fail with a syntax error.
+              </para>
+
+              <para>
+                To fix this problem, edit the dump file in a text editor
+                to replace any instances of
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                with <literal role="type">TIMESTAMP</literal> prior to
+                importing the file. Be sure to use a plain text editor
+                for this, and not a word processor; otherwise, the
+                result is almost certain to be unusable for importing
+                into the MySQL server.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                When trying replicate any <literal role="stmt">CREATE
+                TABLE</literal> or <literal role="stmt">ALTER
+                TABLE</literal> statement containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                from a master MySQL server that supports the
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                syntax to a MySQL 5.5 or newer slave, the statement
+                causes replication to fail. Similarly, when you try to
+                restore from a binary log written by a server that
+                supports
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                to a MySQL 5.5 or newer server, any
+                <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the backup to fail. This holds true regardless of
+                the logging format used by a MySQL 5.1 or newer server.
+              </para>
+
+              <para>
+                It may be possible to fix such issues using a hex
+                editor, by replacing any width arguments used with
+                <literal role="type">TIMESTAMP</literal>, and the
+                parentheses containing them, with space characters
+                (hexadecimal <literal>20</literal>). This can be made to
+                work as long as checksums were not enabled when creating
+                the binary log. Be sure to use a programmer&apos;s
+                binary hex editor and not a regular text editor or word
+                processor for this; otherwise, the result is almost
+                certain to be a corrupted binary log file. To guard
+                against accidental corruption of the binary log, you
+                should always work on a copy of the file rather than the
+                original.
+              </para>
+            </listitem>
+
+          </itemizedlist>
+
+          <para>
+            You should try to handle potential issues of these types
+            proactively by updating with <literal role="stmt">ALTER
+            TABLE</literal> any
+            <literal role="type">TIMESTAMP(N)</literal> columns in your
+            databases so that they use
+            <literal role="type">TIMESTAMP</literal> instead, before
+            performing any upgrades.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
             <emphasis role="bold">Incompatible change</emphasis>:
             <literal>MyISAM</literal> and <literal>InnoDB</literal>
             tables created with <literal role="type">DECIMAL</literal>


Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.0/replication-notes.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 38, Lines Deleted: 0; 1804 bytes

@@ -1527,6 +1527,44 @@
 
     </section>
 
+    <section id="replication-features-timestamp">
+
+      <title>Replication and <literal>TIMESTAMP</literal></title>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>and TIMESTAMP</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>TIMESTAMP</primary>
+        <secondary>and replication</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>between MySQL server versions</secondary>
+      </indexterm>
+
+      <para>
+        Older versions of MySQL (prior to 4.1) differed significantly in
+        several ways in their handling of the
+        <literal role="type">TIMESTAMP</literal> data type from what is
+        supported in MySQL versions &current-series; and newer; these
+        include syntax extensions which are deprecated in MySQL 5.1, and
+        that no longer supported in MySQL 5.5. This this can cause
+        problems (including replication failures) when replicating
+        between MySQL Server versions, if you are using columns that are
+        defined using the old
+        <literal role="type">TIMESTAMP(N)</literal> syntax. See
+        <xref linkend="upgrading-from-previous-series"/>, for
+        more information about the differences, how they can impact
+        MySQL replication, and what you can do if you encounter such
+        problems.
+      </para>
+
+    </section>
+
     <section id="replication-features-timezone">
 
       <title>Replication and Time Zones</title>


Modified: trunk/refman-5.1/data-types.xml
===================================================================
--- trunk/refman-5.1/data-types.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.1/data-types.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 18, Lines Deleted: 0; 1390 bytes

@@ -3282,6 +3282,24 @@
           HH:MM:SS'</literal>.
         </para>
 
+        <note>
+          <para>
+            In older versions of MySQL (prior to 4.1), the properties of
+            the <literal role="type">TIMESTAMP</literal> data type
+            differed significantly in several ways from what is
+            described in this section (see the <citetitle>MySQL 3.23,
+            4.0, 4.1 Reference Manual</citetitle> for details); these
+            include syntax extensions which are deprecated in MySQL 5.1,
+            and no longer supported in MySQL 5.5. This has implications
+            for performing a dump and restore or replicating between
+            MySQL Server versions. If you are using columns that are
+            defined using the old
+            <literal role="type">TIMESTAMP(N)</literal> syntax, see
+            <xref linkend="upgrading-from-previous-series"/>,
+            prior to upgrading to MySQL 5.1 or later.
+          </para>
+        </note>
+
         <para>
           <literal role="type">TIMESTAMP</literal> values are converted
           from the current time zone to UTC for storage, and converted


Modified: trunk/refman-5.1/installing-updowngrade.xml
===================================================================
--- trunk/refman-5.1/installing-updowngrade.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.1/installing-updowngrade.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 114, Lines Deleted: 0; 5643 bytes

@@ -1482,6 +1482,120 @@
 
         <listitem>
           <para>
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and replication</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>logs</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and logs</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>between MySQL server versions</secondary>
+            </indexterm>
+
+            <emphasis role="bold">Incompatible change</emphasis>: In
+            very old versions of MySQL (prior to 4.1), the
+            <literal role="type">TIMESTAMP</literal> data type supported
+            a display width, which was silenty ignored beginning with
+            MySQL 4.1. This is deprecated in MySQL 5.1, and removed
+            altogether in MySQL 5.5. These changes in behavior can lead
+            to two problem scenarios when trying to use
+            <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+            columns with a MySQL 5.5 or later server:
+          </para>
+
+          <itemizedlist>
+
+            <listitem>
+              <para>
+                When importing a dump file (for example, one created
+                using <command>mysqldump</command>) created in a MySQL
+                5.0 or earlier server into a server from a newer release
+                series, a <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the import to fail with a syntax error.
+              </para>
+
+              <para>
+                To fix this problem, edit the dump file in a text editor
+                to replace any instances of
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                with <literal role="type">TIMESTAMP</literal> prior to
+                importing the file. Be sure to use a plain text editor
+                for this, and not a word processor; otherwise, the
+                result is almost certain to be unusable for importing
+                into the MySQL server.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                When trying replicate any <literal role="stmt">CREATE
+                TABLE</literal> or <literal role="stmt">ALTER
+                TABLE</literal> statement containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                from a master MySQL server that supports the
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                syntax to a MySQL 5.5.3 or newer slave, the statement
+                causes replication to fail. Similarly, when you try to
+                restore from a binary log written by a server that
+                supports
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                to a MySQL 5.5.3 or newer server, any
+                <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the backup to fail. This holds true regardless of
+                the logging format.
+              </para>
+
+              <para>
+                It may be possible to fix such issues using a hex
+                editor, by replacing any width arguments used with
+                <literal role="type">TIMESTAMP</literal>, and the
+                parentheses containing them, with space characters
+                (hexadecimal <literal>20</literal>). Be sure to use a
+                programmer&apos;s binary hex editor and not a regular
+                text editor or word processor for this; otherwise, the
+                result is almost certain to be a corrupted binary log
+                file. To guard against accidental corruption of the
+                binary log, you should always work on a copy of the file
+                rather than the original.
+              </para>
+            </listitem>
+
+          </itemizedlist>
+
+          <para>
+            You should try to handle potential issues of these types
+            proactively by updating with <literal role="stmt">ALTER
+            TABLE</literal> any
+            <literal role="type">TIMESTAMP(N)</literal> columns in your
+            databases so that they use
+            <literal role="type">TIMESTAMP</literal> instead, before
+            performing any upgrades.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
             <emphasis role="bold">Incompatible change</emphasis>: For
             <literal role="type">ENUM</literal> columns that had
             enumeration values containing commas, the commas were mapped


Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.1/replication-notes.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 38, Lines Deleted: 0; 1804 bytes

@@ -3237,6 +3237,44 @@
 
     </section>
 
+    <section id="replication-features-timestamp">
+
+      <title>Replication and <literal>TIMESTAMP</literal></title>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>and TIMESTAMP</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>TIMESTAMP</primary>
+        <secondary>and replication</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>between MySQL server versions</secondary>
+      </indexterm>
+
+      <para>
+        Older versions of MySQL (prior to 4.1) differed significantly in
+        several ways in their handling of the
+        <literal role="type">TIMESTAMP</literal> data type from what is
+        supported in MySQL versions &current-series; and newer; these
+        include syntax extensions which are deprecated in MySQL 5.1, and
+        that no longer supported in MySQL 5.5. This this can cause
+        problems (including replication failures) when replicating
+        between MySQL Server versions, if you are using columns that are
+        defined using the old
+        <literal role="type">TIMESTAMP(N)</literal> syntax. See
+        <xref linkend="upgrading-from-previous-series"/>, for
+        more information about the differences, how they can impact
+        MySQL replication, and what you can do if you encounter such
+        problems.
+      </para>
+
+    </section>
+
     <section id="replication-features-timezone">
 
       <title>Replication and Time Zones</title>


Modified: trunk/refman-5.5/data-types.xml
===================================================================
--- trunk/refman-5.5/data-types.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.5/data-types.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 18, Lines Deleted: 0; 1381 bytes

@@ -3277,6 +3277,24 @@
           HH:MM:SS'</literal>.
         </para>
 
+        <note>
+          <para>
+            In older versions of MySQL (prior to 4.1), the properties of
+            the <literal role="type">TIMESTAMP</literal> data type
+            differed significantly in several ways from what is
+            described in this section (see the <citetitle>MySQL 3.23,
+            4.0, 4.1 Reference Manual</citetitle> for details); these
+            include syntax extensions which are deprecated in MySQL 5.1,
+            and no longer supported in MySQL 5.5. This has implications
+            for performing a dump and restore or replicating between
+            MySQL Server versions. If you are using columns that are
+            defined using the old
+            <literal role="type">TIMESTAMP(N)</literal> syntax, see
+            <xref linkend="upgrading-from-previous-series"/>,
+            prior to upgrading to MySQL 5.5.
+          </para>
+        </note>
+
         <para>
           <literal role="type">TIMESTAMP</literal> values are converted
           from the current time zone to UTC for storage, and converted


Modified: trunk/refman-5.5/installing-updowngrade.xml
===================================================================
--- trunk/refman-5.5/installing-updowngrade.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.5/installing-updowngrade.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 125, Lines Deleted: 0; 5971 bytes

@@ -757,6 +757,131 @@
 
         <listitem>
           <para>
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and replication</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>logs</primary>
+              <secondary>and TIMESTAMP</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>TIMESTAMP</primary>
+              <secondary>and logs</secondary>
+            </indexterm>
+
+            <indexterm>
+              <primary>replication</primary>
+              <secondary>between MySQL server versions</secondary>
+            </indexterm>
+
+            <emphasis role="bold">Incompatible change</emphasis>: In
+            very old versions of MySQL (prior to 4.1), the
+            <literal role="type">TIMESTAMP</literal> data type supported
+            a display width, which was silenty ignored beginning with
+            MySQL 4.1. This is deprecated in MySQL 5.1, and removed
+            altogether in MySQL 5.5. These changes in behavior can lead
+            to two problem scenarios when trying to use
+            <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+            columns with a MySQL 5.5 or later server:
+          </para>
+
+          <itemizedlist>
+
+            <listitem>
+              <para>
+                When importing a dump file (for example, one created
+                using <command>mysqldump</command>) created in a MySQL
+                5.0 or earlier server into a server from a newer release
+                series, a <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the import to fail with a syntax error.
+              </para>
+
+              <para>
+                To fix this problem, edit the dump file in a text editor
+                to replace any instances of
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                with <literal role="type">TIMESTAMP</literal> prior to
+                importing the file. Be sure to use a plain text editor
+                for this, and not a word processor; otherwise, the
+                result is almost certain to be unusable for importing
+                into the MySQL server.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                When trying replicate any <literal role="stmt">CREATE
+                TABLE</literal> or <literal role="stmt">ALTER
+                TABLE</literal> statement containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                from a master MySQL server that supports the
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                syntax to a MySQL 5.5.3 or newer slave, the statement
+                causes replication to fail. Similarly, when you try to
+                restore from a binary log written by a server that
+                supports
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                to a MySQL 5.5.3 or newer server, any
+                <literal role="stmt">CREATE TABLE</literal> or
+                <literal role="stmt">ALTER TABLE</literal> statement
+                containing
+                <literal role="type">TIMESTAMP(<replaceable>N</replaceable>)</literal>
+                causes the backup to fail. This holds true regardless of
+                the logging format.
+              </para>
+
+              <para>
+                It may be possible to fix such issues using a hex
+                editor, by replacing any width arguments used with
+                <literal role="type">TIMESTAMP</literal>, and the
+                parentheses containing them, with space characters
+                (hexadecimal <literal>20</literal>).
+
+                <remark role="todo">
+                  [js] Uncomment whenever checksums are implemented
+                </remark>
+
+<!--  
+                                                      This can be made to work 
+                as long as checksums were not enabled when creating the binary 
+                log. 
+-->
+
+                Be sure to use a programmer&apos;s binary hex editor and
+                not a regular text editor or word processor for this;
+                otherwise, the result is almost certain to be a
+                corrupted binary log file. To guard against accidental
+                corruption of the binary log, you should always work on
+                a copy of the file rather than the original.
+              </para>
+            </listitem>
+
+          </itemizedlist>
+
+          <para>
+            You should try to handle potential issues of these types
+            proactively by updating with <literal role="stmt">ALTER
+            TABLE</literal> any
+            <literal role="type">TIMESTAMP(N)</literal> columns in your
+            databases so that they use
+            <literal role="type">TIMESTAMP</literal> instead, before
+            performing any upgrades.
+          </para>
+        </listitem>
+
+        <listitem>
+          <para>
             <emphasis role="bold">Incompatible change</emphasis>: As of
             MySQL 5.5.3, the Unicode implementation has been extended to
             provide support for supplementary characters that lie


Modified: trunk/refman-5.5/replication-notes.xml
===================================================================
--- trunk/refman-5.5/replication-notes.xml	2011-02-10 11:06:38 UTC (rev 25045)
+++ trunk/refman-5.5/replication-notes.xml	2011-02-10 11:11:03 UTC (rev 25046)
Changed blocks: 1, Lines Added: 38, Lines Deleted: 0; 1804 bytes

@@ -3009,6 +3009,44 @@
 
     </section>
 
+    <section id="replication-features-timestamp">
+
+      <title>Replication and <literal>TIMESTAMP</literal></title>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>and TIMESTAMP</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>TIMESTAMP</primary>
+        <secondary>and replication</secondary>
+      </indexterm>
+
+      <indexterm>
+        <primary>replication</primary>
+        <secondary>between MySQL server versions</secondary>
+      </indexterm>
+
+      <para>
+        Older versions of MySQL (prior to 4.1) differed significantly in
+        several ways in their handling of the
+        <literal role="type">TIMESTAMP</literal> data type from what is
+        supported in MySQL versions &current-series; and newer; these
+        include syntax extensions which are deprecated in MySQL 5.1, and
+        that no longer supported in MySQL 5.5. This this can cause
+        problems (including replication failures) when replicating
+        between MySQL Server versions, if you are using columns that are
+        defined using the old
+        <literal role="type">TIMESTAMP(N)</literal> syntax. See
+        <xref linkend="upgrading-from-previous-series"/>, for
+        more information about the differences, how they can impact
+        MySQL replication, and what you can do if you encounter such
+        problems.
+      </para>
+
+    </section>
+
     <section id="replication-features-timezone">
 
       <title>Replication and Time Zones</title>


Thread
svn commit - mysqldoc@docsrva: r25046 - in trunk: refman-5.0 refman-5.1 refman-5.5jon.stephens10 Feb