it-swarm.com.de

Wird nicht gestartet: InnoDB: Beschädigte Seite ... Tablespace wurde nicht gefunden

Wenn ich nach einem Serverabsturz (Ubuntu 16.04) versuche, MySQL (MySQL 5.7) mit innodb_force_recovery=0 Zu starten, wird es nicht gestartet und error.log zeigt:

InnoDB: Checksum mismatch in datafile: ./panel_financiero_v2/kpis_analytics.ibd, Space ID:93, Flags: 33. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
InnoDB: Corrupted page [page id: space=93, page number=0] of datafile './panel_financiero_v2/kpis_analytics.ibd' could not be found in the doublewrite buffer.
InnoDB: Tablespace 93 was not found at ./panel_financiero_v2/kpis_analytics.ibd.
InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
InnoDB: Cannot continue operation.

Ich kann MySQL nur mit innodb_force_recovery=6 Starten (ich kann MySQL nicht mit innodb_force_recovery = 1 starten, wie in der Fehlermeldung angegeben). Die .ibd- und .frm-Dateien der problematischen Tabelle befinden sich im richtigen Verzeichnis (keine leeren Dateien). Ich habe sogar versucht (nur für den Fall, ohne wirkliche Hoffnung), diese beiden Dateien zu löschen (sie in ein anderes Verzeichnis zu verschieben), aber es funktioniert auch nicht.

Gibt es eine Möglichkeit, die Tabelle zu reparieren oder wiederherzustellen (wenn man bedenkt, dass innodb_force_recovery = 6 MySQL im schreibgeschützten Modus startet und ich nicht einmal eine neue Tabelle erstellen kann)? Wie kann man mysql zumindest normal starten (mit innodb_force_recovery=0) Und sogar die Informationen dieser problematischen Tabelle verlieren?

5
Felipe Alonso

https://dev.mysql.com/doc/refman/5.7/en/repair-table.html sagt:

REPAIR TABLE funktioniert für MyISAM-, ARCHIVE- und CSV-Tabellen.

Mit anderen Worten, REPAIR TABLE tut nichts für InnoDB. InnoDB hat seine eigene automatische Absturzwiederherstellung , die beim Start ausgeführt wird.

Die Wiederherstellung nach einem InnoDB-Absturz funktioniert jedoch nur bei verlorenen Änderungen, die zum Zeitpunkt des Absturzes ausgeführt wurden. Es verwendet das Redo-Log und den Doublewrite-Puffer, um verlorene schmutzige Seiten zu rekonstruieren. Dieser Prozess kann keine Daten rekonstruieren, die im Ruhezustand beschädigt wurden.

Die Fehlermeldung sagt Ihnen tatsächlich, was zu tun ist:

InnoDB: Setzen Sie innodb_force_recovery = 1, um dies zu ignorieren und alle Änderungen am Tablespace dauerhaft zu verlieren.

Weitere Informationen finden Sie unter https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html :

1 (SRV_FORCE_IGNORE_CORRUPT) Lässt den Server auch dann laufen, wenn er eine beschädigte Seite erkennt. Versucht, SELECT * FROM tbl_name über beschädigte Indexdatensätze und Seiten springen zu lassen, was beim Speichern von Tabellen hilfreich ist.

Starten Sie den Server mit innodb_force_recovery=1 nachdem Sie Ihre Tablespace-Dateien wieder dorthin verschoben haben, wo sie hingehören.

Dann können Sie die Tabelle mit mysqldump sichern, und sie sollte die Seiten lesen, die sie lesen kann, und beschädigte Seiten überspringen. Anschließend können Sie eine neue Tabelle zum Importieren aus dem Speicherauszug erstellen:

CREATE TABLE mytable_new LIKE mytable;
RENAME TABLE mytable TO mytable_bad, mytable_new TO mytable;

Importieren Sie dann Ihre gedumpten Daten erneut.

Ich gehe davon aus, dass Sie keine Hilfe beim Speichern einer einzelnen Tabelle und beim Importieren der Speicherauszugsdatei benötigen.


Zu Ihrem Kommentar:

Es scheint, als hätten Sie eine umfassendere Korruption. Ich schlage folgende Schritte vor:

  1. Starten Sie den MySQL-Server mit innodb_force_recovery=6
  2. Verwenden Sie mysqldump, um all der Daten zu sichern.
  3. Fahren Sie den MySQL-Server herunter.
  4. Sichern Sie den Inhalt Ihres Datenverzeichnisses, falls Sie professionelle Hilfe benötigen, um festzustellen, ob mehr Daten wiederhergestellt werden können. Versuchen Sie https://twindb.com , sie sind die besten Experten für die Wiederherstellung von MySQL-Datenbanken.
  5. Initialisieren Sie ein neues Datenverzeichnis (ich würde ein neues Festplattengerät verwenden und das alte außer Betrieb nehmen, da es jetzt unbekannte Schäden aufweist).
  6. Stellen Sie den mit mysqldump erstellten Datendump wieder her.
9
Bill Karwin

Wir hatten das gleiche Problem in einer Bitnami Wordpress Appliance). Wir haben viele Websites und Verfahren untersucht, um dieses Problem zu beheben. Keiner der untersuchten Artikel, Blogs und Beiträge hatte die Lösung, die wir brauchten, aber wir konnten Folgendes zusammensetzen.

  1. protokolldatei überprüfen:

    cd/opt/bitnami/mysql tail -400 mysqld.log

AUFGEFÜHRTE FEHLER:

[ERROR] [MY-012224] [InnoDB] Checksum mismatch in datafile: ./bitnami_wordpress/wp_redirection_404.ibd 
[ERROR] [MY-012237] [InnoDB] Corrupted page [page id: space=2126, page number=0] of datafile './bitnami_wordpress/wp_redirection_404.ibd' could not be found in the doublewrite buffer. 
[ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:5551:err == DB_SUCCESS || err == DB_INVALID_ENCRYPT 
  1. Problem und zugehöriges Objekt identifizieren:

    data/bitnami_wordpress/wp_redirection_404.ibd

  2. Problemdatei entfernen:

    mv data/bitnami_wordpress/wp_redirection_404.ibd/tmp /.

  3. Ändern Sie die Konfigurationsdatei, um MySQL zu starten, und ignorieren Sie dabei Fehler:

    vi /opt/bitnami/mysql/my.cnf

-- hinzufügen 'innodb_force_recovery = 1 'zum Ende des Abschnitts " [mysqld] "

  1. Starten Sie MySQL im Wiederherstellungsmodus:

    /opt/bitnami/ctlscript.sh starte mysql

    /opt/bitnami/ctlscript.sh Status MySQL

  2. Ändern Sie die Konfigurationsdatei, um MySQL im NORMAL-Modus zu starten:

    vi /opt/bitnami/mysql/my.cnf

- entferne 'innodb_force ...' aus Abschnitt " [mysqld] "

  1. Starten Sie MySQL neu, um zu überprüfen, ob es korrekt gestartet wurde:

    /opt/bitnami/ctlscript.sh starte mysql

    /opt/bitnami/ctlscript.sh Status MySQL

  2. Überprüfen Sie Wordpress Website wird korrekt gerendert: Navigieren Sie zu http://websiteurl.company.com

  3. Stellen Sie die MySQL-Datenbank aus den neuesten Sicherungen wieder her:

    • beenden Sie die 'root'-Sitzung zur' bitnami'-Kontositzung

- Löschen Sie die lokale MySQL-Datenbank

cd /opt/bitnami/mysql/data/${dbname} ; /home/bitnami/blankwpdb.sh ${dbname} ${dbuser}

--Stellen Sie die MySQL-Datenbank aus der Primärsicherung wieder her

cd /opt/bitnami/mysql/data/${dbname} ; cat ${current_mysql_bkup} | /opt/bitnami/mysql/bin/mysql -u ${dbuser} -p${dbpw} ${dbname}

- Starten Sie MySQL und Apache HTTP Services neu

/opt/bitnami/mysql/scripts/ctl.sh restart
/opt/bitnami/Apache2/scripts/ctl.sh restart

=====/blankwpdb.sh======
#!/bin/bash
EXPECTED_ARGS=2
E_BADARGS=65
MYSQL=`which mysql`
dbpw=`grep DB_PASSWORD /opt/bitnami/apps/wordpress/htdocs/wp-config.php | cut -d \' -f 4`
C1="DROP DATABASE IF EXISTS $1;"
C2="CREATE DATABASE $1;"
COMMANDS="${C1}${C2}"
if [ $# -ne $EXPECTED_ARGS ]
then
  echo "Usage: $0 dbname dbadmin"
  exit $E_BADARGS
fi
$MYSQL -u$2 -p$dbpw -e "$COMMANDS"
  1. Überprüfen Sie Wordpress Website wird korrekt gerendert:

Navigieren Sie zu http://websiteurl.company.com

Ich hoffe, dies hilft jedem, der dieses spezielle Problem jetzt oder in Zukunft weiterhin erlebt.

0
Shaun Walter