I am experiencing a problem with the MySQL innodb_file_per_table innodb
configuration setting on a distributed-replicated Gluster volume.
Gluster Version: 3.2.5
Mysql: 5.1.61
I am attempting to configure MySQL with the file_per_table option enabled, as
this would seem to provide a lot of benefit when running MySQL on Gluster
backend storage. Under default MySQL configuration, MySQL's ibdata file
would just be one large file. By using the innodb_file_per_table option, MySQL
creates a separate table space (separate ibdata file) for every table. I would
like to use innodb_file_per_table because this would spread the distribution of
IO across more drives on the underlying Gluster volume, not to mention some
other benefits. Refer to
http://dev.mysql.com/doc/refman/5.1/en/innodb-multiple-tablespaces.html
The problem is that the innodb_file_per_table option does not seem to work on
the Gluster distributed-replicated volume. When I run mysql_install_db this is
what I get:
mysql_install_db
Installing MySQL system tables...
Installation of system tables failed! Examine the logs in
/mnt/glusterfs/db/mysql for more information.
Here is what the mysql error log reports after running mysql_install_db:
120331 17:51:17 [ERROR] /usr/sbin/mysqld: Incorrect information in file:
'./mysql/user.frm'
ERROR: 1033 Incorrect information in file: './mysql/user.frm'
120331 17:51:17 [ERROR] Aborting
120331 17:51:17 [Note] /usr/sbin/mysqld: Shutdown complete
The DEBUG logs from the Gluster client mount log are at
http://pastebin.com/ZFQWHjEq
The volume where the mysql data directory is stored was created with this
command (where variables were substituted appropriately):
gluster volume create ${VOLNAME} replica 2 transport tcp ${HOST1}:${BRICK1}
${HOST2}:${BRICK1} ${HOST1}:${BRICK2} ${HOST2}:${BRICK2}
Based on that volume create command, you can see that I have to servers.
Mysql actually seems to run just fine with the innodb_file_per_table setting
enabled if I create the mysql database via mysql_install_db on a local
(non-gluster) file system, then copy the mysql data directory into the gluster
mount point, and finally start mysql configured to use the Gluster mount point.
However, as soon as I attempt to import a mysql dump file, I hit the same
problem. It seems that whenever Mysql attempts to create new innodb/ibdata files
with this configuration there is what *feels like* a locking issue.
If I disable the innodb_file_per_table option I have no apparent problems
running MySQL on this Gluster volume.
One interesting to note is that if I shut down the Gluster daemon on one of the
servers, MySQL works as expected with the innodb_file_per_table options enabled.
In essence, no replication would be occurring on the Gluster volume when I do
this.
Any help is much appreciated. Thank you.
Jamie
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120331/18a477e9/attachment.html>