Oracle 5.0 Reference Manual page 168

• When trying replicate any
from a master MySQL server that supports the
TIMESTAMP(N)
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
newer server, any
causes the backup to fail. This holds true regardless of the logging format used by a MySQL 5.1 or
newer server.
It may be possible to fix such issues using a hex editor, by replacing any width arguments used
with TIMESTAMP, and the parentheses containing them, with space characters (hexadecimal 20).
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.
You should try to handle potential issues of these types proactively by updating with
any
TIMESTAMP(N)
performing any upgrades.
• Incompatible change:
5.0.3 to 5.0.5 will appear corrupt after an upgrade to MySQL 5.0.6. (The same incompatibility will
occur for these tables created in MySQL 5.0.6 after a downgrade to MySQL 5.0.3 to 5.0.5.) If you
have such tables, check and repair them with
"mysql_upgrade — Check Tables for MySQL
• Incompatible change: For user-defined functions, exact-value decimal arguments such as
or column values were passed as
DECIMAL
5.0.3, they are passed as strings with a type of DECIMAL_RESULT. If you upgrade to 5.0.3 and find
that your UDF now receives string values, use the initialization function to coerce the arguments to
numbers as described in
• Incompatible change: As of MySQL 5.0.3, the server by default no longer loads user-defined
functions (UDFs) unless they have at least one auxiliary symbol (for example, an
or symbol) defined in addition to the main function symbol. This behavior can be
xxx_deinit
overridden with the
--allow-suspicious-udfs
Defined Function Security
• Incompatible change: The update log has been removed in MySQL 5.0. If you had enabled it
previously, enable the binary log instead.
• Incompatible change: Support for the
you have any tables, you should convert them before upgrading. For example, to convert an
ISAM
table to use the
ISAM
ALTER TABLE tbl_name
Use a similar statement for every
• Incompatible change: Support for
5.0. If you have tables that use these options, you should convert them before upgrading. One
way to do this is to dump them with mysqldump, edit the dump file to remove the
in the
CREATE TABLE
TABLE new_tbl ... SELECT raid_tbl
the
CREATE TABLE
attributes as well as indexes, or column attributes may be lost and indexes will not appear in the new
table. See Section 13.1.10,
The files for
.MYD RAID
subdirectories that have names consisting of two hex digits in the range from
Upgrading MySQL
CREATE TABLE
or
CREATE TABLE ALTER TABLE
columns in your databases so that they use
and
MyISAM InnoDB
Section 21.2.2.3, "UDF Argument
Precautions".
ISAM
storage engine, use this statement:
MyISAM
ENGINE = MyISAM;
table in each of your databases.
ISAM
options in
RAID
statements, and reload the dump file. Another possibility is to use
part of the statement must contain sufficient information to re-create column
"CREATE TABLE
tables in a given database are stored under the database directory in
148
or statement containing
ALTER TABLE
TIMESTAMP(N)
TIMESTAMP(N)
statement containing
TIMESTAMP
tables created with
DECIMAL
after upgrading. See
mysql_upgrade
Upgrade".
values prior to MySQL 5.0.3. As of
REAL_RESULT
Processing".
[400] option. See
storage engine has been removed in MySQL 5.0. If
tables has been removed in MySQL
MyISAM
to create a new table from the
Syntax".
syntax to a
to a MySQL 5.5 or
TIMESTAMP(N)
ALTER TABLE
instead, before
columns in MySQL
Section 4.4.9,
1.3
xxx_init
Section 21.2.2.6, "User-
options
RAID
CREATE
table. However,
RAID
to ff. After
00