I tried to upload a new version of an image file to my wiki and got this error:
Error 1034: Index for table 'oldimage' is corrupt; try to repair it (localhost)
I am running Mediawiki 1.35.6 on an Ubuntu Mate 22.04 LTS linux box (my private wiki). PHP 8.1.2, and Apache/2.4.52.
I don't know how to do this repair the error suggests.
UPDATE: I can sudo mysqlcheck -c mywiki oldimage and got the following result:
rwp#wiki:/var/lib/mysql/mywiki$ sudo mysqlcheck -c mywiki oldimage
mywiki.oldimage
Warning : InnoDB: Index 'oi_actor_timestamp' contains 15 entries, should be 12.
Warning : InnoDB: Index 'oi_name_timestamp' contains 15 entries, should be 12.
Warning : InnoDB: Index 'oi_name_archive_name' contains 15 entries, should be 1 2.
Warning : InnoDB: Index 'oi_sha1' contains 15 entries, should be 12.
error : Corrupt
I don't know what command to issue to repair oldimage.
UPDATE 2: I did the following from CLI.
sudo mysql
show databases;
use mywiki;
repair table mywiki.oldimage use_frm;
And result is:
MariaDB [mywiki]> repair table mywiki.oldimage use_frm;
+-------------------+--------+----------+---------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-------------------+--------+----------+---------------------------------------------------------+
| mywiki.oldimage | repair | note | The storage engine for the table doesn't support repair |
+-------------------+--------+----------+---------------------------------------------------------+
Ok, here is the solution I fumbled around onto (thanks to #erik258).
First, I stopped the web server that uses the database.
sudo service apache2 stop
Then,
sudo mysql
show databases;
use mywiki;
repair table mywiki.oldimage use_frm;
The repair did not work because the table, being InnoDB, did not support a repair. So, I altered the table to MyISAM as per here first. Did the repair, and then converted it back to InnoDB.
sudo mysql
show databases;
use mywiki;
alter table mywiki.oldimage engine=MyISAM;
repair table mywiki.oldimage use_frm;
It reported table repaired. Then I changed it back to InnoDB and all working fine now.
alter table mywiki.oldimage ENGINE=InnoDB;
quit;
Then restarted the web server that uses this database.
sudo service apache2 stop
Related
I've a very fresh installation of mariadb-server-10.5 (1:10.5.15-0+deb11u1) on a freshly installed debian 11.1 .
On the old machine with mysql-server (5.5.9999+default) and debian 9.6 I created a dump like this:
mysqldump -u root -pSOMEPW --all-databases > all_databases.dump
and I loaded this dump on the new server:
source /path/to/all_databases.dump
. The source took a while, did not result any error, however it beeped once at the end (no visible error or warning message).
Checking the mysql.user table it has only 3 entries for root, mysql and mariadb.sys , so I tried to create users (which were existing and used on the old machine) with this command:
create user 'testuser'#'localhost' identified by 'pw';
but it result this error:
ERROR 1396 (HY000): Operation CREATE USER failed for 'testuser'#'localhost'
.
With a short script checking all the tables of the mysql db the 'testuser' appears in 3 different tables, but as a User only in the db table twice like this:
| Host | Db | User | Select_priv
| localhost | somedb | testuser | Y
| localhost | somedbp2 | testuser | Y
.
I think that might cause create user to fail.
How could I fix this issue without losing the information in the db table?
Thanks.
In general you need to run mysql_upgrade whenever you switch to a more recent MySQL or MariaDB release, or after importing a backup taken from an older major version.
This is especially true for MariaDB 10.4 and later when importing from MySQL or from MariaDB 10.3 or earlier, as the internal privilege tables changed substantially with 10.4.
mysql.user table was replaced by mysql.global_priv in 10.4, allowing for more fine grained authentication control, e.g. supporting multiple authentication plugins for a single user.
So now mysql.user is just a VIEW presenting information from mysql.global_priv in a backwards compatible way. Simple information like user and host name can still be modified via that view directly as it is an updateable view, but this does not work for the more complex columns.
And commands like CREATE USER now directly operate on the mysql.global_priv table anyway, the errors you are getting are due to that table not being present in your imported dump.
The good news is: mysql_upgrade will take care of the necessary conversion, and after that CREATE USER should work again.
See also: https://mariadb.com/kb/en/mysql_upgrade/
See also: https://mariadb.com/kb/en/mysqlglobal_priv-table/
Old system: Ubuntu 20.04;
New system: Debian 11
What I have done so far:
Dumped MariaDB from the old system with
mysqldump -u root -p --all-databases | gzip > fullbackup.sql.gzip
Imported to the new system with
gunzip < fullbackup.sql.gz | mysql -u root -p
I installed PHPMyAdmin with apt-get install PHPMyAdmin
What are the current problems:
Not all my databases are imported. I can see missing databases after the import.
I have zero ideas how to see all the users in MARIADB
Phpmyadmin is saying, "Not enough privilege to view users".
I tried mysql> select * from mysql.user; REPAIR TABLE user nothing works
What I think got messed up:
The old system version of mariadb is 10.3.32 the new one is 10.5.12
Somehow the users table got messed up forever ERROR 1050 (42S01) at line 56937: Table 'user' already exists
There may be a misconfiguration in the Phpmyadmin I don't know how to fix.
Help me get my new server up and running, please! I am not an advanced user.
Since MySQL 10.4 mysql.users is not a table anymore, but a view into mysql.global_priv table.
It looks like you missed to run mariadb_upgrade. I didn't test if mariadb_upgrade in 10.5 also handles upgrade from 10.3, the usual way is to upgrade each version (10.3 - > 10.4 -> 10.5).
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.
Database query failed. Error received from database was #144: Table 'dbname.mantis_bug_file_table' is marked as crashed and last (automatic?) repair failed for the query: SELECT bug_id, COUNT(bug_id) AS attachments
FROM mantis_bug_file_table
GROUP BY bug_id.
How to avoid above issue. Many times I got this error after repair table. If I repair table after loading the page it's says "#2013 - Lost connection to MySQL server during query".
Thanks.
Stop MySQL process first.Go to your data folder and try running myisamchk -r <table_name>. If it is not work then try with myisamchk -r -v -f <table_name>.
Problem
I'm running MySQL 5.5.23 on Mac OS 10.8.2 and am unable to drop a particular database, but I can drop others.
When I attempt to drop the specific table I get this error:
#1548 - Cannot load from mysql.proc. The table is probably corrupted
Attempted Fixes
I have restarted the system
I have tried to restart MySQL via CLI
$ sudo /usr/local/mysql/support-files/mysql.server stop
but received this error ERROR! MySQL server PID file could not be found!
I have repaired the mysql.proc table.
REPAIR TABLE mysql.proc
REPAIR TABLE mysql.proc USE_FRM
I have repaired all mysql.* tables.
REPAIR TABLE mysql.*
When running mysqlcheck from the Command Line
mysqlcheck --repair --all-databases
mysqlcheck --repair specific-db
I received this error : mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (2) when trying to connect
Current Status
I still cannot drop the original specific database, but can drop others.
Update[1] 2013-01-05 11:15 am [New York]
Logs and Feedback (per #Thomas in comments)
To find all logs, I ran (cli):
$(ps auxww|sed -n '/sed -n/d;/mysqld /{s/.* \([^ ]*mysqld\) .*/\1/;p;}') --verbose --help|grep '^log'
I received this feedback:
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Note] Plugin 'FEDERATED' is disabled. /usr/local/mysql/bin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
130105 11:35:21 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
I'm looking into the mysql_upgrade.
Update[2] 2013-01-05 4:04 pm [New York]
I ran this :
sudo /usr/local/mysql/support-files/mysql.server stop
And received this error:
ERROR! MySQL server PID file could not be found!
Update[2.1] 2013-01-05 5:37 pm [New York]
I ran ps auxww | grep mysql and found the mysqld process and killed it (sudo kill [process id]). I was then able to restart mysql successfully. However, I'm still having no luck dropping that specific database mentioned above.
Resolved
After trying to manually repair the corruption and many of the suggestions and the other answer listed here, reinstalling mySQL was the only thing that solved my problem.
On a Mac (running 10.8.2) I also had to do some manual deletions for a clean install:
sudo rm /usr/local/mysql
sudo rm -rf /usr/local/mysql*
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm /etc/my.cnf
Articles consulted
MySQL duplicates with CONCAT error 1548 - Cannot load from mysql.proc. The table is probably corrupted
SQL error: BIGINT UNSIGNED value is out of range in (…), but it doesn't make sense
How to repair corrupted table
MySQL manager or server PID file could not be found
PHP/MySQL issue after security update 2010-005
mysql problems after Mac OS X software update
How to remove MySQL completely Mac OS X Leopard
I ran into an issue that queries on my databases (named: caloriecalculator) was taking too long and it won't drop at all. I followed these steps below and it fixed my issue:
See all MySQL processes: mysqladmin processlist -u root -p
Kill all processes relating to caloriecalculator as it was blocking my next queries to be executed.
mysqladmin -u root -p kill 4
Now run: drop database caloriecalculator;
I would try:
Backup/save any databases that have important data.
Remove mySQL
Reinstall mySQL
Restore any backed up databases.
I had this happen to me on a Linux server, and the cause was a corrupted database directory.
UPDATE: one thing to do is to go into MySQL database directory and perform a ls -la, to verify that the evil DB is the same as the others as regards permissions, ownership and so on. For example here the 'original' database cannot be dropped (it was created by a stupid tool ran as root):
drwx------ 2 mysql mysql 4096 Aug 27 2015 _db_graph
drwx------ 2 mysql mysql 4096 Jul 13 11:58 _db_xatex
drwxrw-rw- 2 root root 12288 May 18 14:27 _db_xatex_original
drwx------ 2 mysql mysql 12288 Jun 9 08:23 _db_xatex_contab
drwx------ 2 mysql mysql 12288 May 18 17:58 _db_xatex_copy
drwx------ 2 mysql mysql 4096 Nov 24 2016 _db_xatex_test
Running chown mysql:mysql _db_xatex_original; chmod 700 _db_xatex_original would fix the problem (but check inside the directory to verify there too permissions and ownerships are copacetic).
In the end, I employed the following ugly hack (after trying stopping, restarting and repairing whatever could be targeted by a REPAIR):
created a database "scapegoat"
stopped MySQL Server
copied the directory created by MySQL Server, /var/lib/mysql/scapegoat, to /tmp
restarted MySQL Server, dropped the database "scapegoat", stopped the server
Now I had a copy of a clean, empty DB dir that MySQL no longer knew anything about.
moved the "evildb" directory to /tmp (so that if thing went wrong I could put it back)
moved the "scapegoat" directory to /var/lib/mysql renaming it to "evildb"
started MySQL Server
not sure if I ran any more repairs at this point
and the "evildb" database became droppable!
My explanation is that when asked to drop a database, MySQL Server first performs some checks on the files in the database directory. If these checks fail, the drop also fails. These checks must be subtly different from the ones performed by REPAIR. Maybe in the affected directory there is something unexpected.
I think this was on a MySQL 5.1 or 5.2 on a SuSE 11.2 Linux distribution. Hope it helps.
UPDATE
On thinking back, I don't remember getting errors about "proc". So I'm less sure that the problem lies in the directory. It might be connected with the proc table, without being a table corruption. Have you tried visually inspecting the proc database table, in order to find something there that belongs to the evil DB?
USE mysql;
SELECT * FROM proc;
That, or any errors therefrom, could help in solving the problem. You might, who know, have some lines with the wrong db column. In a pinch, you could export the proc table and reload it after cleaning (either through SQL or via a disk file).
TEST
I have partial verification for the above update. By intentionally inserting rubbish into the proc table apropos a newly created database evil, I partially reproduced your symptoms (undroppable database, MySQL connection crashes on attempt). Error number is not 1548 though; but maybe it would be, if I inserted the right rubbish in that table... anyway, the useful bit is that by removing all references to the evil db, the latter became droppable again:
mysql> drop database evil;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> use mysql;
No connection. Trying to reconnect...
Connection id: 1
Current database: *** NONE ***
Database changed
mysql> DELETE FROM proc WHERE db = 'evil';
Query OK, 2 rows affected (0.00 sec)
mysql> drop database evil;
Query OK, 0 rows affected (0.00 sec)
I had the same problem and all I did was to delete the database directory from the mysql data directory.
If you using xampp In windows
you can also drop your database using phpmyadmin
go to home -> databases -> click on your [database name] -> drop
OR
you can also drop your database manually
go to xampp -> mysql -> data -> [database name]
delete your [database name] now.