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;
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
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 following error when we are upgrading 5.0.45 to 5.1.42. Do I need to use mysql_upgrade
or mysqlcheck ?
Caused by: java.sql.SQLException: Column count of mysql.proc is wrong. Expected 20, found 16. Created with MySQL 50045, now running 50142. Please use mysql_upgrade to fix this error.
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3515)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3447)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1951)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2101)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2554)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1761)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2046)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1964)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1949)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:102)
at org.springframework.jdbc.core.JdbcTemplate$2.doInPreparedStatement(JdbcTemplate.java:792)
at org.springframework.jdbc.core.JdbcTemplate$2.doInPreparedStatement(JdbcTemplate.java:1)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:586)
If you're running on a XAMPP setup on ubuntu, navigate to:
/opt/lampp/bin
Then run
./mysql_upgrade
It should run a check through all your existing databases, at the end it may give you this error message:
Could not create the upgrade info file
'/opt/lampp/var/mysql/mysql_upgrade_info' in the MariaDB Servers
datadir, errno: 13
Not to worry, you can now import your db.sql script without errors.
In case you want to access your MariaDB shell, from the same location:
If you haven't set up a password:
./mysql -u root
If you've set up a password:
./mysql -u root -p
in mysql 5.1 4 additional columns were added for procedures. Seems that somehow your upgrade skipped that step and now you are getting error while importing data.
MySQL upgrade should help you solve that problem.
The exception indicates you should use mysql_upgrade.
The full error is:
Message: Mysqli statement execute
error : Can't create/write to file
'/var/www/zendApp/backup/mysql/1268733580_name.sql'
(Errcode: 13)
I have tried several things already with the /var/www/ZendApp/backup/mysql directory
$chmod 777 mysql
$chmod 1777 mysql
$chown root:root mysql
$chown mysql:mysql mysql
But nothing helps. What am I doing wrong here? Do I have to tell mysql somewhere that I can write to that directory?
With the help off Dominik # Super User, I discovered that Ubuntu is running apparmor and my server is running on Ubuntu. I quote from wikipedia:
AppArmor allows the system
administrator to associate with each
program a security profile that
restricts the capabilities of that
program
Sure enough, among those programs was mysqld. So not the user or his privileges are the problem, but the restrictions imposed on the process by apparmor. I then found the solution here
sudo touch /etc/apparmod.d/disable/usr.sbin.mysqld
sudo /etc/init.d/apparmor reload
This makes mysqld a free process which for me, on that server, is no problem. So, after days of searching, problem fixed!