I really need help with a mariadb crash. Earlier today mariadb stopped working. i tried various things to get back with mariadb until i moved ib_logfile0 ib_buffer_pool to another location and so i was able to start mariadb but all database users seem to have lost permission.
I thought at the time that ibdata1 might be corrupted.
I changed mysql root password because I didn't have mariadb root access but all database users lost access to the database.
i tried to make a backup of all databases "mysqldump -u root -p -A > mydb.sql" but i get the error
"Table 'crmidentiq.tblactivity_log' doesn't exist in engine" when using LOCK TABLES
I'm out of ideas on how to solve this problem and repair users' permission.
Can someone help me?
Check and fix tables mysql.global_priv (for new mariadb versions) or mysql.users (for old versions) , these 2 tables contain your credentials
Related
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).
After I upgraded MySQL 5.7 to MySQL 8.0, I started MySQL again and I got an error:The user specified as a definer ('mysql.infoschema'#'localhost') does not exist' when trying to dump tablespaces.
I don't understand why this problem occurs. And I want to know how to solve it
I had the same error when I accidentally downgraded my MySQL version from 8 to 5.7. At the first start the older version broke something so that version 8 was showing the error above.
In my case I had to enter the docker container where MySQL was running first
docker exec -it mysql bash
Then I basically followed the steps here
mysql -u root -p
mysql> SET GLOBAL innodb_fast_shutdown = 1;
mysql_upgrade -u root -p
This took some minutes but then everything was working again.
It may occur after some time after you set up your new system.
As a suggested solution, just try on Windows
1) open cmd.exe as Administrator
2) run mysql_upgrade.exe -uyour_user_name -pyour_password
mysql_upgrade.exe can be located at
C:\Program Files\MySQL\MySQL Server 8.0\bin
Then run the following to see if the infoschema user has appeared.
select user, host from mysql.user;
In my case, such error was caused by that I had changed the host of the dba user from % to localhost to strengthen the security.
I used "abcdba" with DDL right to create db schema, and used "abc" with CURD right for the Web service to use the DB. After the change, the read operations were OK but the write operations failed with the error message in the OP.
Flush privilege or restarting the server did not solve the problem. Then I changed to host of the dba user back to %. Then things have become normal again.
Apparently mysql does not like the changes of host of the dba user, and existing databases created by that dba user will have problem if the host of the dba user is changed.
Essentially, changing the host of the dba user is actually removing user abcdba#% and creating a new user abcdba#localhost. Here had come the error message, since abcdba#% and abcdba#localhost are 2 differently fully qualified usernames.
When trying (InnoDB):
DROP DATABASE mydatabase;
I almost inmediately get:
ERROR 2013 (HY000): Lost connection to MySQL server during query
I checked the timeouts and they are far enough from being short (600 seconds) so I stopped MySQL, removed mydatabase folder and started MySQL again. Then I re-created my DB and loaded it from a dump:
mysql -u <user> -p mydatabase < Dump.sql
But the process failed once and again due to some already existing table (though I'm sure it is not duplicated in the dump file), so at this point I don't really know what to do and whether I'm facing some InnoDB corruption issue (logs do not show anything related).
Any thoughts?
So finally, as (credits go for him) #t.niese's link points out, I quit trying to drop the (corrupted) DB and ended up recovering the dump into another DB, just changing its name. Fortunately I didn't need to have the same name, so I skipped the long process pointed out at that link. But alas it seems the corrupted database will stay in the ibdata1 file.
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 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.