Hello everyone, I am Yaoshan, today I will discuss theMySQL startup issues
Cause
The server was rebooted, and after the server started, I found that the MySQL program did not start, the error message is as follows:
2025-04-19T12:46:47.648559Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.2025-04-19T12:46:55.913703Z 0 [Warning] [MY-000081] [Server] option 'max_allowed_packet': unsigned value 107374182400 adjusted to 1073741824.2025-04-19T12:46:55.913790Z 0 [Warning] [MY-010915] [Server] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.2025-04-19T12:46:55.913893Z 0 [System] [MY-010116] [Server] /www/server/mysql/bin/mysqld (mysqld 8.0.24) starting as process 174712025-04-19T12:46:56.017284Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.Check ./mysqlbinlog, the log address for Baota’s mysqlbinlog: /www/server/mysql/bin
After looking at the binlog logs, I found that the last few SQL statements were fine, and then I remembered that I was exporting SQL during the reboot,it is highly likely that the server was suddenly rebooted while executing SQL, causing errors in the InnoDB database files
Force Enable Recovery Mode
Add the following content to the MySQL configuration file:
innodb_force_recovery = 1<span><span>1 (SRV_FORCE_IGNORE_CORRUPT)</span></span>- Allows the server to run even if corrupted pages are detected. Attempts to
<span><span>SELECT * FROM *</span></span>tbl_name<span><span>*</span></span>to skip corrupted index records and pages, which helps in dumping the table. <span><span>2 (SRV_FORCE_NO_BACKGROUND)</span></span>- Prevents the main thread and any purge threads from running. This recovery value prevents unexpected exits during purge operations.
<span><span>3 (SRV_FORCE_NO_TRX_UNDO)</span></span>- Does not run transaction rollbacks after crash recovery.
<span><span>4 (SRV_FORCE_NO_IBUF_MERGE)</span></span>- Prevents insert buffer merge operations. Do not do this if they would cause a crash. Does not calculate table statistics. This value may permanently damage data files. After using this value, be prepared to delete and recreate all secondary indexes. Set
<span><span>InnoDB</span></span>to read-only. <span><span>5 (SRV_FORCE_NO_UNDO_LOG_SCAN)</span></span>- Does not check the undo log when starting the database:
<span><span>InnoDB</span></span>even treats unfinished transactions as committed. This value may permanently damage data files. Set<span><span>InnoDB</span></span>to read-only. <span><span>6</span></span><span><span> (SRV_FORCE_NO_LOG_REDO)</span></span>- Does not perform redo log roll-forward related to recovery. This value may permanently damage data files. Leaves database pages in an outdated state, which may further damage B-trees and other database structures. Set
<span><span>InnoDB</span></span>to read-only.
Try starting from 1 and gradually increase; I successfully started at 2.
Backup Data
After a successful startup, we can use dump to export the database structure and data / Baota directly clicks to back up data.
After a successful backup, we can delete the original database. Since recovery mode is used and the InnoDB files are already corrupted, we can find the MySQL configuration file, locate the corresponding data files, and then use rm -rf to delete the original database files.
Ensure that all data is backed up!!!!
rm -rf /www/server/mysqlAfter deletion, reinstall the database, and then re-import the directly backed-up database, MySQL can start normally.
Ending
In life, one must learn to do one thing thoroughly, so as not to waste this life…Let’s encourage each other 💪.
