Re: [gentoo-user] [slightly O/T] mysql problems
On Thursday 16 Oct 2014 07:24:43 J. Roeleveld wrote: On Wednesday, October 15, 2014 09:40:56 PM Mick wrote: Well, I still have the backup from the live website, I can restore from it if I have to. However, what I find confusing is that the errors mention the live website's database name, not the local database. Shouldn't the import function import the tables into the local database? When you do it as you said: mysql -u webadmin -h localhost -p website_test website1_20141014.sql then that is the expected result (that it uses tables in the local database.) Can you do a search in the SQL-file for references to the remote database and post some of those lines? (Preferably only a subset referencing a single table) Thank you both for your help. I think I have fixed whatever it was that had gone sideways, but I can't explain it with any certainty. So, here is what happened. The local database name more than a year ago had a hyphen in the name; e.g. website-new. When listing /var/lib/mysql it was shown as: website@002dnew However, 9 months ago I had dropped that database and created a new database with an underscore instead of a hyphen; e.g. website_new. Imported the tables from the remote database into it and carried on with my work. Suddenly, I notice all these errors in the log. They were definitely not there before and in any case the website-new directory was no longer listed in /var/lib/mysql, while website_new was there. I dropped website_new, recreated website-new and the errors in the logs stopped. Finally, I dropped website-new again, recreated website_new and still no errors in the logs. :-) The only problem is that now I can't load the website from the recreated website_new database! LOL! I will look at it later, but wanted to report that the errors I posted about have thankfully gone. I blame it all on filesystem corruption of some sort (ext4), as it was running out of space, but can't be sure. Thanks again. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [slightly O/T] mysql problems
On Wednesday, October 15, 2014 09:40:56 PM Mick wrote: On Wednesday 15 Oct 2014 13:41:03 Kerin Millar wrote: Database changed mysql DROP TABLE `website1@002dnew`.`actions`; Is this a table for which it is also complaining that a corresponding tablespace doesn't exist in database `website1@@002dnew`? Your original post mentioned only a table named `webform_validation_rule_components`. Yes, there are loads of tables that it is complaining about. However, the name of the database mentioned in the logs is not that of the local machine, but of the remote. Whichever table(s) it is complaining about, if you happen to find a corresponding .idb file in a different database (sub-directory), you might be able to satisfy MySQL by copying it to where it is expecting to find it. If that works, you should then be able to drop it. I lost you here. We have the local database, website_test. In it I can see a number of tables. I also have other databases for different websites. Where am I supposed to look for corresponding .idb files? Sometimes, directly copying an InnoDB tablespace into place requires a more elaborate procedure but I won't muddy the waters by describing said procedure just yet. ERROR 1051 (42S02): Unknown table 'actions' mysql DISCARD TABLESPACE `website1@002dnew`.`actions`; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISCARD TABLESPACE `website1@002dnew`.`actions`' at line 1 = I think in mysql-5.5 I should be using DROP TABLESPACE instead? My mistake. The correct syntax for discarding the tablespace would be: ALTER TABLE table DISCARD TABLESPACE; I'm stating the obvious here, but be sure not to DROP or DISCARD TABLESPACE on a table whose tablespace does exist and for which you do not have a backup. Both commands are destructive. Well, I still have the backup from the live website, I can restore from it if I have to. However, what I find confusing is that the errors mention the live website's database name, not the local database. Shouldn't the import function import the tables into the local database? When you do it as you said: mysql -u webadmin -h localhost -p website_test website1_20141014.sql then that is the expected result (that it uses tables in the local database.) Can you do a search in the SQL-file for references to the remote database and post some of those lines? (Preferably only a subset referencing a single table) -- Joost
Re: [gentoo-user] [slightly O/T] mysql problems
On Wednesday 15 Oct 2014 02:14:37 Kerin Millar wrote: On 14/10/2014 23:25, Mick wrote: On Tuesday 14 Oct 2014 21:15:48 Kerin Millar wrote: * Have you upgraded MySQL recently without going through the documented upgrade procedure? [1] I'm still on mysql-5.5.39 OK. If it has always been running MySQL 5.5, there's nothing to be concerned about. No, sorry I wasn't clear. I have been upgrading mysql on this machine for some years now, always running stable versions. After each update I run: mysql_upgrade -h localhost -u root -p * Have you otherwise removed or modified files in the data directory? Not as far as I know. I have suspicions of fs corruption though (it's been running out of space lately and I haven't yet found out why). Not good. Which filesystem, if I may ask? XFS is preferable, due to its very good performance with O_DIRECT, which ext4 coming in second. Other filesystems may be problematic. In particular, ZFS does not support asynchronous I/O. ext4 In any case, go into /var/lib/mysql and check whether the file that it mentions exists. If it does not exist, try running: DROP TABLE `website1@002dnew`.`webform_validation_rule_components` If that does not work then try again, using DISCARD TABLESPACE as opposed to DROP TABLE. Note that the backtick quoting is necessary because of the presence of the @ symbol in the database name, which would otherwise be misinterpreted. Hmm ... I'm probably not doing this right. First of all, there is no local database /var/lib/mysql/website1, because this is the live website name, on the shared server. I only have /var/lib/mysql/website_test on the local dev machine. Then although I can see, e.g. -rw-rw 1 mysql mysql 8939 Oct 14 19:25 actions.frm -rw-rw 1 mysql mysql98304 Oct 14 19:25 actions.ibd in /var/lib/mysql/website_test, if I try to run DROP TABlE, logged in as (mysql) root, I get an unknown table, error 1051. = mysql USE website_test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql DROP TABLE `website1@002dnew`.`actions`; ERROR 1051 (42S02): Unknown table 'actions' mysql DISCARD TABLESPACE `website1@002dnew`.`actions`; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISCARD TABLESPACE `website1@002dnew`.`actions`' at line 1 = I think in mysql-5.5 I should be using DROP TABLESPACE instead? PS. This is the only database I have problems with. There are another dozen or so which I have imported in a similar fashion and there are no errors in the logs about them. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [slightly O/T] mysql problems
On 15/10/2014 13:05, Mick wrote: On Wednesday 15 Oct 2014 02:14:37 Kerin Millar wrote: On 14/10/2014 23:25, Mick wrote: On Tuesday 14 Oct 2014 21:15:48 Kerin Millar wrote: * Have you upgraded MySQL recently without going through the documented upgrade procedure? [1] I'm still on mysql-5.5.39 OK. If it has always been running MySQL 5.5, there's nothing to be concerned about. No, sorry I wasn't clear. I have been upgrading mysql on this machine for some years now, always running stable versions. After each update I run: mysql_upgrade -h localhost -u root -p * Have you otherwise removed or modified files in the data directory? Not as far as I know. I have suspicions of fs corruption though (it's been running out of space lately and I haven't yet found out why). Not good. Which filesystem, if I may ask? XFS is preferable, due to its very good performance with O_DIRECT, which ext4 coming in second. Other filesystems may be problematic. In particular, ZFS does not support asynchronous I/O. ext4 In any case, go into /var/lib/mysql and check whether the file that it mentions exists. If it does not exist, try running: DROP TABLE `website1@002dnew`.`webform_validation_rule_components` If that does not work then try again, using DISCARD TABLESPACE as opposed to DROP TABLE. Note that the backtick quoting is necessary because of the presence of the @ symbol in the database name, which would otherwise be misinterpreted. Hmm ... I'm probably not doing this right. First of all, there is no local database /var/lib/mysql/website1, because this is the live website name, on the shared server. I only have /var/lib/mysql/website_test on the local dev machine. Then although I can see, e.g. -rw-rw 1 mysql mysql 8939 Oct 14 19:25 actions.frm -rw-rw 1 mysql mysql98304 Oct 14 19:25 actions.ibd in /var/lib/mysql/website_test, if I try to run DROP TABlE, logged in as (mysql) root, I get an unknown table, error 1051. = mysql USE website_test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql DROP TABLE `website1@002dnew`.`actions`; Is this a table for which it is also complaining that a corresponding tablespace doesn't exist in database `website1@@002dnew`? Your original post mentioned only a table named `webform_validation_rule_components`. Whichever table(s) it is complaining about, if you happen to find a corresponding .idb file in a different database (sub-directory), you might be able to satisfy MySQL by copying it to where it is expecting to find it. If that works, you should then be able to drop it. Sometimes, directly copying an InnoDB tablespace into place requires a more elaborate procedure but I won't muddy the waters by describing said procedure just yet. ERROR 1051 (42S02): Unknown table 'actions' mysql DISCARD TABLESPACE `website1@002dnew`.`actions`; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISCARD TABLESPACE `website1@002dnew`.`actions`' at line 1 = I think in mysql-5.5 I should be using DROP TABLESPACE instead? My mistake. The correct syntax for discarding the tablespace would be: ALTER TABLE table DISCARD TABLESPACE; I'm stating the obvious here, but be sure not to DROP or DISCARD TABLESPACE on a table whose tablespace does exist and for which you do not have a backup. Both commands are destructive. --Kerin
Re: [gentoo-user] [slightly O/T] mysql problems
On Wednesday 15 Oct 2014 13:41:03 Kerin Millar wrote: Database changed mysql DROP TABLE `website1@002dnew`.`actions`; Is this a table for which it is also complaining that a corresponding tablespace doesn't exist in database `website1@@002dnew`? Your original post mentioned only a table named `webform_validation_rule_components`. Yes, there are loads of tables that it is complaining about. However, the name of the database mentioned in the logs is not that of the local machine, but of the remote. Whichever table(s) it is complaining about, if you happen to find a corresponding .idb file in a different database (sub-directory), you might be able to satisfy MySQL by copying it to where it is expecting to find it. If that works, you should then be able to drop it. I lost you here. We have the local database, website_test. In it I can see a number of tables. I also have other databases for different websites. Where am I supposed to look for corresponding .idb files? Sometimes, directly copying an InnoDB tablespace into place requires a more elaborate procedure but I won't muddy the waters by describing said procedure just yet. ERROR 1051 (42S02): Unknown table 'actions' mysql DISCARD TABLESPACE `website1@002dnew`.`actions`; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DISCARD TABLESPACE `website1@002dnew`.`actions`' at line 1 = I think in mysql-5.5 I should be using DROP TABLESPACE instead? My mistake. The correct syntax for discarding the tablespace would be: ALTER TABLE table DISCARD TABLESPACE; I'm stating the obvious here, but be sure not to DROP or DISCARD TABLESPACE on a table whose tablespace does exist and for which you do not have a backup. Both commands are destructive. Well, I still have the backup from the live website, I can restore from it if I have to. However, what I find confusing is that the errors mention the live website's database name, not the local database. Shouldn't the import function import the tables into the local database? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] [slightly O/T] mysql problems
Hi All, This may be slightly off topic, but I thought of asking here first. I noticed two problems, one specific to a particular database, the other more general. In reverse order: 1. I am getting this error when I start mysqld 141014 19:41:38 [Warning] /usr/sbin/mysqld: unknown option '--loose-federated' Sure enough I seem to have this in /etc/mysql/my.cnf: # Uncomment this to get FEDERATED engine support #plugin-load=federated=ha_federated.so loose-federated As far as I recall this is a default setting. Should I change it? 2. A particular database which I have imported locally from a live site gives me loads of this: 141014 19:41:37 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 141014 19:41:37 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './website1@002dnew/webform_validation_rule_components.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this. Is this some error imported from the live site, or is it due to something being wrong locally? Any ideas how to fix this? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [slightly O/T] mysql problems
On 10/14/2014 11:54 AM, Mick wrote: Hi All, This may be slightly off topic, but I thought of asking here first. I noticed two problems, one specific to a particular database, the other more general. In reverse order: 1. I am getting this error when I start mysqld 141014 19:41:38 [Warning] /usr/sbin/mysqld: unknown option '--loose-federated' Did you compile with the 'extraengine' USE flag? It's required for federated engine support. 141014 19:41:37 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './website1@002dnew/webform_validation_rule_components.ibd'! Does this file (and directory) exist? Is this some error imported from the live site, or is it due to something being wrong locally? Most likely the live website stores its files in a different place. I'm not sure how to fix that, though. I would imagine the error text gives hints. (DISCARD TABLESPACE and IMPORT TABLESPACE - I've never used them.) Then again, I only use mysql for pretty basic stuff. Dan
Re: [gentoo-user] [slightly O/T] mysql problems
On 14/10/2014 19:54, Mick wrote: Hi All, This may be slightly off topic, but I thought of asking here first. I noticed two problems, one specific to a particular database, the other more general. In reverse order: 1. I am getting this error when I start mysqld 141014 19:41:38 [Warning] /usr/sbin/mysqld: unknown option '--loose-federated' Sure enough I seem to have this in /etc/mysql/my.cnf: # Uncomment this to get FEDERATED engine support #plugin-load=federated=ha_federated.so loose-federated As far as I recall this is a default setting. Should I change it? No. I presume that you are not actively using the federated storage engine but let's put that aside because there is more to this error than meets the eye. Check your MySQL error log and look for any anomalies from the point at which MySQL is started. If you don't know where the log file is, execute SELECT @@log_error. I have several questions: * Have you started MySQL with skip-grant-tables in effect? * Have you upgraded MySQL recently without going through the documented upgrade procedure? [1] * Have you copied files into MySQL's data directory that originated from a different version of MySQL? * Have you otherwise removed or modified files in the data directory? 2. A particular database which I have imported locally from a live site gives me loads of this: The wording here suggests a broader context that would be relevant. Please be specific as to the circumstances. What procedure did you employ in order to migrate and import the database? What do you mean by live site? Which versions of MySQL are running at both source and destination? How are they configured? 141014 19:41:37 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 141014 19:41:37 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './website1@002dnew/webform_validation_rule_components.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this. Is this some error imported from the live site, or is it due to something being wrong locally? MySQL believes that an InnoDB table named webform_validation_rule_components presently exists in a database named website1@002dnew but the corresponding tablespace file does not exist, relative to the MySQL datadir. The reason for this may become clear if you answer the questions posed above. --Kerin [1] https://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html (and its predecessors)
Re: [gentoo-user] [slightly O/T] mysql problems
On Tuesday 14 Oct 2014 20:21:27 Daniel Frey wrote: On 10/14/2014 11:54 AM, Mick wrote: Hi All, This may be slightly off topic, but I thought of asking here first. I noticed two problems, one specific to a particular database, the other more general. In reverse order: 1. I am getting this error when I start mysqld 141014 19:41:38 [Warning] /usr/sbin/mysqld: unknown option '--loose-federated' Did you compile with the 'extraengine' USE flag? It's required for federated engine support. I had emerged mysql with USE=-extraengine it seems. However the configuration includes the federated option regardless. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [slightly O/T] mysql problems
On Tuesday 14 Oct 2014 21:15:48 Kerin Millar wrote: On 14/10/2014 19:54, Mick wrote: # Uncomment this to get FEDERATED engine support #plugin-load=federated=ha_federated.so loose-federated As far as I recall this is a default setting. Should I change it? No. I presume that you are not actively using the federated storage engine but let's put that aside because there is more to this error than meets the eye. Check your MySQL error log and look for any anomalies from the point at which MySQL is started. If you don't know where the log file is, execute SELECT @@log_error. 141014 19:41:37 [Warning] No argument was provided to --log-bin, and --log- bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=mysqld-bin' to avoid this problem. 141014 19:41:37 InnoDB: The InnoDB memory heap is disabled 141014 19:41:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins 141014 19:41:37 InnoDB: Compressed tables use zlib 1.2.8 141014 19:41:37 InnoDB: Using Linux native AIO 141014 19:41:37 InnoDB: Initializing buffer pool, size = 16.0M 141014 19:41:37 InnoDB: Completed initialization of buffer pool 141014 19:41:37 InnoDB: highest supported file format is Barracuda. 141014 19:41:37 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 141014 19:41:37 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './website1@002dnew/actions.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html I have several questions: * Have you started MySQL with skip-grant-tables in effect? Not knowingly. How do I find out? * Have you upgraded MySQL recently without going through the documented upgrade procedure? [1] I'm still on mysql-5.5.39 Installed versions: 5.5.39(16:42:22 08/09/14)(community perl ssl - bindist -cluster -debug -embedded -extraengine -jemalloc -latin1 -max-idx-128 -minimal -profiling -selinux -static -static-libs -systemtap -tcmalloc -test) * Have you copied files into MySQL's data directory that originated from a different version of MySQL? No, not manually. * Have you otherwise removed or modified files in the data directory? Not as far as I know. I have suspicions of fs corruption though (it's been running out of space lately and I haven't yet found out why). 2. A particular database which I have imported locally from a live site gives me loads of this: The wording here suggests a broader context that would be relevant. Please be specific as to the circumstances. What procedure did you employ in order to migrate and import the database? What do you mean by live site? Which versions of MySQL are running at both source and destination? How are they configured? mysql -u webadmin -h localhost -p website_test website1_20141014.sql The server is on 5.5.36. website1 is the database name of the live site, and website_test is the local development database. The server is a shared server, so I'm getting its vanilla configuration with no choice on the matter. The local configuration is attached. Is this some error imported from the live site, or is it due to something being wrong locally? MySQL believes that an InnoDB table named webform_validation_rule_components presently exists in a database named website1@002dnew but the corresponding tablespace file does not exist, relative to the MySQL datadir. The reason for this may become clear if you answer the questions posed above. I'll check this when I get a minute and report back. Right now the machine is locked up - no space left on the root partition for some obscure reason. I need to start clearing stuff out. Thanks for your help! -- Regards, Mick # /etc/mysql/my.cnf: The global mysql configuration file. # $Header: /var/cvsroot/gentoo-x86/dev-db/mysql/files/my.cnf-5.5,v 1.3 2014/04/25 00:43:46 jmbsvicetto Exp $ # The following options will be passed to all MySQL clients [client] #password = your_password port= 3306 socket = /var/run/mysqld/mysqld.sock [mysql] character-sets-dir=/usr/share/mysql/charsets default-character-set=utf8 [mysqladmin] character-sets-dir=/usr/share/mysql/charsets default-character-set=utf8 [mysqlcheck] character-sets-dir=/usr/share/mysql/charsets default-character-set=utf8 [mysqldump]
Re: [gentoo-user] [slightly O/T] mysql problems
On 14/10/2014 23:25, Mick wrote: On Tuesday 14 Oct 2014 21:15:48 Kerin Millar wrote: On 14/10/2014 19:54, Mick wrote: # Uncomment this to get FEDERATED engine support #plugin-load=federated=ha_federated.so loose-federated As far as I recall this is a default setting. Should I change it? No. I presume that you are not actively using the federated storage engine but let's put that aside because there is more to this error than meets the eye. Check your MySQL error log and look for any anomalies from the point at which MySQL is started. If you don't know where the log file is, execute SELECT @@log_error. 141014 19:41:37 [Warning] No argument was provided to --log-bin, and --log- bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=mysqld-bin' to avoid this problem. 141014 19:41:37 InnoDB: The InnoDB memory heap is disabled 141014 19:41:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins 141014 19:41:37 InnoDB: Compressed tables use zlib 1.2.8 141014 19:41:37 InnoDB: Using Linux native AIO 141014 19:41:37 InnoDB: Initializing buffer pool, size = 16.0M 141014 19:41:37 InnoDB: Completed initialization of buffer pool 141014 19:41:37 InnoDB: highest supported file format is Barracuda. 141014 19:41:37 InnoDB: Operating system error number 2 in a file operation. InnoDB: The error means the system cannot find the path specified. InnoDB: If you are installing InnoDB, remember that you must create InnoDB: directories yourself, InnoDB does not create them. 141014 19:41:37 InnoDB: Error: trying to open a table, but could not InnoDB: open the tablespace file './website1@002dnew/actions.ibd'! InnoDB: Have you moved InnoDB .ibd files around without using the InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE? InnoDB: It is also possible that this is a temporary table #sql..., InnoDB: and MySQL removed the .ibd file for this. InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html Nothing particularly interesting there. I have several questions: * Have you started MySQL with skip-grant-tables in effect? Not knowingly. How do I find out? If you had, you would know. It disables the privilege handling system outright. Typically it's used in situations where the root password has been forgotten or just prior to executing mysql_upgrade. The reason for asking is that it may also prevent some storage engines from loading, in which case their options will not be recognized. In turn, this may result in confusing error messages such as the one that you encountered. However, with the benefit of being able to read your my.cnf, the explanation turns out to be much simpler. You have loose-federated specified as an option but you are not loading the corresponding storage plugin. There is also the possibility that the engine was not compiled in at all (whether as a plugin or not). Simply remove or comment the line specifying this option and the error should go away. * Have you upgraded MySQL recently without going through the documented upgrade procedure? [1] I'm still on mysql-5.5.39 OK. If it has always been running MySQL 5.5, there's nothing to be concerned about. Installed versions: 5.5.39(16:42:22 08/09/14)(community perl ssl - bindist -cluster -debug -embedded -extraengine -jemalloc -latin1 -max-idx-128 -minimal -profiling -selinux -static -static-libs -systemtap -tcmalloc -test) * Have you copied files into MySQL's data directory that originated from a different version of MySQL? No, not manually. Good. * Have you otherwise removed or modified files in the data directory? Not as far as I know. I have suspicions of fs corruption though (it's been running out of space lately and I haven't yet found out why). Not good. Which filesystem, if I may ask? XFS is preferable, due to its very good performance with O_DIRECT, which ext4 coming in second. Other filesystems may be problematic. In particular, ZFS does not support asynchronous I/O. 2. A particular database which I have imported locally from a live site gives me loads of this: The wording here suggests a broader context that would be relevant. Please be specific as to the circumstances. What procedure did you employ in order to migrate and import the database? What do you mean by live site? Which versions of MySQL are running at both source and destination? How are they configured? mysql -u webadmin -h localhost -p website_test website1_20141014.sql Ah, just using DDL. That shouldn't have caused any trouble. The server is on 5.5.36. website1 is the database name of the live site, and website_test is the local development database. The server is a shared server, so I'm getting its vanilla configuration with no choice on the matter. The local configuration is attached. Is this some error imported from
