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.
Related
I can't login my MySQL server. I got many solutions via the internet but not working any single solution.
The first thing is to ensure that MySQL server is up and running. This procedure is different for different distros, but you can try
$ sudo /etc/init.d/mysql start
to start
MySQL is not starting.
As suggested, your first step is to bang out the typical commands: service mysql status and journalctl -xe to see what errors are reported. The usual suspects are permissions on the mysql data folder typically located in/var/lib/mysql (permissions should be mysql:mysql) and also errors in my.cnf (/etc/mysql/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf for recent mariadb installs)
If your MySQL was previously running and now wont start, you might be dealing with table corruption. Get mysqlcheck running on it if this is the case. If you are going to attempt a database startup with innodb_force_recovery flag, make sure you have your data backed up prior to launching the database.
Let us know the output of these commands so we can further assist.
After upgrading MySQL to 5.7.8-rc
and loging to server I got error:
Table 'performance_schema.session_variables' doesn't exist
I can't find any solution for this. Can you help ?
I was able to log on to the mysql server after running the command #robregonm suggested:
mysql_upgrade -u root -p --force
A MySQL server restart is required.
The mysql_upgrade worked for me as well:
# mysql_upgrade -u root -p --force
# systemctl restart mysqld
Regards,
MSz.
mysql -u app -p
mysql> set ##global.show_compatibility_56=ON;
as per http://bugs.mysql.com/bug.php?id=78159 worked for me.
Since none of the answers above actually explain what happened, I decided to chime in and bring some more details to this issue.
Yes, the solution is to run the MySQL Upgrade command, as follows: mysql_upgrade -u root -p --force, but what happened?
The root cause for this issue is the corruption of performance_schema, which can be caused by:
Organic corruption (volumes going kaboom, engine bug, kernel driver issue etc)
Corruption during mysql Patch (it is not unheard to have this happen during a mysql patch, specially for major version upgrades)
A simple "drop database performance_schema" will obviously cause this issue, and it will present the same symptoms as if it was corrupted
This issue might have been present on your database even before the patch, but what happened on MySQL 5.7.8 specifically is that the flag show_compatibility_56 changed its default value from being turned ON by default, to OFF. This flag controls how the engine behaves on queries for setting and reading variables (session and global) on various MySQL Versions.
Because MySQL 5.7+ started to read and store these variables on performance_schema instead of on information_schema, this flag was introduced as ON for the first releases to reduce the blast radius of this change and to let users know about the change and get used to it.
OK, but why does the connection fail? Because depending on the driver you are using (and its configuration), it may end up running commands for every new connection initiated to the database (like show variables, for instance). Because one of these commands can try to access a corrupted performance_schema, the whole connection aborts before being fully initiated.
So, in summary, you may (it's impossible to tell now) have had performance_schema either missing or corrupted before patching. The patch to 5.7.8 then forced the engine to read your variables out of performance_schema (instead of information_schema, where it was reading it from because of the flag being turned ON). Since performance_schema was corrupted, the connections are failing.
Running MySQL upgrade is the best approach, despite the downtime. Turning the flag on is one option, but it comes with its own set of implications as it was pointed out on this thread already.
Both should work, but weight the consequences and know your choices :)
Follow these steps without -p :
mysql_upgrade -u root
systemctl restart mysqld
I had the same problem and it works!
As sixty4bit question, if your mysql root user looks to be misconfigured, try to install the configurator extension from mysql official source:
https://dev.mysql.com/downloads/repo/apt/
It will help you to set up a new root user password.
Make sure to update your repository (debian/ubuntu) :
apt-get update
If, while using the mysql_upgrade -u root -p --force command You get this error:
Could not create the upgrade info file '/var/lib/mysql/mysql_upgrade_info' in the MySQL Servers datadir, errno: 13
just add the sudo before the command. That worked for me, and I solved my problem. So, it's: sudo mysql_upgrade -u root -p --force :)
For my system the problem ended up being that I still had Mysql 5.6 installed and so the mysql_upgrade.exe from that installation was being called instead of the one for 5.7. Navigate to C:\Program Files\MySQL\MySQL Server 5.7\bin and run .\mysql_upgrade.exe -u root
sometimes mysql_upgrade -u root -p --force is not realy enough,
please refer to this question : Table 'performance_schema.session_variables' doesn't exist
according to it:
open cmd
cd [installation_path]\eds-binaries\dbserver\mysql5711x86x160420141510\bin
mysql_upgrade -u root -p --force
Unfortunately, I have removed super user privileges from postgres user in PostgreSQL. And currently I have not any super user in PostgreSQL. And i want to make superuser. So how can i make it ? Every time I am trying to make postgres to super user. I am facing this problem.
Error : must be superuser to alter superusers.
(assuming you have root access on Ubuntu machine)
To enter psql as super user you need to:
sudo -u postgres psql
as suggested in this SO post here
If there is no user called postgres you need to create it on system first, with:
sudo adduser newuser
Else, if you have problems with password not accepted or not created at all you can follow (Ubuntu 14.04 related) instructions here or for more on user accounts look here
For me helps:
sudo -u gleb psql postgres
where gleb is my mac system user
Adding to Craig Ringer's answer, here is the procedure for MacOS and Brew if you accidentally downgrade your only PostgreSQL user:
brew services stop postgresql
Wait a few seconds and/or check Activity Monitor to make sure "postgres" is no longer running.
/usr/local/Cellar/postgresql/10.4/bin/postgres --single -D /usr/local/var/postgres
backend> ALTER USER "yourname" with superuser; or whatever privilege you need to fix
CTRL-D
brew services start postgresql
You're going to have to stop the database system and start a stand-alone back-end, which always unconditionally runs as a superuser.
You can use this backend to ALTER the user you wish to give superuser rights to. Then shut the standalone backend down and start the database normally.
It is important that you completely stop the database server before entering single user mode. PostgreSQL single user mode will refuse to start if there's a postmaster, but to be sure you should make sure there are no PostgreSQL processes running on your system. Under (almost) no circumstances should you ever delete postmaster.pid - that's pretty much guaranteed to result in database corruption if there's still any PostgreSQL process accessing that data directory.
Exactly how to start a standalone back-end depends a bit on your OS/distro and how you installed PostgreSQL. You haven't included this info, so I can only really point you at the manual for the postgres back-end executable.
Make a backup first.
In the single-user mode, the session user will be set to the user with ID 1, and implicit superuser powers are granted to this user. This user does not actually have to exist, so the single-user mode can be used to manually recover from certain kinds of accidental damage to the system catalogs.
See the section Options for Single User mode and, toward the bottom, Usage. You'll want to run the postgres backend with --single, as the unix user that owns the database files, with the path to the datadir. On a typical Linux PostgreSQL install this might be something like:
sudo systemctl stop postgresql-9.3.service
sudo -u postgres /usr/pgsql-9.3/bin/postgres --single -D /var/lib/pgsql/9.3/data
Your datadir and postgres executable location are quite possibly different. The above is for a Fedora system running with PGDG PostgreSQL packages from http://yum.postgresql.org/ .
Assuming that your system user is 'ec2-user'
So try this to enter as superuser
psql -U ec2-user postgres
This will enter you as ec2-user as superuser using postgres db
Now, change postgres user roles to superuser
ALTER USER postgres WITH SUPERUSER;
Quit from above console and now you can open psql using postgres user as superuser
psql -U postgres
Note: I tested this on PostgreSQL 12.5
SELECT usename AS role_name,
CASE
WHEN usesuper AND usecreatedb THEN
CAST('superuser, create database' AS pg_catalog.text)
WHEN usesuper THEN
CAST('superuser' AS pg_catalog.text)
WHEN usecreatedb THEN
CAST('create database' AS pg_catalog.text)
ELSE
CAST('' AS pg_catalog.text)
END role_attributes
FROM pg_catalog.pg_user
ORDER BY role_name desc;
log with root_user then give superuser to postgres
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