Introduction détaillée pour résoudre le problème de l'arrêt de MySQL immédiatement après le démarrage (causé par des dommages au fichier ibdata1)

L'éditeur ci-dessous vous apportera une solution parfaitemysql immédiatement après le démarrage Le problème de fermeture (causée par l'endommagement du fichier ibdata1). L'éditeur pense que c'est plutôt bien, je vais donc le partager avec vous maintenant et lui donner une référence

Sur un serveur de la salle informatique. fonctionne depuis un certain temps, et un phénomène très étrange s'est soudainement produit : Il ne peut pas être restauré après le redémarrage ! La situation exacte est la suivante : Mysql est arrêté immédiatement après son démarrage 🎜> Consultez le journal des erreurs mysql comme suit :

InnoDB : Récupération en cours : analysé jusqu'au numéro de séquence du journal 20293596130

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 : Échec de l'assertion : 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

Journal d'analyse Il a été découvert plus tard que la raison pour laquelle la base de données n'a pas pu être redémarré parce que le fichier ibdata1 a été endommagé et n'a pas pu être restauré normalement après le redémarrage

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.

Vous devez ignorer l'étape de récupération

, modifier le fichier my.cnf, et ajoutez [mysqld] dans my.cnf :

innodb_force_recovery = 6
innodb_purge_threads = 1

Explication :

innodb_force_recovery fonctionne Fixé sur 1 à 6, le plus grand nombre inclut l'influence de tous les nombres précédents
La signification correspondante du numéro spécifique :

1-----(SRVFORCEIGNORECORRUPT) : Ignorer la page corrompue détectée 2---. --(SRVFORCENOBACKGROUND): Empêcher le thread principal de s'exécuter. Si le thread principal doit effectuer une opération de purge complète, cela provoquera un crash .-----(SRVFORCENOTIRXUNDO): Ne pas effectuer de restauration de transaction. 4-----(SRVFORCENOIBUFMERGE) : N'effectuez pas d'opération de fusion du tampon d'insertion. -(SRVFORCENOUNDOLOGSCAN) : Sans afficher le journal de rétablissement, le moteur de stockage InnoDB traitera les transactions non validées comme validées.

6-----(SRVFORCENOLOG_REDO) : N'effectuez pas d'opération de roll forward.

Redémarrez MySQL et tout ira bien~

S'il ne peut toujours pas être démarré, vous devez supprimer ibdata1, ib_logfile* et les autres fichiers du fichier de données du répertoire de données.
Exportez la base de données MySQL après le démarrage et restaurez-la à nouveau.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!