Mysql update gone wrong

[mimic]

I tried to upgrade mysql from 5.0 to 5.1, but got an error.

So i removed 5.1 files and downloaded 5.0 again:

tesla:/usr/local/directadmin/custombuild# ./build mysql
--14:32:18-- http://files.directadmin.com/services/all/mysql/debian/mysql-5.0.67-linux-i686.tar.gz
=> `mysql-5.0.67-linux-i686.tar.gz'
Resolving files.directadmin.com... 72.35.85.222
Connecting to files.directadmin.com[72.35.85.222]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 28,160,997 [application/x-gzip]

100%[=======================================================================================>] 28,160,997 261.37K/s ETA 00:00

14:34:04 (258.74 KB/s) - `mysql-5.0.67-linux-i686.tar.gz' saved [28160997/28160997]

Stopping mysqld ...
Stopping mysqld: [ FAILED ]
/etc/init.d/mysqld: line 9: cd: /usr/local/bin/mysql: Not a directory
Starting mysqld: [ OK ]
Giving mysqld a few seconds to start up...
Looking for 'mysql' in: /usr/local/mysql-5.0.67-linux-i686/bin/mysql
Looking for 'mysqlcheck' in: /usr/local/mysql-5.0.67-linux-i686/bin/mysqlcheck
This installation of MySQL is already upgraded to 5.0.67, use --force if you still need to run mysql_upgrade
/usr/local/mysql/bin/mysqlcheck: unknown option '--fix-db-names'
Restarting MySQL.
Stopping mysqld: [ OK ]
/etc/init.d/mysqld: line 9: cd: /usr/local/bin/mysql: Not a directory
Starting mysqld: [ OK ]
It is recommended to do "./build php n" after MySQL update.
tesla:/usr/local/directadmin/custombuild#

But the service stays offline.

 

[mimic]

090217 20:36:23 mysqld started
090217 20:36:23 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
090217 20:36:23 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
090217 20:36:28 InnoDB: Started; log sequence number 0 11612889
090217 20:36:28 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 Source distribution
090217 20:36:28 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown

090217 20:36:28 InnoDB: Starting shutdown...
090217 20:36:32 InnoDB: Shutdown completed; log sequence number 0 11612889
090217 20:36:32 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

090217 20:36:32 mysqld ended

 

[mimic]

090217 20:36:23 mysqld started
090217 20:36:23 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
090217 20:36:23 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
090217 20:36:28 InnoDB: Started; log sequence number 0 11612889
090217 20:36:28 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 Source distribution
090217 20:36:28 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown

090217 20:36:28 InnoDB: Starting shutdown...
090217 20:36:32 InnoDB: Shutdown completed; log sequence number 0 11612889
090217 20:36:32 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

090217 20:36:32 mysqld ended

from the error log in /home/mysql/

 

[scsi]

Maybe something is jacked up try reinstalling mysql. Remove the mysql rpm that you are not using.

 

[mimic]

Maybe something is jacked up try reinstalling mysql. Remove the mysql rpm that you are not using.

Thank you for your awnser.

I reinstalled MySQL numerous of times. And I did remove all the other debs.

It keeps complaining that some directories are not present. It might be broken symlinks?

I'm using Debian 4.

 

[scsi]

I would backup the database directory somewhere and completely remove mysql then reinstall it via custombuild.

 

[mimic]

I would backup the database directory somewhere and completely remove mysql then reinstall it via custombuild.

I had it installed via Custombuild, always had.

When i tried this afternoon to upgrade it from 5 to 5.1, it crashed, and never came back up..

..until now, it seems to be running. The websites are getting databse results.

But this is far from good.

 

[bizna]

try my.cnf

Just in case someone else has this issue, you should look at the settings in the file:

/etc/my.cnf

The system might have had different paths for the data and/or log and/or lock files, and now it's unable to use them.

Bare in mind: moving a MySQL from one path to the other, must be done strictly by the book. Especially if you have InnoDB tables.

Dotan