Detaillierte Einführung zur Lösung des Problems, dass MySQL unmittelbar nach dem Start herunterfährt (verursacht durch eine Beschädigung der ibdata1-Datei)

Der folgende Editor bietet Ihnen eine perfekte Lösungmysql Unmittelbar nach dem Start Das Problem von Schließen (verursacht durch den Schaden an der ibdata1-Datei), also werde ich es jetzt mit Ihnen teilen und einen Verweis auf einen Server im MySQL-Raum geben läuft schon eine Weile und plötzlich ist ein sehr seltsames Phänomen aufgetreten:

Es kann nach dem Neustart nicht wiederhergestellt werden. Die genaue Situation ist: MySQL wird sofort nach dem Start heruntergefahren 🎜> Sehen Sie sich das MySQL-Fehlerprotokoll wie folgt an:

InnoDB: Wiederherstellung wird durchgeführt: Bis zur Protokollsequenznummer 20293596130 gescannt

160920 22:41:41 mysqld_safe Starting mysqld daemon with databases from /home/MysqlData/
2016-09-20 22:41:41 0 [Note] /Data/app/mysql5.6.25/bin/mysqld (mysqld 5.6.25-log) starting as process 32372 ...
2016-09-20 22:41:42 32372 [Note] 
Plugin 'FEDERATED' is disabled.
2016-09-20 22:41:42 32372 
[Warning] option 'innodb-write-io-threads': unsigned value 1000 adjusted to 64
2016-09-20 22:41:42 32372
 [Warning] option 'innodb-read-io-threads': unsigned value 1000 adjusted to 64
2016-09-20 22:41:42 32372 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-09-20 22:41:42 32372 [Note] InnoDB: The InnoDB memory heap is disabled
2016-09-20 22:41:42 32372 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-09-20 22:41:42 32372 [Note] InnoDB: Memory barrier is not used
2016-09-20 22:41:42 32372 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-09-20 22:41:42 32372 [Note] InnoDB: Using CPU crc32 instructions
2016-09-20 22:41:42 32372 [Note] InnoDB: Initializing buffer pool, size = 1.0G
2016-09-20 22:41:42 32372 [Note] InnoDB: Completed initialization of buffer pool
2016-09-20 22:41:42 32372 [Note] InnoDB: Highest supported file format is Barracuda.
2016-09-20 22:41:42 32372 [Note] InnoDB: Log scan progressed past the checkpoint lsn 20293587957
2016-09-20 22:41:42 32372 [Note] InnoDB: 
Database was not shutdown normally!
2016-09-20 22:41:42 32372 [Note] InnoDB: Starting crash recovery.
2016-09-20 22:41:42 32372 [Note] InnoDB: Reading tablespace information from the .ibd files...
2016-09-20 22:41:42 32372 [Note] InnoDB: Restoring possible half-written data pages 
2016-09-20 22:41:42 32372 [Note] InnoDB: from the doublewrite buffer...

InnoDB: Behauptung fehlgeschlagen : purge_sys->iter.trx_no aed35fad5efef22ef3ddda2955186ec0rseg->last_trx_no

2016-09-20 22:41:42 32372 [Note] InnoDB: Starting an apply batch of log rec
ord
s to the database...
InnoDB: Progress in percent: 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 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.00
001
3
2016-09-20 22:41:43 32372 [Note] InnoDB: 128 rollback segment(s) are active.
2016-09-20 22:41:43 32372 [Note] InnoDB: Waiting for purge to start
2016-09-20 22:41:43 7f77a9edd700 InnoDB: Assertion failure in thread 140151928772352 in file trx0purge.cc line 699

Analyseprotokoll Später wurde festgestellt, dass der Grund für die Datenbank konnte nicht neu gestartet werden, weil die Datei ibdata1 beschädigt war und nach dem Neustart nicht normal wiederhergestellt werden konnte
Sie müssen den Wiederherstellungsschritt überspringen

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: corruption in the InnoDB tablespace. Please refer to
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 could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, 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.

, die Datei my.cnf ändern. und füge [mysqld] in my.cnf hinzu:

innodb_force_recovery = 6

innodb_purge_threads = 1

Erklärung:
innodb_force_recovery funktioniert. Auf 1-6 eingestellt, die größere Zahl beinhaltet den Einfluss aller vorherigen Zahlen

Die entsprechende Bedeutung der spezifischen Nummer:

1-----(SRVFORCEIGNORECORRUPT): Ignorieren Sie die erkannte beschädigte Seite 2---. --(SRVFORCENOBACKGROUND): Verhindert die Ausführung des Hauptthreads, da dies zu einem Absturz führt Operation.
4-----(SRVFORCENOIBUFMERGE): Führen Sie keine Zusammenführungsoperation des Einfügepuffers durch. -(SRVFORCENOUNDOLOGSCAN): Ohne Anzeige des Redo-Logs behandelt die InnoDB-Speicher-Engine nicht festgeschriebene Transaktionen. 6-----(SRVFORCENOLOG_REDO): Führen Sie keinen Rollforward-Vorgang durch.

Starten Sie MySQL erneut und es wird in Ordnung sein~

Wenn es immer noch nicht gestartet werden kann, müssen Sie ibdata1, ib_logfile* und andere Dateien im Datenverzeichnis datafile löschen.

Exportieren Sie die MySQL-Datenbank nach dem Start und stellen Sie sie erneut wieder her.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung zur Lösung des Problems, dass MySQL unmittelbar nach dem Start herunterfährt (verursacht durch eine Beschädigung der ibdata1-Datei). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!