When i perform any procedure creation or update operation to mysql DB, i am getting the below error
Table './mysql/proc' is marked as crashed and should be repaired
Tried to run mysql isam recover using below command -
myisamchk -q -r /var/lib/mysql/mysql/proc
But the issue still persists.
Thanks in Advance.
Try these:
mysqlcheck --auto-repair -A -u username -ppassword
Inside MySQL terminal
repair table mysql.proc;
Reference: https://dev.mysql.com/doc/refman/5.1/en/repair-table.html
Modify the my.cnf
[mysqld]
character-sets-dir=/usr/share/mysql/charsets
Reference: http://dev.mysql.com/doc/refman/5.0/en/repair-table.html
The above answer also applicable to other business related tables -
example -
Table './dev/bank_accounts' is marked as crashed and should be repaired
Can be resolved by following command in mysql prompt.
repair table 'dev.bank_accounts';
Internally, mysql trys to recover the data from MyISAM storage engine of mysql.
Caution - Please take a back up of the table before doing a repair, As the repair might cause a data loss.
Go to structure of the table and scroll down and click on optimize option. It will repair your table and will fix this issue.
Related
I'm trying to repair some corrupted tables throught mysqlcheck command, but it returns the following "errno 2" error:
# mysqlcheck -u user -p --repair database
Enter password:
database.users OK
database.notes
Error : Can't find file: 'notes' (errno: 2)
status : Operation failed
...
I don't even need the information that was stored in that tables I can't repair, if only I could repair the tables without information it would be fine.
Do you happen to know if is there any way to repair the corrupted tables?
Worked for me:
Stop MySQL to free memory and get MySQL run memory parameter to put in the repair command:
myisamchk --sort_buffer_size=20M --key_buffer_size=5G --read_buffer_size=8M --write_buffer_size=8M -t DIR_WITH_SPACE -r PATH_TO_TABLE.MYI
DIR_WITH_SPACE has to store tmp file as big as MYI table file. If you don't specify it, it'll use the system tmp, beware of reaching full.
PATH_TO_TABLE.MYI is the MYI file of your table, in the MySQL data dir or elsewhere read/write place.
Then the mysqlcheck should be useless and table usable.
Currently I'm using the newest version of ISPConfig 3. Today I wanted to add a db and user. It didn't work. Then I tried it on PHPmyadmin and it didn't work.
When I tried to add a user in PHPMyadmin Users Panel I received the following error message:
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 '* TO 'test'#'localhost'' at line 1
The output from /var/log/mysql/error.log:
[ERROR] Column count of mysql.user is wrong. Expected 42, found 44.
The table is probably corrupted
Mysql Version: 5.5.55-0+deb8u1
PHPMyadmin Version: 4:4.2.12-2+deb8u2
Debian Linux 8
I had the same problem when I updated the mysql server from 5.5 to 5.7 in Debian 8 (jessie). In rare cases, it probably happens if you update directly bypassing the sequences of versions. (Many people do this, but such upgrades are not officially supported).
In my case, it worked fine when I executed the command below:
mysql_upgrade --force -uroot -p
I hope this will help you
Migrating from mariadb 10 to mysql 5.6 saw similar issues. The error message I received, was slightly different than the others listed on this page... which, of course, means it required a different solution. Upon attempting to modify a user record I received the following error:
Column count of mysql.user is wrong. Expected 43, found 46. The table is probably corrupted
Some of the advice above helped frame the problem. After taking a look at a similar server (to the mysql 5.6 one), I compared the fields in the both the "corrupted" user table (from the mariadb 10 mysql.users table) & the "functional" user table in the other mysql 5.6 mysql.users table.
I removed the three problematic fields using the mysql cli & the following commands:
mysql -u root -p
use mysql;
alter table mysql.user drop column default_role;
alter table mysql.user drop column max_statement_time;
alter table mysql.user drop column password_expired;
quit
Problem resolved!
This worked for me:
mysql_upgrade -uroot -p
and add your password root
In my case, and following the recommendation of the error message, I ran:
root#mysql-190877524-gm3j4:/# mysql_upgrade -uroot -p***
Checking if update is needed.
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv OK
mysql.db OK
mysql.engine_cost OK
mysql.event OK
mysql.func OK
mysql.general_log OK
mysql.user OK
Upgrading the sys schema.
Checking databases.
[...]
Upgrade process completed successfully.
Checking if update is needed.
That solved everything.
Had the same trouble today on debian (jessie) and another ami linux box.
Removing the password expired column from mysql user table fixed the issue for me.
mysql> alter table mysql.user drop column password_expired;
I moved from mariadb to mysql because i was unable to change the myriadb data directory on centos 7 x 64.
on mysql When i tried adding new user other than root. i got
column count of mysql.user is wrong expected 45 found 48
i tried
mysql_upgrade -uroot -p
and
mysql_upgrade --force -uroot -p
but still got the same error.
so i went ahead and added new user manually in mysql.user table by copying all details from other rows having root username.
restart service mysqld
and done.
Today I ran into the same problem after I did a dist-upgrade of a Debian Jessie 8 staging box. After some Investigation I found out, that the mysql table structure differs from what mysql-5.5.55 expects to find. I just compared the corrupted mysql database with a freshly installed one and created a little patch file, that should correct the error. Not sure if this works under other conditions, too. So, be careful using this patch and backup /var/lib/mysql and /etc/mysql before doing something nasty ;) I'll take no responsibility for any kind of damages possibly arising by this patch. Use it at your very own risk.
First of all MAKE BACKUPS!! and even more BACKUPS!! e.g. you could give mysqlsafebackup a try (Look at https://github.com/VerboteneZone/MySQLSafeBackup), an encrypting and compressing MySQL backup solution, written by me.
Download the following patch to your box:
# wget https://download.rent-an.expert/mysql-patch-5.5.55.sql.gz
Make sure, that no instance is currently accessing your MySQL server (stop services like apache2, postfix or whatever normally accesses the MySQL server). If you made yourself sure, that you are alone in the dark, apply the patch and force a mysql upgrade with the following commands:
# zcat mysql-patch-5.5.55.sql.gz | mysql -uroot -p mysql
# mysql_upgrade --force -uroot -p
If anything worked without any error, restart your MySQL service:
# service mysql stop
# service mysql start
After that, try to create a testuser to see, if the patch has been applied correctly:
# mysql -uroot -p
CREATE USER 'Testuser123'#'localhost' IDENTIFIED BY 'Pass0worZ';
You should get a message like:
Query OK, 0 rows affected (0.00 sec)
Now, you can safely delete your testuser again, with:
DROP USER 'Testuser123'#'localhost';
Anyway, if something went wrong, restore your backup and try again ;)
Hope that helps.
In my case, with Debian 8 and MySQL 5.5, mysql_upgrade --force -uroot -p wont fix the issue.
I needed upgrading to MySQL 5.6 first and then run the command above.
http://www.debiantutorials.com/install-mysql-server-5-6-debian-7-8/
When migrating from mysql 5.5 to 5.7, (by using a full mysqldump and then the source command) I had the error only when I tried to edit or add a user
ERROR 1805 (HY000): Column count of mysql.user is wrong. Expected 45,
found 42. The table is probably corrupted
Similar to some others here I did
sudo mysql_upgrade -u root -p #sudo so it can write a log sudo
service mysql restart
And that fixed the issue, I could add and edit users again. I would have added this small difference as a comment to one of the similar answers, but I don't have the reputation yet
I've ran into the same issue today..
The solution for me was to manually add the missing columns to the user table.
Beware - Use at your own risk
The newly added columns with mysql.5.5.55 are:
plugin, authentication_string, Create_tablespace_priv
They need to be added in a specific oder:
use mysql;
alter Table user ADD Create_tablespace_priv enum('N','Y') DEFAULT 'N' NOT NULL AFTER Trigger_priv;
alter Table user ADD plugin char(64) DEFAULT '';
alter Table user ADD authentication_string text DEFAULT NULL;
After this, I was able to again, modify the user table.
After and upgrade I had "Column count of mysql.user is wrong. Expected 45, found 46. The table is probably corrupted" I was having trouble logging in so i fired up the db:
mysqld --console --skip-grant-tables
logged in and there was an extra column compared to my default table "Is_role" so i removed it:
ALTER TABLE `user` DROP COLUMN `is_role`;
restarted mysqld and we are all good.
I finally solved my problem this way:
1) Start mysql: mysqld –-console –-skip-grant-tables –-skip-external-locking (keep the terminal open)
2) Execute: mysqlcheck –-repair mysql user
Source: https://forums.mysql.com/read.php?10,652134,652135#msg-652135
Quiet the same error message : Column count of mysql.user is wrong. Expected 42, found 43. The table is probably corrupted.
This is not the solution but a circumvention ... I backuped all my databases from mysql 5.5.55-0+deb8u1 and restored them to mysql 5.7.18-0ubuntu0.16.04.1 until this bug is not resolved.
Hard job to update all connections but usefull.
If you are trying to add a new user or even change the permission of any existing users and getting the error, firstly I would suggest to grant full permission to the root users, and then adding new users.
sudo mysql
GRANT ALL PRIVILEGES ON * . * TO 'ccuser'#'localhost';
And then,
CREATE USER 'new_user'#'localhost' IDENTIFIED BY 'new_password';
In case you do not want to Upgrade the MySQL using mysql_upgrade --force -uroot -p or mysql -u root -p as it may interfere with the database,
as if the database may be important i.e. it may either be running on a live server, or too big to take a backup and restore it, and you may not want to take that risk of getting it deleted from a live server, then you may simply rectify the error after understanding it line by line.
It may be different in your case but, In my case
I had to give privileges to a remote host as: GRANT ALL PRIVILEGES ON some_db_name_abc.* to 'root'#'xxx.xxx.x.xxx' IDENTIFIED BY 'test123';
and the error was #1558 - Column count of mysql.user is wrong. Expected 42, found 39. Created with MySQL 50173, now running 50562. Please use mysql_upgrade to fix this error.
So Basically 3 columns named Create_tablespace_priv, plugin and authentication_string were absent from the table named user of database mysql. The column names, their position in the table and their datatypes, I came to know from another testing server, which I added as follows:
ALTER TABLE mysql.user
ADD Create_tablespace_priv ENUM('N','Y') NOT NULL
AFTER Trigger_priv;
ALTER TABLE mysql.user
ADD plugin CHAR(64) NOT NULL
AFTER max_user_connections;
ALTER TABLE mysql.user
ADD authentication_string TEXT NOT NULL
AFTER plugin;
And the query to give privileges to a remote host ran successfully after it
In case you made mistake, then you can delete the added column from the table as:
ALTER TABLE mysql.user DROP COLUMN plugin;
I have my VPS installed cPanel. Today it suddenly not work, all of Wordpress websites on VPS show the error:
This webpage has a redirect loop
ERR_TOO_MANY_REDIRECTS
and auto redirect to wp-admin/install.php.
I log in to phpmyadmin then see some tables have collation "in use" (not "utf8_general_ci" such as normally). Can't be loaded because of error:
#1286 - Unknown storage engine 'InnoDB'".
So how to fix this error?
Thanks for help me!
I faced the same issue, this issue raised up because your innoDB got corrupted and all your databases using innoDB tables are showing in-use.
To fix this issue you need to follow the below steps
To get 100% clean tablespace you need to start MySQL with innodb_force_recovery=4, take mysqldump and restore it on a fresh instance of InnoDB (by fresh I mean you have to delete ibdata1, and all databases directories).
UPDATE:
At this point MySQL is started with innodb_force_recovery=x (x != 0)
Take dump of all databases:
mysqldump --skip-lock-tables -A > alldb.sql
Check where MySQL keeps its files(in my case it's /var/lib/mysql/):
mysql -NBe "SELECT ##datadir"
/var/lib/mysql/
Stop MySQL
mysqladmin shut
Move old MySQL files to safe place
mv /var/lib/mysql /var/lib/mysql.old
Create new system database
mkdir /var/lib/mysql
mysql_install_db
Start MySQL
/etc/init.d/mysql start
Restore the dump
mysql < alldb.sql
Restore may take long time if the database is big.
Another trick may work in that case. Run ALTER TABLE ... ENGINE INNODB on each InnoDB table. It will rebuild all InnoDB indexes and thus the errors will go away.
+++++++++++++++++++++++++++++++++++++++++++++++++
Another solution to this is restoring the databases from backup.
For this first you need to remove ibdata1 file
cd /var/lib/mysql
rm -f ibdata1
Then restore all the databases one by one using below command
mysql -u username -p databasename < backupfile.sql
++++++++++++++++++++++++++++++++++++++++++++++++++
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.