MariaDB/MySQL - Fix error "Unknown/unsupported storage engine: InnoDB" by using recover mode

Although the InnoDB storage engine has mechanisms to preserve data, problems such as power failure or sudden restart can still cause errors in MySQL/MariaDB data. These errors can make the system unable to boot, unable to restore the normal data state. Some of the error messages we often encounter are listed below.

[Note] InnoDB: Starting shutdown...
[ERROR] InnoDB: Database was not shut down normally!
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[Note] Plugin 'FEEDBACK' is disabled.
[ERROR] InnoDB: Starting crash recovery from checkpoint LSN=1637690
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting

Note: Some crashes are caused by other causes but also return the error message "Unknown/unsupported storage engine: InnoDB". In that case, there will be more detailed information in the MySQL log to help you find the cause and handle it. As for the cases where the service can't tell why InnoDB is unsupported or unrecoverable, most of the time, data errors are caused. You can handle that case according to the instructions in this article.

To use this mode is very simple. You just need to specify the value innodb_force_recovery in the installation file of MySQL or MariaDB. Then restart the service. MySQL will restart and try to use recovery mode to recover the corrupted data.

[mysqld]
innodb_force_recovery = 1

MySQL has a total of 6 recovery modes in ascending severity. You often choose to get the most suitable mode for your system. Please try again with a higher level if the error is not resolved.

1 (SRV_FORCE_IGNORE_CORRUPT)
Lets the server run even if it detects a corrupt page. Tries to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.

2 (SRV_FORCE_NO_BACKGROUND)
Prevents the master thread and any purge threads from running. If an unexpected exit would occur during the purge operation, this recovery value prevents it.

3 (SRV_FORCE_NO_TRX_UNDO)
Does not run transaction rollbacks after crash recovery.

4 (SRV_FORCE_NO_IBUF_MERGE)
Prevents insert buffer merge operations. If they would cause a crash, does not do them. Does not calculate table statistics. This value can permanently corrupt data files. After using this value, be prepared to drop and recreate all secondary indexes. Sets InnoDB to read-only.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Does not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed. This value can permanently corrupt data files. Sets InnoDB to read-only.

6 (SRV_FORCE_NO_LOG_REDO)
Does not do the redo log roll-forward in connection with recovery. This value can permanently corrupt data files. Leaves database pages in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures. Sets InnoDB to read-only.

Finally, after troubleshooting, restore the "innodb_force_recovery" configuration to level 0 and then restart the database service to keep the system working properly.

Also note that this is only a workaround, it may also fail if the data is badly corrupted. Our advice remains that every database system should always have a mechanism to automatically back up data.

Read More

Ubuntu - MySQL Can't set password for root account, even though all command are successful

After a fresh install of MySQL or MariaDB on an Ubuntu server, you can run the "mysql" command line without being asked for your password, even if you have successfully changed the password. While you still cannot access root account from other software like Navicat, php ... the error encountered is "Access denied for user 'root'@'localhost' (using password: YES)"

What happened ?

you can run the "mysql" command without any password because by default, the root account is configured to login via the AUTH_SOCKET plugin. So MySQL Command-Line Client can always connect successfully without being asked for a password while other software can't connect even if the correct password is entered.

Security issue?

In a way, the mysql root account should only be accessed from the server, and a person who already has root privileges with Ubuntu can obviously optionally reset the mysql root account password. So this default configuration should not be a problem.

However, if you are a strict person or are familiar with other operating systems like Centos, you will be very uncomfortable with this configuration. If so, bring it back to the same as mysql on Centos by following the steps below.

Solving problems

Access the MySQL command-line. 

mysql

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 8

Server version: 8.0.21-0ubuntu20.0 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Switch to the 'mysql' database

use mysql;

Verify current status

select Host,User,authentication_string,plugin from mysql.user;

You can see: The MySQL ROOT account has no password configured and using the authentication plugin named auth_socket.

Now configure the ROOT account to use mysql_native_password plugin

ALTER USER root@localhost IDENTIFIED WITH mysql_native_password;

Set new password for root account

ALTER USER root@localhost IDENTIFIED BY 'newpassword';

Flush privileges

FLUSH PRIVILEGES;

exit;

Done

Problem solved !

Read More

MySQL: Fix Error 2013 - Lost connection to MySQL server during query

Case: You have successfully connected to a MySQL/MariaDB database. But when trying to import a large SQL file, an error occurred.

Error Code: 2013. Lost connection to MySQL server during query

Reason:

- Timeout due to slow connection or too much data (Not the server's fault)

- Memory allocated is not enough: the data fields are too large ....

Quick fix:

Increase memory for Mysql package.

Find config file

Eg:

Xampp Windows: C:\xampp\mysql\bin\my.ini

Linux: /etc/my.cnf

Edit file my.ini (my.cnf), find [mysqld] block, to change max_allowed_packet to a larger value (16, 32, or 128 M)

Eg:

[mysqld]
.....
max_allowed_packet=128M

Then restart MySQL

*Note: 

- If max_allowed_packet is not found, you can add it to your [mysqld] block yourself.

- Increasing memory capacity may affect the stability of MySQL server. So you can freely change it on your local computer, but if you are on the product server, please consider carefully. Another solution to importing large mysql files on the server is to use the command line.

Done ! Solved !

Read More

MySQL: Fix Error 1071 "Specified key was too long"

MySQL/MariaDB Error 1071 when try to import SQL File:

#1071 - Specified key was too long; max key length is 767 bytes

Sometime error is "max key length is 1000 bytes"

Reason:

From MySQL 5.6 and MariaDB 10.2.2 InnoDB File Format default is Barracudar. Barracudar is newer file type ,support many new format types (DYNAMIC and COMPRESSED). But in older version of MySQL or MariaDB default InnoDB File Format is still Antelope. So if you want to import a database using Barracudar(exported from newer version), you also need to change the current file format to Barracudar.

Solved:

To do that, run the following command in the Mysql command line (Root account is required):

SET GLOBAL innodb_file_format = Barracuda;
SET GLOBAL innodb_file_per_table = on;
SET GLOBAL innodb_default_row_format = dynamic;
SET GLOBAL innodb_large_prefix = 1;
SET GLOBAL innodb_file_format_max = Barracuda;
FLUSH PRIVILEGES;

Done ! The problem has been solved, you can try imoport SQL file again.

Tip: You can run Mysql command line from linux terminal or run Query in Navicat, PHPMyadmin ....

mysql -h localhost -u root -p

Refer: https://dev.mysql.com/doc/refman/5.6/en/innodb-file-format-enabling.html

Read More