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'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 ¤t-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'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 ¤t-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'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 ¤t-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.5 | jon.stephens | 10 Feb |
