Skip navigation links

User Comments

Posted by [name withheld] on October 22 2003 10:11am[Delete] [Edit]

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.

Posted by [name withheld] on August 28 2004 11:37am[Delete] [Edit]

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.....

Posted by Gustavo on October 19 2004 10:04am[Delete] [Edit]

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.

Posted by Daniel Lorch on January 9 2005 10:17pm[Delete] [Edit]

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

Posted by Kaloyan Tenchov on January 10 2005 11:47pm[Delete] [Edit]

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).

Posted by Angel Justo on May 18 2005 10:51am[Delete] [Edit]

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.

Posted by S Harper on June 18 2005 7:06pm[Delete] [Edit]

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.

Posted by Richard Fearn on September 23 2005 8:39pm[Delete] [Edit]

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.

Posted by Martyn Kinder on February 14 2006 4:21pm[Delete] [Edit]

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.

Posted by Darcy Baston on March 18 2006 3:45pm[Delete] [Edit]

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.

Posted by stephane cottin on June 23 2006 10:04am[Delete] [Edit]

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 ...