Bug 761978 (GLUSTER-246)

Summary:	MySQL hangs while using GlusterFS mount point as it's data directory
Product:	[Community] GlusterFS	Reporter:	Pavan Vilas Sondur <pavan>
Component:	locks	Assignee:	Pavan Vilas Sondur <pavan>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	2.0.6	CC:	gluster-bugs, matthaei, vbellur, vikas
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	RTP	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Pavan Vilas Sondur 2009-09-04 09:28:11 UTC

When the glusterfs mount point in a simple replicate configuration is used as the data directory for MySQL the following errors result.

<snip>
/var/lib/mysql points to the glusterfs mounted /srv/mysql.

Starting mysql on cluster-1 => everything is fine.
Starting mysql on cluster-2 ends up with:

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

Well after some minutes the startup script aborts:

cluster-2:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!

..
..

The errors points to some locking issue.

Comment 1 Pavan Vilas Sondur 2009-09-24 06:13:11 UTC

Turns out, this may not be a glusterfs bug after all. I successfully executed mysqld processes with the data directories replicated. MySQL clients can easily connect to mysqld processes. MySQL as of now does not seem to support running two mysqld processes sharing the same data directory (also one using a mirror of the other's data directory). I shared data directories between two mysqld processes using NFS and the mysqld processes did not run as well. 

GlusterFS supports MySQL clusters within the way MySQL is designed and if the limitation of mysqld processes not able to share data directories is resolved, GlusterFS would work fine as well.

I'll be closing the bug for now - Please re-open the bug if it is found that MySQL does work when 2 server processes share data directories successfully.