Getting MySQL 5.5 working with CustomBuild

truenegative

truenegative

Verified User
Joined
Feb 16, 2006
Messages
153
First, this was done on CentOS 5.5 with everything current....

I set mysql in custombuild to 5.5 first, but it didn't allow it to be upgraded....
Code: 
#./build set mysql 5.5

Download MySQL rpms from the DA site:
Code: 
wget http://files.directadmin.com/services/all/mysql/64-bit/5.5.8/MySQL-client-5.5.8-1.linux2.6.x86_64.rpm
wget http://files.directadmin.com/services/all/mysql/64-bit/5.5.8/MySQL-devel-5.5.8-1.linux2.6.x86_64.rpm
wget http://files.directadmin.com/services/all/mysql/64-bit/5.5.8/MySQL-server-5.5.8-1.linux2.6.x86_64.rpm
wget http://files.directadmin.com/services/all/mysql/64-bit/5.5.8/MySQL-shared-5.5.8-1.linux2.6.x86_64.rpm


Install them:
Code: 
rpm -Uvh *
Preparing...                ########################################### [100%]
   1:MySQL-shared           ########################################### [ 25%]
   2:MySQL-client           ########################################### [ 50%]
   3:MySQL-devel            ########################################### [ 75%]
   4:MySQL-server           ########################################### [100%]
101227 15:33:19 [ERROR] /usr/sbin/mysqld: unknown option '--skip-locking'
101227 15:33:19 [ERROR] Aborting

101227 15:33:19 [Note] /usr/sbin/mysqld: Shutdown complete


Installation of system tables failed!  Examine the logs in
/var/lib/mysql for more information.

You can try to start the mysqld daemon with:

    shell> /usr/sbin/mysqld --skip-grant &

and use the command line tool /usr/bin/mysql
to connect to the mysql database and look at the grant tables:

    shell> /usr/bin/mysql -u root mysql
    mysql> show tables

Try 'mysqld --help' if you have problems with paths.  Using --log
gives you a log in /var/lib/mysql that may be helpful.

Please consult the MySQL manual section
'Problems running mysql_install_db', and the manual section that
describes problems on your OS.  Another information source are the
MySQL email archives available at http://lists.mysql.com/.

Please check all of the above before mailing us!  And remember, if
you do mail us, you MUST use the /usr/bin/mysqlbug script!


Then run mysql_upgrade...
Code: 
# mysql_upgrade -uroot -p
Enter password: 
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
Running 'mysqlcheck with default connection arguments
da_roundcube.cache                                 OK
da_roundcube.contactgroupmembers                   OK
da_roundcube.contactgroups                         OK
da_roundcube.contacts                              OK
da_roundcube.identities                            OK
da_roundcube.messages                              OK
da_roundcube.session                               OK
da_roundcube.users                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.general_log                                  OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.ndb_binlog_index                             OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.servers                                      OK
mysql.slow_log                                     OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.user                                         OK
Running 'mysql_fix_privilege_tables'...


Lastly rebuild php...
Code: 
# ./build php n


That's it! Worked on my system!
 
i get this error :(


error: %pre(MySQL-server-5.5.8-1.linux2.6.x86_64) scriptlet failed, exit status 1
error: install: %pre scriptlet failed (2), skipping MySQL-server-5.5.8-1.linux2.6
 
In my case I had to manually remove mysql-* packages, stop service and kill remaining processes, then do rpm -ivh *. Don't know why there were remaining process, but there was. It was freshly installed test site DA on CentOS 5.5 64bit.
 
I am running Centos 5.4 32-bit and downloaded the 32-bit files. The task, however, was a bit more complicated as I ran into the same error as Frej.

Trying to upgrade the server manually revealed the truth: an error message told me that this should NOT be done being a bit dangerous and that I should dump the databases and import them.

So what I did was as follows:

Code: 
mysqldump -u da_admin -p --all-databases >/tmp/mysqldump.sql
/etc/init.d/mysqld stop
rpm -e <each mysql-5.0 package>
rpm -i <each mysql-5.5 package>
/etc/init.d/mysqld start
Then, when I ran

Code: 
mysql_upgrade -uda_admin -p

I got quite a few error messages like:

Code: 
error    : Table upgrade required. Please do "REPAIR TABLE `site_sections`" or dump/reload to fix it!
note     : The storage engine for the table doesn't support repair

So what I ended up was

Code: 
#root>mysql -u da_admin -p
mysql>source /tmp/mysqldmp.sql

And finally rebuilt PHP. Everything seems to be working now (fingers crossed!)

EDIT: Just as Jeff says, DO NOT use /tmp as a storage directory!
Markku
 
Last edited:
I would suggest NOT using the /tmp directory to store the database dump. It used to be standard to delete the contents of the /tmp directory on a reboot. While this doesn't seem to be the case any longer with the default installs of CentOS (the distribution I use), it could be for other OS Distributions.

You never know when you might have a system failure which results in, or requires, a reboot.

Jeff
 
Jeff,

jlasman said:
I would suggest NOT using the /tmp directory to store the database dump.
Click to expand...
Jeff

You are absolutely correct here and what I actually did was dump the database to /tmp for a checkout and then move it to safe directory. As you said one should never rely on anything stored to /tmp. It may also accessible by other people there.

As for reboots: what are they :)? This very VPS ran 360 days without the need for one and why it was needed was the installation of a new VPS control panel. I really like my VPS provider!

My secondary backup VPS is a completely different beast and an uptime of 2 weeks can be considered long. Well, if one pays $25/year for 1GB mem + 50GB disk + 1TB banwidth one cannot expect luxury.

Markku
 
meto said:
In my case I had to manually remove mysql-* packages, stop service and kill remaining processes, then do rpm -ivh *. Don't know why there were remaining process, but there was. It was freshly installed test site DA on CentOS 5.5 64bit.
Click to expand...

Ah yes... my fault. I forgot to say to remove the old mysql packages.
 
You must log in or register to reply here.
Back
Top