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).
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;
I am using mysql-server 5.5.41-0+wheezy1 on Debian 3.2.54-2 x86_64
I have problems (not related to mysql) on some on my web app that uses mysql table so I am doing a re-install of the app
I started with aptitude remove packagename to remove my app and mysql-server, but it seems that it did not remove/delete the currently used mysql databases
When I reinstall mysql-server the previous database still used. I drop the previous user to create a new one using the command drop user olduser and also I drop the old database drop database olddb
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
+--------------------+
Now when I recreate the database with new name, it is a sucess, but if I recreate the same old user create user 'olduser'#'localhost' identified by 'somesecret'; it will always say ERROR 1396 (HY000): Operation CREATE USER failed for 'olduser'#'localhost' Creating a different user is a success, but this problem of recreating the same old user is bugging me. Is there something wrong or something I missed?
I have tried flush privileges
Well it's kinda hard to debug this without having any access to the database, this error is common with MySQL, but normally a FLUSH PRIVILEGES fix it. Anyway, if really the user is dropped you can bypass it that way :
CREATE USER 'anyuser'#'localhost' IDENTIFIED BY 'test123';
UPDATE mysql.user SET USER='olduser' WHERE USER='anyuser';
Note that to completly remove an user, you must delete all datas associated to it in these tables : columns_priv, db, procs_priv, tables_priv. Then finally execute flush privileges.
From the doc :
DROP USER does not automatically drop or invalidate databases or
objects within them that the old user created. This includes stored
programs or views for which the DEFINER attribute names the dropped
user. Attempts to access such objects may produce an error if they
execute in definer security context. (For information about security
context, see Section 18.5, “Access Control for Stored Programs and
Views”.)
I have installed WAMP server2.2 . Installation completed smoothly. but when i tried to access phpmyadmin. It gives error. I changed the password from /wamp/apps/phpmyadmin3.5.1/conf.inc.php.
But now I am facing another error as follows:
Error:-
SQL query: Documentation Edit
SELECT * FROM information_schema.CHARACTER_SETS
MySQL said: Documentation
#1146 - Table 'information_schema.character_sets' doesn't exist
I am new to this so please help me out....I stuck on the same error......
I can't proceed further without phpmyadmin..... Hope somebody help me as early as possible to resolve this error.
Thanks in advance.
Login via command line,
mysql -h myhost -u myusername -p
<ENTER PASSWORD>
run the command
show databases;
sample output:
+--------------------+
| Database |
+--------------------+
| mysql |
| phprojekt |
| test |
+--------------------+
if there is no database information_schema in your output , your mysql server is too old. (Version 4.x, most recent is 5.6 as of 2013). This can be the case, if you try to connect to an old database server in your company which didn't bother to upgrade (happens quite often for many reasons).
Also read this:
Generate INFORMATION_SCHEMA table for MySQL database
(you can't)
not sure if this is a question better suited for serverfault but I've been messing with amazon RDS lately and was having trouble getting 'file' privileges to my web host mysql user.
I'd assume that a simple:
grant file on *.* to 'webuser#'%';
would work but it does not and I can't seem to do it with my 'root' user as well. What gives? The reason we use load data is because it is super super fast for doing thousands of inserts at once.
anyone know how to remedy this or do I need to find a different way?
This page, http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/index.html?Concepts.DBInstance.html seems to suggest that I need to find a different way around this.
Help?
UPDATE
I'm not trying to import a database -- I just want to use the file load option to insert several hundred-thousand rows at a time.
after digging around this is what we have:
mysql> grant file on *.* to 'devuser'#'%';
ERROR 1045 (28000): Access denied for user 'root'#'%' (using password: YES)
mysql> select User, File_priv, Grant_priv, Super_priv from mysql.user;
+----------+-----------+------------+------------+
| User | File_priv | Grant_priv | Super_priv |
+----------+-----------+------------+------------+
| rdsadmin | Y | Y | Y |
| root | N | Y | N |
| devuser | N | N | N |
+----------+-----------+------------+------------+
You need to use LOAD DATA LOCAL INFILE as the file is not on the MySQL server, but is on the machine you are running the command from.
As per comment below you may also need to include the flag:
--local-infile=1
For whatever it's worth... You can add the LOCAL operand to the LOAD DATA INFILE instead of using mysqlimport to get around this problem.
LOAD DATA LOCAL INFILE ...
This will work without granting FILE permissions.
Also struggled with this issue, trying to upload .csv data into AWS RDS instance from my local machine using MySQL Workbench on Windows.
The addition I needed was adding OPT_LOCAL_INFILE=1 in: Connection > Advanced > Others. Note CAPS was required.
I found this answer by PeterMag in AWS Developer Forums.
For further info:
SHOW VARIABLES LIKE 'local_infile'; already returned ON
and the query was:
LOAD DATA LOCAL INFILE 'filepath/file.csv'
INTO TABLE `table_name`
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 ROWS;
Copying from the answer source referenced above:
Apparently this is a bug in MYSQL Workbench V8.X. In addition to the
configurations shown earlier in this thread, you also need to change
the MYSQL Connection in Workbench as follows:
Go to the Welcome page of MYSQL which displays all your connections
Select Manage Server Connections (the little spanner icon)
Select your connection
Select Advanced tab
In the Others box, add OPT_LOCAL_INFILE=1
Now I can use the LOAD DATA LOCAL INFILE query on MYSQL RDS. It seems
that the File_priv permission is not required.*
Pretty sure you can't do it yet, as you don't have the highest level MySQL privileges with RDS. We've only done a little testing, but the easiest way to import a database seems to be to pipe it from the source box, e.g.
mysqldump MYDB | mysql -h rds-amazon-blah.com --user=youruser --pass=thepass
Importing bulk data into Amazon MySQL RDS is possible two ways. You could choose anyone of below as per your convenience.
Using Import utility.
mysqlimport --local --compress -u <user-name> -p<password> -h <host-address> <database-name> --fields-terminated-by=',' TEST_TABLE.csv
--Make sure, here the utility will be inserting the data into TEST_TABLE only.
Sending a bulk insert SQL by piping into into mysql command.
mysql -u <user-name> -p<password> -h <host-address> <database-name> < TEST_TABLE_INSERT.SQL
--Here file TEST_TABLE_INSERT.SQL will have bulk import sql statement like below
--insert into TEST_TABLE values('1','test1','2017-09-08'),('2','test2','2017-09-08'),('3','test3','2017-09-08'),('3','test3','2017-09-08');
I ran into similar issues. I was in fact trying to import a database but the conditions should be the same - I needed to use load data due to the size of some tables, a spotty connection, and the desire for a modest resume functionality.
I agree with chris finne that not specifying the local option can lead to that error. After many fits and starts I found that the mk-parallel-restore tool from Maatkit provided what I needed with some excellent extra features. It might be a great match for your use case.