Bug #14281 MySQL server 4.1.12 Fails to start on a NFS mounted directory in HP-UX platform
Submitted: 25 Oct 2005 6:47 Modified: 25 Oct 2005 12:23
Reporter: tejaswi gk Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.12 OS:HP/UX (HP-UX)
Assigned to: CPU Architecture:Any

[25 Oct 2005 6:47] tejaswi gk
Description:
MySQL server fails to startup on HP-UX paltform if the install directory is on a Mounted NFS directory.
When we refer the .err file in the data directory we found the following error message:

"051020 07:08:35  mysqld started
InnoDB: Unable to lock ./ibdata1, error: 13
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
051020  7:08:36  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error in creating or opening ./ibdata1
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
051020  7:08:36 [ERROR] Can't init databases
051020  7:08:36 [ERROR] Aborting

051020  7:08:36 [Note] /mysql/bin/mysqld: Shutdown complete"

This error message is not releven as we have only one mysql server running. This occurs only on all available HP-UX  platforms both 32bit and 64 bit binaries give out this error and will never start at all.
If the mount directory is a local mount volume then there is no problem.

How to repeat:
UnZIP the MySQL 4.1.12 binaris and untar the file to a directory which is a NFS mount on HP-UX platform.
Start the mysql server you find that mysql server will never start thne if you look in the .err file in the data directory then you find the following error.

"051020 07:08:35  mysqld started
InnoDB: Unable to lock ./ibdata1, error: 13
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
051020  7:08:36  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error in creating or opening ./ibdata1
InnoDB: Could not open or create data files.
InnoDB: If you tried to add new data files, and it failed here,
InnoDB: you should now edit innodb_data_file_path in my.cnf back
InnoDB: to what it was, and remove the new ibdata files InnoDB created
InnoDB: in this failed attempt. InnoDB only wrote those files full of
InnoDB: zeros, but did not yet use them in any way. But be careful: do not
InnoDB: remove old data files which contain your precious data!
051020  7:08:36 [ERROR] Can't init databases
051020  7:08:36 [ERROR] Aborting

051020  7:08:36 [Note] /mysql/bin/mysqld: Shutdown complete"
[25 Oct 2005 12:23] Valeriy Kravchuk
Thank you for a problem report. But it really not a bug, but a problem you should avoid, especially when using InnoDB tables. According to the manual (http://dev.mysql.com/doc/refman/4.1/en/multiple-servers.html):

"Warning: Normally you should never have two servers that update data in the same databases. This may lead to unpleasant surprises if your operating system does not support fault-free system locking. If (despite this warning) you run multiple servers using the same data directory and they have logging enabled, you must use the appropriate options to specify log filenames that are unique to each server. Otherwise, the servers try to log to the same files. Please note that this kind of setup only works with ISAM, MyISAM and MERGE tables, and not with any of the other storage engines.

The warning against sharing a data directory among servers also applies in an NFS environment. Allowing multiple MySQL servers to access a common data directory over NFS is a very bad idea.
    * The main problem is that NFS is the speed bottleneck. It is not meant for such use.
    * Another risk with NFS is that you must devise a way to ensure that two or more servers do not interfere with each other. Usually NFS file locking is handled by the lockd daemon, but at the moment there is no platform that performs locking 100% reliably in every situation.

Make it easy for yourself: Forget about sharing a data directory among servers over NFS. A better solution is to have one computer that contains several CPUs and use an operating system that handles threads efficiently."

So, the fact that this setup shoud not work for InnoDB is clearly documented.
[25 Oct 2005 18:20] James Day
See the no_auth_nlm option described in section E of the NFS FAQ at http://nfs.sourceforge.net/ . This looks like a known NFS issue rather than a MySQL issue with either single or multiple servers running.