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
Related
Okay, I have a little problem.
My password is expired and my users table is corrupted. I can login via
mysql -u root -p
but on every action I perform I get the folowing error:
Column count of mysql.user is wrong. Expected 45, found 46. The table is probably corrupted.
I have read that you can fix the mysql.user table with the folowing command:
mysql_upgrade -u root -p
But when I do that I get the folowing error:
mysql_upgrade: Got error: 1862: Your password has expired. To log in you
must change it using a client that supports expired passwords. while
connecting to the MySQL server
Upgrade process encountered error and will not continue.
So, How do I fix this?
I have backups of all my tables so I won't be a problem if I have to reset all my databases.
(why the weird format? Stackoverflow thinks it's all code and wants me to put it in code blocks, otherwise I can not save it)
EDIT:
I know my password. That's not the problem at all.
My problem is that the password is expired and I am not able to do anything becuase my mysql.user is corrupted!
Try to disable the password expiration option: edit the my.cnf and put
[mysqld]
default_password_lifetime=0
and try to restart mysql server and try again login again.
the source is here https://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html
For repairing the database you run mysqlcheck --repair --databases db_name or mysqlcheck --repair --all-databases for repairing all databases
The source is here https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html
You could first try to repair the database then you could try to disable password lifetime.
Had the same issue when restoring an old backup from 2018, reinstalling MySQL as you said in a comment didn't solve the issue.
How I did:
Stop MySQL service
Run mysqld_safe --skip-grant-tables --skip-networking &
(if you get an error you may need to manually create and chown the directory /run/mysqld)
--skip-grant-tables will allow passwordless logins and will also disable any check on the password expiration
Now run mysql_upgrade --force and mysqlcheck --repair --all-databases
You can now kill the running mysqld_safe (ps aux | grep mysql to find the PID to kill) and then start the server normally with service mysql start.
In my case it didn't work and I still had the "Expected 45, found 46" error. In that case go ahead:
Stop the server again and restart it in safe mode as point 2 above
Now you should be able to dump the content, but we must exclude the mysql schema from being dumped.
Since mysqldump doesn't have a --exclude-database option, we need to get the list of databases to dump. To get the list of existing databases, except system schemas, run:
mysql -Nse "SELECT GROUP_CONCAT(SCHEMA_NAME SEPARATOR ' ') FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','information_schema','performance_schema','sys');"
Remove from the list any other db you don't need, and run the dump:
mysqldump --databases db1 db2 ... db50 > mysqldump.sql
Kill mysqld, move the datadir away and create an empty one (mv /var/lib/mysql /var/lib/mysql-old && mkdir /var/lib/mysql && chown mysql:mysql /var/lib/mysql)
service mysql start and a fresh datadir will be populated.
Run mysql_secure_installation to set a new root password
Import the dump file:
cat mysqldump.sql | mysql -u root -p
After that, the server is UP and running without issues.
Pretty simple question here. I just want a SQL database on my version of Kali linux so I can practice SQL.
I opened the command line and entered tried to start mysql and get an error.
> mysql -u root
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'
I also made sure it was already installed using apt-get.
What are the steps I need to take to be able to make a database with tables and data that I can query?
I don't know about Kali, but on Ubuntu it would be
$ sudo service mysql start
Once that command returns, the mysqld service has started, so you can use the mysql client to connect to it.
Of course, you also have to make sure you have the mysql-server package installed, not just mysql-client and mysql-common, and that you've initialized the database instance. Complete post-installation instructions can be found in the official documentation, but the short version is
Make sure the installer has created the mysql user account. This is the account that will "own" the server process once it starts.
Change to your data directory. (I used the installer's default of /var/lib/mysql; you can change this by editing my.cnf.)
As root, execute the server daemon with the --initialize switch. Check whereis to determine the correct path, then
$ sudo /path/to/mysqld --initialize --user=mysql
This command will twiddle itself for a while, then display an automatically-generated password and exit. Once the command returns, the database instance has been initialized and the system tables created. You can now start the database instance normally (using service start), then log in as the database user root (which is not the same as the system user root) using the password from above, then change your password, create a new database user, log in as that user, create a user database, and start creating tables.
Again, the official documentation is the place to look for this; if any of the instructions in the official documentation differ from my instructions, you should ignore me and follow the official documentation's instructions.
If sudo service mysql start doesn't work for you, please try running mysqld_safe and don't kill the process. Use another tab to check the status of mysql service. This should solve your mysqld.sock issue.
If it doesn't work out, then please edit your my.cnf file and add the following:
socket=/var/lib/mysql/mysql.sock
And the permissions,
sudo chmod -R 755 /var/lib/mysql/
Hopefully, this should do it.
On my version of kali (2022-rolling), even though it's installed as MySQL, it's run as mariadb. To start it is:
sudo /etc/init.d/mariadb start
Try this
sudo service mysql start
From my syslog:
mysql[1663]: ERROR 1577 (HY000) at line 1: Cannot proceed because system tables used by Event Scheduler were found damaged at server start
I tried this command to find damaged tables:
mysqlcheck -A --auto-repair --password
but all tables are OK. What's to do now?
EDIT
I also tried
sudo mysql_upgrade -u root -h localhost -p --verbose --force
but everything is OK. Still get the error.
I had the same problem, altough I didn't notice any errors or problems, I got those warnings. They seemed harmless.
I use MariaDB Ver 15.1 Distrib 10.3.22-MariaDB, for debian and your command fixed the issue perfectly:
mysql_upgrade -u root -h localhost -p --verbose --force
After lot of R&D finally i found solution...........
Basically its happen with mysql 5.7.10 version or earlier versions.
I was getting this error with event table(Mysql event scheduler).
solution-
click on start menu => search for Mysql installer => click on upgrade=> upgrade all mysql => it's really work.............!
I use Navicat for structure synchronisation and it's usually hassle-free, but with this problem I wasn't able to correct the base issue on shared hosting. Unticking 'Compare events' under 'Options' on the screen for selection of Source and Target allowed the structure synch to proceed unhindered.
I am new with MySql please help me out.
First to install MySql 5.5.7-rc i used this command->
sudo ./configure --prefix=/usr/local/mysql --with-plugin-partition --with-tcp-port=3308 --with-unix-socket-path=/tmp/mysql1.sock --with-debug
$sudo make
$sudo make install
Then when i am executing following command i am getting couple of errors.
$sudo ./mysql_install_db --datadir=/usr/local/mysql/data --basedir=/usr/local/mysql/ --user=mysql
ERROR:::
Installing MySQL system tables...
connect: Connection refused
Installation of system tables failed! Examine the logs in
/usr/local/mysql/data for more information.
You can try to start the mysqld daemon with:
shell> /usr/local/mysql//bin/mysqld --skip-grant &
and use the command line tool /usr/local/mysql//bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/mysql//bin/mysql -u root mysql
mysql> show tables
Try 'mysqld --help' if you have problems with paths. Using --log
gives you a log in /usr/local/mysql/data that may be helpful.
Please consult the MySQL manual section
'Problems running mysql_install_db', and the manual section that
describes problems on your OS. Another information source are the
MySQL email archives available at http://lists.mysql.com/.
Please check all of the above before mailing us! And remember, if
you do mail us, you MUST use the /usr/local/mysql//scripts/mysqlbug script!
Then i tried '/usr/local/mysql//bin/mysql -u root mysql' and i found
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
But /tmp/mysql.sock and /var/run/mysqld/mysqld.sock don't exist. I checked it...
Please give some suggestion to overcome this problem.
even mysqld service is not being started..
"connect: Connection refused" means the server's not listening where it's expected to; I understand that an answer a year late might be a bit too late but one should start with what the distribution provides or the official builds and not a self-made source build of an RC of a quite complex product in the first place.
Maybe those hitting this question will find the accepted answer to that one useful: bash:scripts/mysql_install_db: No such file or directory
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.