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
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.
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;
A. First things first:
Mr. Google hasn't helped me to found any reply to my question
above
Yes, I have read a solution to the opposite question here
How to upgrade MySQL to MariaDB in XAMPP in 5 minutes on Windows
(and it hasn't helped me: MySQL simply doesn't start)
I don't expect replies like 'MariaDB is better, - stop your silly
exercises'.
B. I am working with MySQL Workbench and because of that don't want to face any incompatibilities either now or in future.
C. Can someone share their experience (if any) in solving this problem?
Running XAMPP with MySQL
Here are exact step by step instructions for truly integrating MySQL into XAMPP on Windows. This has been successfully tested with Windows 10 and XAMPP 7.3.11 for both MySQL 8.0.18 and 5.7.28.
Stop MySQL (which actually is MariaDB) in the XAMPP Control Panel.
Download the MySQL community server as zip archive (Windows 64 bit version)
Rename C:\xampp\mysql to C:\xampp\mariadb
Extract the downloaded zip archive to C:\xampp\mysql. Make sure you extract the folder level which has the subfolders bin, include, lib etc.
Copy C:\xampp\mariadb\bin\my.ini to C:\xampp\mysql\bin
Open C:\xampp\mysql\bin\my.ini in an editor and comment out the line starting with key_buffer= in the [mysqld] section.
Open a command prompt and run the following commands:
For MySQL 8.0.18:
cd C:\xampp\mysql
bin\mysqld --initialize-insecure
start /b bin\mysqld
bin\mysql -u root
CREATE USER pma#localhost;
SOURCE C:/xampp/phpMyAdmin/sql/create_tables.sql;
GRANT SELECT, INSERT, DELETE, UPDATE, ALTER ON phpmyadmin.* TO pma#localhost;
ALTER USER root#localhost IDENTIFIED WITH mysql_native_password BY '';
ALTER USER pma#localhost IDENTIFIED WITH mysql_native_password BY '';
\q
bin\mysqladmin -u root shutdown
For MySQL 5.7.28:
cd C:\xampp\mysql
bin\mysqld --initialize-insecure --log_syslog=0
start /b bin\mysqld --log_syslog=0
bin\mysql -u root
CREATE USER pma#localhost;
SOURCE C:/xampp/phpMyAdmin/sql/create_tables.sql;
GRANT SELECT, INSERT, DELETE, UPDATE, ALTER ON phpmyadmin.* TO pma#localhost;
\q
bin\mysqladmin -u root shutdown
Start Apache and MySQL in the XAMPP Control Panel.
Go to http://localhost/phpmyadmin and verify that your database server is now reported as MySQL Community Server.
You can use the following way.
Stop MariaDB in Xampp which show as mysql running...
Download the installer for windows mysql Installer
Follow the instruction.
Now start Apache2 and clear cookie in your browser. Now you can see phpmyadmin and workbench showing Server type: MySQL
If you want to stick to MariaDB then you can use sqlyog also.
Hope it answer your question
You have to do little adjustment with xampp in order to use MySQL instead of MariaDB . I just did following and its worked , i think it may helpful to others also.
Download and install mysql installer.
2.stop xampp and rename the mysql folder inside the xampp directory(may be its not necessary! )
3.just start Apache only from xampp control panel . No need to start mysql.
4.Last step . Make sure your running MySQL in your system . That's it ..
Check php admin panel there you can see Server type: MySQL instead of MariaDB ...
Thanks..
I just upgraded XAMPP because of PHP 7. I am also using mysql workbench. I want to be as close to production as I can, but my webhoster supports only mysql. These where my reasons to switch back from mariadb to mysql
I followed these steps: (also max 5min)
https://gist.github.com/odan/c799417460470c3776ffa8adce57eece
I tried everything, changing the port no. and all but it still did not start I had to end the mysql process using the activity monitor and now the tables wont respond. When I click the name it shows an error message: #1146 table 'table_name' doesn't exist!
My past projects will be wasted if they don't respond and I had forgotten to export the databases.
you can run this command to repair any database you have:
mysqlcheck -u mysql_username -p database_name
but if you see this error after running this:
Error: Table 'database_name.table_name' doesn't exist
you should drop your damaged table, all details can you find through this link