In general, you should do the following when upgrading from MySQL 3.23 to 4.0:
Read all the items in Section 2.11.1, “Upgrading MySQL”, to see whether any of them might affect your applications.
Read all the items in the change list found later in this section to see whether any of them might affect your applications. Note particularly any that are marked Known issue or Incompatible change; these result in incompatibilities with earlier versions of MySQL.
Read the 4.0 changelog to see what significant new features you can use in 4.0. See Section B.2, “Changes in Release 4.0.x”.
If you run MySQL Server on Windows, see Section 2.3.14, “Upgrading MySQL on Windows”.
After upgrading, update the grant tables to add new privileges and features. This procedure uses the mysql_fix_privilege_tables script and is described in Section 4.4.5, “mysql_fix_privilege_tables — Upgrade MySQL System Tables”.
If you use replication, see Section 14.6, “Upgrading a Replication Setup”, for information on upgrading your replication setup.
Edit any MySQL startup scripts or option files so that they do not use any of the options described as deprecated later in this section.
Convert your old ISAM
tables to
MyISAM
format. One way to do this is with
the mysql_convert_table_format script.
(This is a Perl script; it requires that
DBI
be installed.) To convert all of the
tables in a given database, use this command:
shell> mysql_convert_table_format database db_name
Note that the above command should be used only if
all tables in the database are
ISAM
or MyISAM
tables.
To avoid converting tables of other types to
MyISAM
, you can explicitly list the names
of the ISAM
tables following the database
name on the command line.
Individual tables can be changed to
MyISAM
by using the following
ALTER TABLE
statement for
each table to be converted:
mysql> ALTER TABLE tbl_name
TYPE=MyISAM;
If you are not sure of the storage engine for a given table, use this statement:
mysql> SHOW TABLE STATUS LIKE 'tbl_name
';
Ensure that you do not have any MySQL clients that use
shared libraries (like the Perl
DBD::mysql
module). If you do, you should
recompile them, because the data structures used in
libmysqlclient.so
have changed. The
same applies to other MySQL interfaces such as the Python
MySQLdb
module.
MySQL 4.0 works even if you do not perform the preceding
actions, but you cannot use the new security privileges in MySQL
4.0 and you may run into problems when upgrading later to MySQL
4.1 or newer. The ISAM
file format still
works in MySQL 4.0, but is deprecated and is not compiled in by
default as of MySQL 4.1. MyISAM
tables should
be used instead.
Old clients should work with a MySQL 4.0 server without any problems.
Even if you perform the preceding actions, you can still downgrade to MySQL 3.23.52 or newer if you run into problems with the MySQL 4.0 series. In this case, you must use mysqldump to dump any tables that use full-text indexes and reload the dump file into the 3.23 server. This is necessary because 4.0 uses an improved format for full-text indexing that is not backward-compatible.
The following lists describe changes that may affect applications and that you should watch out for when upgrading from MySQL 3.23 to 4.0.
Server Changes:
As of MySQL 4.0.24, the server by default no longer loads
user-defined functions unless they have at least one
auxiliary symbol defined in addition to the main function
symbol. This behavior can be overridden with the
--allow-suspicious-udfs
option. See Section 18.2.2.6, “User-Defined Function Security Precautions”.
MySQL 4.0 has many new privileges in the
mysql.user
table. See
Section 5.5.1, “Privileges Provided by MySQL”.
In order for these new privileges to work, you must update
the grant tables. The procedure for this is described in
Section 4.4.5, “mysql_fix_privilege_tables — Upgrade MySQL System Tables”. Until you do
this, all accounts have the SHOW
DATABASES
, CREATE TEMPORARY
TABLES
, and LOCK
TABLES
privileges.
SUPER
and
EXECUTE
privileges take their
value from PROCESS
.
REPLICATION SLAVE
and
REPLICATION CLIENT
take their
values from FILE
.
If you have any scripts that create new MySQL user accounts,
you may want to change them to use the new privileges. If
you are not using GRANT
commands in the scripts, this is a good time to change your
scripts to use GRANT
instead
of modifying the grant tables directly.
From version 4.0.2 on, the option
--safe-show-database
is
deprecated (and no longer does anything). See
Section 5.4.4, “Security-Related mysqld Options”.
If you get Access denied
errors for new
users in version 4.0.2 and up, you should check whether you
need some of the new grants that you did not need before. In
particular, you need REPLICATION
SLAVE
(instead of
FILE
) for new slave servers.
safe_mysqld has been renamed to mysqld_safe. For backward compatibility, binary distributions will for some time include safe_mysqld as a symlink to mysqld_safe.
InnoDB
support is included by default in
binary distributions. If you build MySQL from source,
InnoDB
is configured in by default. If
you do not use InnoDB
and want to save
memory when running a server that has
InnoDB
support enabled, use the
--skip-innodb
server startup option. To compile MySQL without
InnoDB
support, run
configure with the
--without-innodb
option.
Values for the startup parameters
myisam_max_extra_sort_file_size
and
myisam_max_extra_sort_file_size
are given in bytes (prior to 4.0.3,they were given in
megabytes).
mysqld has the option
--temp-pool
enabled by
default because this gives better performance with some
operating systems (most notably Linux).
The mysqld startup options
--skip-locking
and
--enable-locking
were renamed to
--skip-external-locking
and
--external-locking
.
--skip-locking
and
--enable-locking
are deprecated.
External system locking of
MyISAM
/ISAM
files is
turned off by default. You can turn this on with
--external-locking
. (However,
this is never needed for most users.)
The following startup variables and options were renamed:
Name in 3.23 | Name in 4.0 (and above) |
myisam_bulk_insert_tree_size |
bulk_insert_buffer_size |
query_cache_startup_type |
query_cache_type |
record_buffer |
read_buffer_size |
record_rnd_buffer |
read_rnd_buffer_size |
sort_buffer |
sort_buffer_size |
--warnings |
--log-warnings |
--err-log |
--log-error (for
mysqld_safe) |
The startup options record_buffer
,
sort_buffer
, and
warnings
still work in MySQL 4.0 but are
deprecated.
SQL Changes:
Some keywords are reserved in MySQL 4.0 that were not reserved in MySQL 3.23. See Section 8.3, “Reserved Words”.
The following SQL variables have been renamed:
Name in 3.23 | Name in 4.0 and above |
sql_big_tables |
big_tables |
sql_low_priority_updates |
low_priority_updates |
sql_max_join_size |
max_join_size |
sql_query_cache_type |
query_cache_type |
The older names still work in MySQL 4.0 but are deprecated.
You must use SET GLOBAL
SQL_SLAVE_SKIP_COUNTER=skip_count
instead of
SET SQL_SLAVE_SKIP_COUNTER=skip_count
.
SHOW MASTER STATUS
returns an
empty set if binary logging is not enabled.
SHOW SLAVE STATUS
returns an
empty set if the slave is not initialized.
SHOW INDEX
has two more
columns in 4.0 than in 3.23 (Null
and
Index_type
).
The format of SHOW OPEN
TABLES
changed.
As of MySQL 4.0.11, ORDER BY col_name
DESC
sorts NULL
values last. In
3.23 and in earlier 4.0 versions, this was not always
consistent.
CHECK
, LOCALTIME
, and
LOCALTIMESTAMP
are reserved words.
DOUBLE
and
FLOAT
columns honor the
UNSIGNED
flag on storage (previously,
UNSIGNED
was ignored for these columns).
The result of all bitwise operators (|
,
&
, <<
,
>>
, and ~
) is
unsigned. This may cause problems if you are using them in a
context where you want a signed result. See
Section 11.9, “Cast Functions and Operators”.
When you use subtraction between integer values where one
is of type UNSIGNED
, the result is
unsigned. In other words, before upgrading to MySQL 4.0,
you should check your application for cases in which you
are subtracting a value from an unsigned entity and want a
negative answer or subtracting an unsigned value from an
integer column. You can disable this behavior by using the
--sql-mode=NO_UNSIGNED_SUBTRACTION
option when starting mysqld. See
Section 5.1.7, “Server SQL Modes”.
You should use integers to store values in
BIGINT
columns (instead of
using strings as in MySQL 3.23). Using strings still works,
but using integers is more efficient.
In MySQL 3.23,
INSERT INTO
... SELECT
always had IGNORE
enabled. As of 4.0.1, MySQL stops (and possibly rolls back)
by default in case of an error unless you specify
IGNORE
.
You should use TRUNCATE TABLE
when you want to delete all rows from a table and you do not
need to obtain a count of the number of rows that were
deleted. (DELETE FROM
returns a row
count in 4.0 and does not reset the
tbl_name
AUTO_INCREMENT
counter, and
TRUNCATE TABLE
is faster.)
You get an error if you have an active transaction or
LOCK TABLES
statement when
trying to execute TRUNCATE
TABLE
or DROP
DATABASE
.
To use MATCH ... AGAINST (... IN BOOLEAN
MODE)
full-text searches, you must rebuild
existing table indexes using REPAIR TABLE
. If
you attempt a boolean full-text search without rebuilding
the indexes in this manner, the search returns incorrect
results. See Section 11.8.6, “Fine-Tuning MySQL Full-Text Search”.
tbl_name
USE_FRM
LOCATE()
and
INSTR()
are case sensitive if
one of the arguments is a binary string. Otherwise they are
case insensitive.
STRCMP()
uses the current
character set when performing comparisons. This makes the
default comparison behavior not case sensitive unless one or
both of the operands are binary strings.
HEX(
returns the characters in str
)str
converted to hexadecimal. If you want to convert a number to
hexadecimal, you should ensure that you call
HEX()
with a numeric
argument.
RAND(seed)
returns a
different random number series in 4.0 than in 3.23; this was
done to further differentiate
RAND(seed)
and
RAND(seed+1)
.
The default type returned by
IFNULL(A,B)
is set to be the
more “general” of the types of
A
and B
. (The
general-to-specific order is string,
REAL
,
INTEGER
).
C API Changes:
The old C API functions
mysql_drop_db()
,
mysql_create_db()
, and
mysql_connect()
are no
longer supported in MySQL 4.0 unless MySQL is compiled with
CFLAGS=-DUSE_OLD_FUNCTIONS
. It is
preferable to change client programs to use the new 4.0 API
instead.
In the MYSQL_FIELD
structure,
length
and max_length
have changed from unsigned int
to
unsigned long
. This should not cause any
problems, except that they may generate warning messages
when used as arguments in the printf()
class of functions.
Multi-threaded clients should use
mysql_thread_init()
and
mysql_thread_end()
. See
Section 17.6.15.2, “How to Make a Threaded Client”.
Other Changes:
If you want to recompile the Perl
DBD::mysql
module, use a recent version.
Version 2.9003 is recommended. Versions older than 1.2218
should not be used because they use the deprecated
mysql_drop_db()
call.
User Comments
I've successfully upgraded MySQL on a Redhat 9 server by following these steps:
1. Download the server, client, and "Dynamic client libraries
(including 3.23.x libraries)" rpms.
2. rpm -Uvh --nodeps MySQL-server-4.0.16-0.i386.rpm
3. rpm -Uvh MySQL-shared-compat-4.0.16-0.i386.rpm
4. rpm -Uvh MySQL-client-4.0.16-0.i386.rpm
5. I had to manually kill the mysqld process and restart, but after that everything works fine, including my php code.
I've done the step describe above with the rpms stuff
_________________________________________________
1. Download the server, client, and "Dynamic client libraries
(including 3.23.x libraries)" rpms.
2. rpm -Uvh --nodeps MySQL-server-4.0.16-0.i386.rpm
3. rpm -Uvh MySQL-shared-compat-4.0.16-0.i386.rpm
4. rpm -Uvh MySQL-client-4.0.16-0.i386.rpm
5. I had to manually kill the mysqld process and restart, but after that everything works fine, including my php code.
_______________________________________________
Not agreed with 5.
I had Problems cause I'm running Teamspeak on the same maschine wich use a sort of mysql db
and Teamspeak server 2.0.20.1(under redhat 9.0) didn't start cause of sql-db Problems
I had to delete Teamspeak and install new after that everything works fine now .
Apache,phpmyadmin,Teamspeak.....
We've recently upgraded from 3.23 to 4.0.21.
We have more than 1200 different databases on the server with 12GB of data. Clients spread around 10 computers connect to this server. Everything was really easy and we had no problems at all.
We just had to
/etc/init.d/mysql stop
rpm -Uvh MySQL-server-4.0.21-0.i386.rpm
rpm -Uvh MySQL-devel-4.0.21-0.i386.rpm
rpm -Uvh MySQL-client-4.0.21-0.i386.rpm
/etc/init.d/mysql start
The only thing I'm still trying to learn are the new grants options.
Pay attention to the phrase "The ISAM file format still works in MySQL 4.0, but is deprecated and is not compiled in by default as of MySQL 4.1." I updated from mysql 3.2.23 to 4.1.18 and mysql wouldn't start up anymore with the error:
[ERROR] /usr/local/mysql/libexec/mysqld: Can't find file: 'host.MYI' (errno: 2)
MYI represents tables in the MyISAM file format. My grant tables were still in ISAM format and I couldn't convert them to MyISAM with mysql_convert_table_format because that script required mysql to be running. The solution was to download the sources and compile it with the option --with-isam
Here are the steps I have used to upgrade a 3.23.57 MySQL Server to 4.1.8 on a RedHat 9 distribution (heavily based on the comments above).
Have in mind the following incompatibilities and novelties:
- The PASSWORD() function is different and it is often (mistakenly) used in web scripts.
- Subnet (ip/mask) restrictions in the user, host, and db tables do not work anymore when the skip-name-resolve option is enabled.
- The safe-show-database option is obsolete.
- The mysql_fix_privilege_tables script updates existing user accounts in such a way that they can see all databases on the server. This has to be manually fixed.
- The query cache is disbled by default.
I have used customized RPM packages based on the mysql-4.1.7-8.src.rpm from the development section of Fedora Core 3 and the original mysql-4.1.8.tar.gz .
- Check, repair and possibly back-up all your databases.
- #service mysqld stop
- #rpm -Uvh --nodeps mysql-4.1.8-Zay1.athlon.rpm mysql-server-4.1.8-Zay1.athlon.rpm mysql-devel-4.1.8-Zay1.athlon.rpm
- #service mysqld start
- #mysql_fix_privilege_tables
- Set Create_tmp_table_priv and Lock_tables_priv columns in the mysql.user table to 'N' for all users that you don't want to be able to see all databases on your server (see my comment on the SHOW DATABASES command).
- Edit /etc/my.cnf, remove safe-show-database ant skip-name-resolve if present and enable the query cache by adding a query_cache_size parameter (ex. query_cache_size=16777216).
- #service mysqld restart
- Recompile and update your DBD::mysql RPM package (the dependencies were broken when the mysql packages were updated).
I've upgraded a RedHat ES 3.0 machine from 3.23 to 4.1.12 with the rpm instructions posted here and I just found a minor problem with a non existed directory: /var/run/mysqld. The my.cnf was set to put the mysqld.pid file there.
I created that dir with the mysql user as owner and 755 permissions and it runs fine now.
When upgrading from 3.23.58-2.3 on Fedora Core 2, using MySQL-server-4.0.24-0.i386.rpm, the command:
rpm -Uvh --nodep MySQL-server-4.0.24-0.i386.rpm
worked fine, except the upgrade process somehow removed the mysql user and group from the system without adding it again.
So of course, the /etc/init.d/mysql start script complained about the user being missing.
To complete the upgrade, I just used vipw to add the mysql user again and also added mysql to the /etc/group file. Of course, for an upgrade, be sure and use the same uid and guid as the original files were owned by, as well as the same mysql user's home directory.
After that, mysql started up just fine.
Regarding the above comment by S Harper about upgrading from 3.23.58 to 4.0.24 on Fedora Core 2 - I did a similar upgrade (to 4.0.26, though), and found that the user/group weren't removed - just given a different uid/gid.
Previously the mysql user had uid 27, and the mysql group had gid 27. Now the uid is 101, and the gid is 102.
The only files which remained with the old uid/gid were the log files - /var/log/mysqld.log*. For completeness I chown'd them to be owned by the "real" mysql user and group.
I have upgraded two RH FC3 servers from MySQL 3.23 to MySQL 4.1. In both cases it was better to uninstall (using rpm -e) the old version then clean install the new version (I used the RHEL4 rpm from the MySQL downloads. All databases, accounts etc were OK. PHP4 was OK. No problems noted so far. The only thing that I had to do was rename /etc/my.cnf.rpmsave to /etc/my.cnf
On the first server, the rpm -UVH install was unsuccesful because the rpm's has different names. Suffered greatly from an RPM clash. But still very easy to fix by uninstalling then reinstalling.
To upgrade a default GoDaddy Virtual Dedicated Host setup which comes with 3.x, I had to use rpm -e to remove all its current mysql packages, and then installed a 4.1.x version. I needed and used MySQL-client-4.1.7-0.i386.rpm, MySQL-server-4.1.7-0.i386.rpm.
The mysql user didn't disappear with the 4.1.7 install, but it did when I was trying with 4.0.x.
On FC3 with php and php-mysql 4.3.11 : the upgrade to mysql 3.23.58 to mysql 4.0.27 works fine (mysql user must be added again). (MySQL-client-4.0.27-0.i386.rpm - MySQL-devel-4.0.27-0.i386.rpm - MySQL-server-4.0.27-0.i386.rpm - MySQL-shared-4.0.27-0.i386.rpm - MySQL-shared-compat-4.0.27-0.i386.rpm )
But if I do a phpinfo => php see again mysql 3.23.58, ecen I make yum remove php, yum remove php-mysql and yum install php, yum install php-mysql.
And the new sql function of mysql 4 works in phpmyadmin ...
Add your own comment.