Il n'y a rien que vous puissiez vraiment faire car une restauration est en cours via l'espace de table UNDO à l'intérieur d'ibdata1 , qui aurait dû se développer considérablement.
Si vous tuez le processus mysqld et redémarrez mysql, il reprendra simplement là où il s'était arrêté dans le cadre du cycle de récupération après incident.
AVERTISSEMENT: pas responsable de la perte de données
Ce que vous pourriez faire peut entraîner une perte de données pour d'autres tables, mais vous pouvez faire quelque chose pour contourner le cycle normal de récupération après incident d'InnoDB.
Il existe une option de démarrage appelée innodb_force_recovery , qui vous permet de contourner les différentes étapes de la récupération après incident d'InnoDB.
Selon la documentation MySQL sur Forcing InnoDB Recovery , voici les paramètres et leurs effets:
1 (SRV_FORCE_IGNORE_CORRUPT)
Laissez le serveur s'exécuter même s'il détecte une page corrompue. Essayez de faire SELECT * FROM tbl_name sauter par-dessus les enregistrements et les pages d'index corrompus, ce qui aide à vider les tables.
2 (SRV_FORCE_NO_BACKGROUND)
Empêchez l'exécution du thread principal. Si un plantage se produisait pendant l'opération de purge, cette valeur de récupération l'empêche.
3 (SRV_FORCE_NO_TRX_UNDO)
N'exécutez pas de restauration de transactions après une récupération après incident.
4 (SRV_FORCE_NO_IBUF_MERGE)
Empêcher les opérations de fusion de tampon d'insertion. S'ils provoquaient un crash, ne les faites pas. Ne calculez pas les statistiques de table.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Ne regardez pas les journaux d'annulation lors du démarrage de la base de données: InnoDB traite même les transactions incomplètes comme validées.
6 (SRV_FORCE_NO_LOG_REDO)
N'effectuez pas la restauration du journal de reprise dans le cadre de la récupération.
Avec les modifications transactionnelles enfouies dans les journaux UNDO et REDO, vous courez le risque de
- perte de données destinées à être écrites
- conserver les données destinées à être supprimées
Dans le cas où vous vous attendez à de mauvais effets secondaires, sauvegardez l'intégralité de / var / lib / mysql et placez-le quelque part au cas où vous voudriez copier ibdata1, ib_logfile0 et ib_logfile1 et réessayer la récupération normale.
Si mysql est complètement opérationnel dans l'un des modes
- mysqldump toutes les données sauf la table incriminée
- arrêter mysql
- supprimer tout dans / var / lib / mysql sauf / var / lib / mysql / mysql
- démarrer mysql
- recharger le mysqldump
CAVEAT: Assurez-vous de tout sauvegarder !!!
J'espère que ça aide !!!
