I run a WordPress website. Today I found that wp_posts table is crashed. When I tried to repair the table, I got the following error:
REPAIR TABLE wp_posts;
error Can't create new tempfile: './[databasename]/wp_posts.TMD'
repair status Operation failed
I tried to run the following command in shell:
myisamchk -r -f wp_posts.MYI
error: File 'wp_posts.MYI' doesn't exist
Can you please tell me what else I can try to fix this problem?
Turned out that "myisamchk -r -f wp_posts.MYI" was the correct solution. I just had to go to the data folder.
In my CentOS system, I changed directory to /var/lib/mysql/[database]/and found wp_posts.MYI
After removing this file, repair was successful.
Try stopping your service using the following command sudo service mysql stop
Now do the repair check myisamchk -r -f -o /var/lib/mysql/DatabaseName/wp_posts
Start your service and enjoy it!
It works for me
Try adding the following line to your wp-config.php file:
define( 'WP_ALLOW_REPAIR', true );
Then go to:
/wp-admin/maint/repair.php
That should take effect and automatically repair your crashed table.
For mariaDB and some other combination of OS and DB version, the file may also be located under /config/databases/[DATABASE].
Try to run as root (sudo su):
service mysql stop
myisamchk -rf /config/databases/[databasename]/wp_posts.MYI
service mysql start
I just had the same trouble. The problem was the .TMD file already existed and mysqlrepair refused to overwrite it. I removed the .TMD file and the mysqlrepair worked famously. I had to stop the process attempting to use the crashed table, then run the repair.
When I saw this error in phpMyadmin, I got around it by navigating to /var/lib/mysql/[database]/ and deleting the TMD file for the table I was trying to repair (not the MYI file as stated in the explanation above).
When I tried getting rid of the MYI file, the repair operation didn't work.
Related
I want to copy the database tables from my production server to a local test machine so I can perform test om (copies of) the real data.
I stopped mysql and deleted all the frm, MYD and MYI files. Starting mysql here and querying show tables gives an empty result set. I then shut down mysql and copied all the frm, MYD and MYI files from the server. When starting mysql "show tables" shows the tables as expected but trying to query them I get the error message
ERROR 1017 (HY000): Can't find file: './WhateverTableIQuery.frm'
(errno: 13)
But the WhateverTableIQuery.frm file is on the disc and is identical to the one on the server.
Any ideas about what might be the problem?
I'd suggest giving two things a try:
1. Check Permissions
Make sure that your MySQL data directory and all the files in it are owned by mysql user and mysql group. This may not be the case if you copied the files onto your local test machine as root user:
chown -R mysql:mysql your-mysql-data-dir-here
2. Repair corrupted tables
Use mysqlcheck to check for corrupted tables and repair them if it finds any:
mysqlcheck -u root -p --auto-repair --all-databases
If you still can't use the tables after that then give mysqldump a go!
I encountered the same issue after restoring a MySQL database with frm and MYD files. After a number of hours spent I observed that I have configured the database directory with only read and write permission to mysql user but not execute permission. After adding execute permission to the database directory, the problem was solved.
I did have the very same issue a couple minutes ago and it took me a few minutes to realize that I had insufficient permission to access the .sql file I wanted to import.
In order to get rid of this problem you could just move the file to a place you know you have access to (with your current user) for sure. (eg. ~/Home_directory).
I hope I could help some lonely soul that was searching for the answer just like I was.
I had the same issue and did this...
Delete Migrations Folder
Drop the _migrationhistory table
Enable, Add and Update migration
I'm sure there's a much better way to solve this but, it worked for me.
I changed permissions for the mysql-data-directory as well as the <table>.frm file.
If using as root user:
chmod 600 mysql-data-directory chmod 600
mysql-data-directory/tableOfData.frm
If using as non-root user:
chmod 660 mysql-data-directory
chmod 660 mysql-data-directory/tableOfData.frm
This error, "General error: 1017 Can't find file", also happened on Windows with WAMP if the table doesn't exist.
Try following things:
repair whole database
change permission to mysql:mysql
restart mysql service
One of these will work.
I was repairing this table suddenly server hanged and when I returned back all tables are ok but this one showing 'in use' and when I try to repair it doesn't proceed.
ERROR 144 - Table './extas_d47727/xzclf_ads' is marked as crashed and last (automatic?) repair failed
What can I do to repair it?
If your MySQL process is running, stop it. On Debian:
sudo service mysql stop
Go to your data folder. On Debian:
cd /var/lib/mysql/$DATABASE_NAME
Try running:
myisamchk -r $TABLE_NAME
If that doesn't work, you can try:
myisamchk -r -v -f $TABLE_NAME
You can start your MySQL server again. On Debian:
sudo service mysql start
Try running the following query:
repair table <table_name>;
I had the same issue and it solved me the problem.
This was my experience resolving this issue. I'm using XAMPP.
I was getting the error below
Fatal error: Can't open and lock privilege tables: Table '.\mysql\db' is marked as crashed and last (automatic?) repair failed
This is what I did to resolve it, step by step:
went to location C:\xampp\mysql, For you, location may be different, make sure you are in right file location.
created backup of the data folder as data-old.
copied folder "mysql" from C:\xampp\mysql\backup
pasted it inside C:\xampp\mysql\data\ replacing the old mysql folder.
And it worked. Keep in mind, I have already tried around 10 solutions and they didnt work for me. This solutions may or may not work for you but regardless, make backup of your data folder before you do anything.
Note: I would always opt to resolve this with repair command but in my case, i wasnt able to get mysql started at all and i wasnt able to get myisamchk command to work.
Regardless of what you do, create a periodic backup of your database.
If it gives you permission denial while moving to /var/lib/mysql then use the following solution
$ cd /var/lib/
$ sudo -u mysql myisamchk -r -v -f mysql/<DB_NAME>/<TABLE_NAME>
I needed to add USE_FRM to the repair statement to make it work.
REPAIR TABLE <table_name> USE_FRM;
I got myisamchk: error: myisam_sort_buffer_size is too small as error.
The solution
myisamchk -r -v mysql/<DB_NAME>/<TABLE_NAME> --sort_buffer_size=2G
Go to data_dir and remove the Your_table.TMP file after repairing <Your_table> table.
If this happend to your XAMPP installation, just copy global_priv.MAD and global_priv.MAI files from ./xampp/mysql/backup/mysql/ to ./xampp/mysql/data/mysql/.
Without stopping the database I go to this folder
cd /var/lib/mysql/$DATABASE_NAME
and then execute the following command
myisamchk -r -v -f $TABLE_NAME
Without having any issue the command successfully completed and resolve the issue
Thank you
I tried the options in the existing answers, mainly the one marked correct which did not work in my scenario. However, what did work was using phpMyAdmin. Select the database and then select the table, from the bottom drop down menu select "Repair table".
Server type: MySQL
Server version: 5.7.23 - MySQL Community Server (GPL)
phpMyAdmin: Version information: 4.7.7
This is a 100% solution. I tried it myself.
myisamchk -r -v -f --sort_buffer_size=128M --key_buffer_size=128M /var/lib/mysql/databasename/tabloname
enter to your mysql and select your database
then
repair table ;
this work with me
I am getting the following:
Native table 'performance_schema'.'file_instances' has the wrong structure
Native table 'performance_schema'.'cond_instances' has the wrong structure
Native table 'performance_schema'.'rwlock_instances' has the wrong structure
Native table 'performance_schema'.'mutex_instances' has the wrong structure
...
And on it goes
These errors come up when I restart MySql. It seems to cause MySql Administrator to become unstable, I get a lot of:
"MySQL server has gone away"
Try following command in shell (the root user here is the mysql root user, not the system root)
sudo mysql_upgrade -u root -p
sudo service mysql restart
Make sure to restart mysql after running this (All credit to #Mikepote in the comments.)
Im my case it appeared when specific query was run on a table.
And log also contained:
Missing system table mysql.proxies_priv; please run mysql_upgrade to
create it
I've run mysql_upgrade and after that problem has gone.
I had this problem, the answer was here by #Berend de Boer
Restart mysql after the upgrade.
[ERROR]Native table performance schema has the wrong structure
This error is encountered when you installed MySQL over a previous installation that was configured without the Performance Schema or an older version of Performance schema that may not have all the current tables.
I also encountered this issue on mamp. To resolve it, I have executed the following:
cd /Applications/MAMP/bin/
sudo ./upgradeMysql.sh
Remember to restart the mysql server.
You can read the Performance Schema Build Configuration for more details.
If the database is a Akonadi (KDE) database the above won't be enough.
You need to mirror the options given to your mysqld, check with
ps aux | grep mysql
Copy the options to the mysql_upgrade commands (I did not need '-u root -p' but you might)
mysql_upgrade --defaults-file=/home/USER/.local/share/akonadi/mysql.conf --datadir=/home/USER/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-USER.x0Bvxr/mysql.socket
I really think the --socket option is the key.
Try mysql_upgrade and then restart mysql and its working back
It seems this happens after you have done upgrade. Simply restart mysql:
Like run below command in CMD
sudo mysql_upgrade -u root -p
service mysql restart
and the error should now have disappeared.
Apparently MySQL schema storage is broken due to a reason. These reasons may be:
You have broken the database information_schema
File system corrupted or some bugs in the file system damaged the database.
MySQL internals broke the schema database due to a bug in MySQL (maybe nobody encountered it before).
If you don't have backups however you are still able to access your data, first backup your data then do the following:
If you have backups, then reinstall MySQL (before that completely clear all data of mysql) and then import your data.
I installed LAMP on Ubuntu 11.04 and copy project from Windows.
PHP directory (/ci/) to var/www/
and
MySQL project directory (/ci/) to var/lib/mysql/
Full text of error that i get:
A Database Error Occurred
Error Number: 1017
Can't find file: './ci/users.frm' (errno: 13)
SELECT COUNT(*) AS `numrows` FROM (`users`) WHERE `email` = 'admin#localsite.com'
I googled that its permission problem, but don't know what do next.
Log from /var/log/mysql/error.log:
110622 19:27:21 [ERROR] /usr/sbin/mysqld: Can't find file: './ci/users.frm' (errno: 13)
Permissions problem meaning the permissions on the file. MySQL probably can't read it. Just change the owner and group to mysql and it should work.
chown mysql:mysql /var/lib/mysql/ci/*
As well as the files being readable by the MySQL user, the directory containing the .MYI files needs to be read, write and executable by the MySQL user. On my system this was achieved by:
chown -R mysql:mysql /var/lib/mysql/dbname
chmod -R 660 /var/lib/mysql/dbname
chown mysql:mysql /var/lib/mysql/dbname
chmod 700 /var/lib/mysql/dbname
This is an old topic, but I didn't find anything that worked for me so for anyone running into the same problem, yet the above file permission suggestions still don't change the "Can't find file" errors, here's what worked for me and my particular issue.
I was doing a rescue from one CentOS server to another using a recovery image, which had a different OS than the original OS and the original filesystem was mounted on a temporary dir. While I had access to the original /var/lib/mysql files, I didn't have access to the mysql admin or dump utilities, which requires the server to be running anyway (it's not automatically included when doing a recovery from a read-only image). Backups were a week old and I wanted to see if I could get the most recent data possible.
Changing the standard file permissions on these still kept giving "Can't find file" for nearly all of the database tables, however I could see that the tables were there. Turns out it was related to SELinux context on the files I had moved over using rysnc. All of the rescued dirs and files looked like this:
$ ls -alZ
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_dev
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_local
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_production
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_staging
The -Z flag notes the security context of files and dirs. Notice the unconfined_u and admin_home_t context. These are different from what they should be:
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
Changing these database files to the proper context solved the problem and gave proper access to mysqld using the chcon command:
$ chcon -R -u system_u -t mysqld_db_t somedb_*
This changed all my custom databases to the proper SELinux context and the files could now be recognized by mysqld. I recommend running the chcon commad while the database server is not active, just as a precaution.
Hope that helps someone running into the same problem I had! Of course, you can turn off SELinux temporarily to test if this is fact this issue, but I didn't want turning off SELinux as a permanent solution.
I followed this steps:
Stop the mysql service.
Modify the my.cnf line datadir to my custom location.
Deleted all the files ib_data* , ib_logfile* in our new custom location
Change the permissions of the entire folder with your sentence:
chown mysql:mysql -R /custom_location/mysql/*
Start again the mysql service.
It works!!
Thanks
This error also occurs if the table is not in the database; so if you changed permissions of the directory and are still running into issues check your database and make sure the table is there.
So let's say you got an error like the OP:
Can't find file: './ci/users.frm'
ci is the database name
users is the table name
So in this case if you changed permissions and still had this issue you would verify that the users table is in the ci database.
#Brent Baisley It does work in XAMPP for Linux, but the location is different.
I did upgrade the Kernel today to fix the new Linux “Dirty Cow” Vulnerability (CVE-2016-5195). After the reboot I got the 'frm' permission error too.
So, if you get the following error:
Can't find file: 'yourtablename.frm' (errno: 13 - Permission denied) SQL query :...
You can do:
chown mysql:mysql /opt/lampp/var/mysql/yourDBname/*.frm
This will resolve your issue.
If you'd like to check, if your permission to any of the files has been modified before you execute the permission change, do:
ls -l /opt/lampp/var/mysql/yourDBname/*.frm
Hope that helps someone.
If you have failed RENAME TABLE statement, it could leave MySQL metadata in bad state. The solution is to recreate schema or to recreate table.
I'm having issues creating a table for my ruby on rails app. It's driving me crazy! The following is returned when I try to create the table:
ERROR 1 (HY000): Can't create/write to file '/usr/local/mysql/data/test_development/users.MYI' (Errcode: 2)
It's worth mentioning I'm a total newbie, btw.
This forum post seems to deal with the same problem:
Try the following:
mkdir /var/lib/mysql/tmp
chown mysql:mysql /var/lib/mysql/tmp
Add the following line into the [mysqld] section: tmpdir =
/var/lib/mysql/tmp
Restart the server
I hope you got this resolved as it has been a year. But I just ran into this same problem and resolved it successfully. This error is because mysql does not have permission to modify files in /usr/local/mysql/data. To bypass using this directory, this was to copy out one of the provided cnf in /usr/local/mysql/support-files into ~/.my.cnf. I used my-medium.cnf. Then I added the variable tmpdir=/tmp under the section [mysqld]. I picked /tmp because I have read and write permissions there. Remember to start and restart your mysql server.
I got this error in Windows, and I find out that I rename my DB name similarly. it solved my problem. Hope this helps.
No need to restart the server
The following can work, and is worth a try:
Using root privileges, search /tmp for a file named like #sql_d5_0.MYD
If found, just move or delete is. That way you release the lock that keeps mysql from accesing your data. It´s
sudo rm /tmp/\#sql*