It perfectly solves the problem of disabling mysql immediately after it is started (the ibdata1 file is damaged) and mysqlibdata1

It perfectly solves the problem of disabling mysql immediately after it is started (the ibdata1 file is damaged) and mysqlibdata1

Mysql on a server in the data center has been running for a while, and suddenly a strange phenomenon occurs: it cannot be recovered after restart! The exact result is that mysql is disabled immediately after it is started.

View the mysql error log as follows:

160920 22:41:41 mysqld_safe Starting mysqld daemon with databases from/home/MysqlData/
22:41:41 0 [Note]/Data/app/mysql5.6.25/bin/mysqld (mysqld 5.6.25-log) starting as process 32372...
22:41:42 32372 [Note] Plugin 'federated 'is disabled.
22:41:42 32372 [Warning] option 'innodb-write-io-Threads': unsigned value 1000 adjusted to 64
22:41:42 32372 [Warning] option 'innodb-read-io-Threads': unsigned value 1000 adjusted to 64
22:41:42 32372 [Note] InnoDB: Using atomics to ref count buffer pool pages
22:41:42 32372 [Note] InnoDB: The InnoDB memory heap is disabled
22:41:42 32372 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
22:41:42 32372 [Note] InnoDB: Memory barrier is not used
22:41:42 32372 [Note] InnoDB: Compressed tables use zlib 1.2.3
22:41:42 32372 [Note] InnoDB: Using CPU crc32 instructions
22:41:42 32372 [Note] InnoDB: Initializing buffer pool, size = 1.0G
22:41:42 32372 [Note] InnoDB: Completed initialization of buffer pool
22:41:42 32372 [Note] InnoDB: Highest supported file format is Barracuda.
22:41:42 32372 [Note] InnoDB: Log scan progressed past the checkpoint lsn 20293587957
22:41:42 32372 [Note] InnoDB: Database was not shutdown normally!
22:41:42 32372 [Note] InnoDB: Starting crash recovery.
22:41:42 32372 [Note] InnoDB: Reading tablespace information from the. ibd files...
22:41:42 32372 [Note] InnoDB: Restoring possible half-written data pages
22:41:42 32372 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 20293596130
22:41:42 32372 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 49 50 51 52 53 54 55 57 58 59 60 61 62 63 64 65 66 67 69 70 71 72 73 74 75 76 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 136254, file name mysql-bin.000013
22:41:43 32372 [Note] InnoDB: 128 rollback segment (s) are active.
22:41:43 32372 [Note] InnoDB: Waiting for purge to start
22:41:43 7f77a9edd700 InnoDB: Assertion failure in thread 140151928772352 in file trx0purge. cc line 699
InnoDB: Failing assertion: purge_sys-> iter. trx_no <= purge_sys-> rseg-> last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: Snapshot uption in the InnoDB tablespace. Please refer
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:41:43 UTC-mysqld got signal 6;
This cocould be because you hit a bug. It is also possible that this binary
Or one of the libraries it was linked against is too upt, improperly built,
Or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
Diagnose the problem, but since we have already crashed,
Something is definitely wrong and this may fail.

After analyzing the logs, it is found that the cause of the Database Failure to restart is that the ibdata1 file is damaged and the database cannot be recovered after the restart.

Solution:

Recovery steps need to be skippedModify the my. cnf file and add the following content to [mysqld] In my. cnf:

Innodb_force_recovery = 6
Innodb_purge_threads = 1

Explanation:

Innodb_force_recovery can be set to 1-6. A large number contains the effects of all the preceding numbers.

Meanings of specific numbers:

1 ----- (srvforceignore0000upt): Ignore the checked upt page.
2 ----- (SRVFORCENOBACKGROUND): prevents the running of the main thread. If the main thread needs to perform the full purge operation, crash may occur.
3 ----- (SRVFORCENOTRXUNDO): no transaction rollback is performed.
4 ----- (SRVFORCENOIBUFMERGE): Do not merge the insert buffer.
5 ----- (SRVFORCENOUNDOLOGSCAN): If you do not view redo logs, the InnoDB Storage engine considers uncommitted transactions as committed.
6 ----- (SRVFORCENOLOG_REDO): do not perform the rollback operation.

Start mysql again ~

If it cannot be started, you need to delete ibdata1, ib_logfile *, and other files under the Data Directory datafile.

After the instance is started, export the MySQL database and restore it.

The above perfectly solves the problem that mysql will be closed immediately after it is started (the ibdata1 file is damaged). This is all the content that I have shared with you. I hope you can give it a reference, we also hope that you can support the customer's home.