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