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://gluster.org/pipermail/gluster-users/attachments/20120331/18a477e9/attachment.htm>
