it-swarm-eu.dev

Wie erkennen Sie die Beschädigung der InnoDB-Tabelle?

Ich habe einige Tabellen, die partitioniert sind und mehrere Indizes für einen replizierten Slave haben. Nach dem Kopieren des Snapshots (verifizierter Safe) auf einen neuen Slave und dem Aktualisieren von mysqld von 5.1.42 auf 5.5.15 und dem Neustart der Replikation stürzt InnoDB mit der Fehlermeldung "Ungültiger Zeiger ..." ab.

Diese Fehler sind auf 2 Servern mit unterschiedlicher Hardware und Betriebssystem aufgetreten. Nach dem Rennen:

ALTER TABLE .... COALESCE PARTION n;

das Problem geht für diesen Tisch weg.

Meine Frage ist jedoch umfangreicher und lautet: "Wie identifizieren Sie die Beschädigung der InnoDB-Tabelle?" oder umformuliert "Wie beurteilen Sie den Zustand der InnoDB-Tabelle?" Ist "CHECK TABLE" das einzige verfügbare Tool, um Probleme vor dem Absturz zu identifizieren?

Ich bin mir nicht sicher, ob es wichtig ist, aber die Abstürze sind ausgeführt worden: Version: '5.5.15-55-log' Socket: '/opt/mysql.sock' Port: 3306 Percona Server (GPL), Release rel21.0, Revision 158

24
randomx

Morgan gibt in seinem Kommentar einen Hinweis darauf, dass InnoDB ständig nach beschädigten Seiten sucht, indem es Prüfsummen auf den gelesenen Seiten durchführt. Wenn InnoDB eine Nichtübereinstimmung der Prüfsumme feststellt, wird dies der Fall sein absturz Stoppen Sie den Server.

Wenn Sie diesen Prozess beschleunigen möchten (anstatt darauf zu warten, dass InnoDB die beschädigte Seite liest), können Sie innochecksum verwenden:

Da die Nichtübereinstimmung der Prüfsumme dazu führt, dass InnoDB einen laufenden Server absichtlich herunterfährt, kann es vorzuziehen sein, dieses Tool zu verwenden, anstatt darauf zu warten, dass ein Server in der Produktion auf die beschädigten Seiten stößt.

Eine interessante Einschränkung:

innochecksum kann nicht für Tablespace-Dateien verwendet werden, die der Server bereits geöffnet hat. Für solche Dateien sollten Sie CHECK TABLE verwenden, um Tabellen im Tablespace zu überprüfen.

Also ja, für eine Online-Tabelle CHECK TABLE ist wahrscheinlich das Tool (oder wie bereits erwähnt in einer anderen Antwortmysqlcheck, wenn Sie mehr als eine einzelne Datenbank gleichzeitig ausführen möchten.)

Wenn Sie Ihre Datenbank herunterfahren können, können Sie die Prüfsummen mit innochecksum erzwingen

Anekdotisch: Auf einem Innodb-Tablespace von 29 GB (mit innodb_file_per_table=1), dieses Skript dauerte ca. 2 Minuten

#!/bin/bash
for i in $(ls /var/lib/mysql/*/*.ibd)
do
  innochecksum -v $i
done

Als Bonus haben sie jedoch, da Sie Percona ausführen, eine neue Methode für schnelle innodb-Prüfsumme implementiert. Ich habe es nie benutzt, aber es könnte den Prozess beschleunigen.

18
Derek Downey

WARNUNG: Bevor Sie eine dieser Anweisungen ausführen, wird dringend empfohlen, zu überprüfen, ob für alle Fälle eine ordnungsgemäße Sicherung Ihrer Datenbank in Händen ist. (danke an @Nick für die Warnung)

Versuchen Sie, den Befehl mysqlcheck zu verwenden. Auf einem Terminal:

mysqlcheck -u username -p --databases database1 database2

Dieser Befehl gibt eine Liste aller Tabellen und einen Status aus, der Sie darüber informiert, ob eine Beschädigung vorliegt:

table1  OK
table2  OK
table3  OK
tableN  OK

Mit diesen Händen wissen Sie bereits, welche Tische Sie reparieren müssen. Nur für den Fall, dass Sie alles auf einmal reparieren möchten:

mysqlcheck -u username -p --auto-repair --databases database1 database2 

Weitere Informationen zu mysqlcheck: http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html

Hinweis: Sie haben Ihre Frage mit percona markiert. Ich hatte keine Ahnung, was das war, also googelte ich. Es scheint eine Abzweigung von MySQL zu sein, aber ich habe keinen Grund zu der Annahme, dass die Befehle nicht kompatibel sind (Daumen drücken).


Jemand hat mich auf dieses Handbuch verwiesen, das spezifischere Anweisungen für die Wiederherstellung der InnoDB-Datenbank für kritischere Situationen enthält, in denen nicht die gesamte Datenbank gestartet wird: http://www.softwareprojects.com/resources/programming/t-how-to -fix-mysql-database-myisam-innodb-1634.html

6
marcio

Gemäß MySQL 5.0 Certification Study Guide, Seite 443.444, Abschnitt 30.4 :

Sie können InnoDB-Tabellen mit dem Befehl CHECK TABLE oder mit einem Client-Programm überprüfen, um die Anweisung für Sie auszugeben. Wenn eine InnoDB-Tabelle jedoch Probleme aufweist, können Sie diese nicht mithilfe von REPAIR TABLE beheben, da diese Anweisung nur für MyISAM gilt.

Wenn eine Tabellenprüfung anzeigt, dass eine InnoDB-Tabelle Probleme aufweist, sollten Sie in der Lage sein, die Tabelle in einem konsistenten Zustand wiederherzustellen, indem Sie sie mit mysqldump sichern, löschen und aus diesem Speicherauszug neu erstellen.

Im Falle eines Absturzes eines MySQL-Servers oder des Hosts, auf dem er ausgeführt wird, müssen einige InnoDB-Tabellen möglicherweise repariert werden. Normalerweise reicht es aus, den Server einfach neu zu starten, da die InnoDB-Speicher-Engine im Rahmen ihrer Startsequenz eine automatische Wiederherstellung durchführt. In seltenen Fällen wird der Server möglicherweise nicht gestartet, da die automatische Wiederherstellung von InnoDB fehlgeschlagen ist. Gehen Sie in diesem Fall wie folgt vor:

  • Starten Sie den Server neu, indem Sie die Option --innodb_force_recovery auf einen Wert in der Wut von 1 bis 6 setzen. Diese Werte weisen auf eine zunehmende Vorsicht bei der Vermeidung eines Absturzes und auf eine zunehmende Toleranz für mögliche Inkonsistenzen in den wiederhergestellten Tabellen hin. Ein guter Anfangswert ist 4.

  • Wenn Sie den Server mit --innodb_force_recovery auf einen Wert ungleich Null starten, behandelt InnoDB den Tabellenbereich als schreibgeschützt. Folglich sollten Sie die InnoDB-Tabellen mit mysqldump sichern und sie dann löschen, während die Option aktiviert ist. Starten Sie dann den Server ohne die Option --innodb_force_recovery neu. Wenn der Server hochfährt, stellen Sie die InnoDB-Tabellen aus den Speicherauszugsdateien wieder her.

  • Wenn die vorhergehenden Schritte fehlschlagen, müssen die InnoDB-Tabellen aus einer vorherigen Sicherung wiederhergestellt werden.

Bitte lesen Sie MySQL Docs auf InnoDB Forced Recovery

6
RolandoMySQLDBA

Ich frage mich, was passiert, wenn jemand InnoDB-Daten verwendet, die über das InnoDB-Plugin erstellt wurden, und dann zu einer anderen Version von InnoDB wechselt. Dies könnte in den Augen von mysqld zu einer möglichen Seitenbeschädigung führen.

Beachten Sie, was die MySQL-Dokumentation zum InnoDB-Dateiformat über diese Möglichkeit aussagt:

Im Allgemeinen kann eine neuere Version von InnoDB eine Tabelle oder einen Index erstellen, die mit einer früheren Version von InnoDB nicht sicher gelesen oder geschrieben werden können, ohne dass das Risiko von Abstürzen, Hängen, falschen Ergebnissen oder Beschädigungen besteht. Das InnoDB-Plugin führt einen neuen Mechanismus ein, um sich vor diesen Bedingungen zu schützen und die Kompatibilität zwischen Datenbankdateien und Versionen von InnoDB zu gewährleisten.

Ich würde die Daten auf dem Slave verschrotten. Tatsächlich würde ich nur Brute Force anwenden, indem ich einen logischen Speicherauszug (mysqldump) der Daten erhalte:

  • Löschen Sie alle Datenbanken mit InnoDB auf dem Slave
  • Fahren Sie MySQL auf dem Slave herunter
  • Löschen Sie ibdata1, ib_logfile0 und ib_logfile1 auf dem Slave
  • Starten Sie mysql auf dem Slave und lassen Sie ibdata1, ib_logfile0 und ib_logfile1 neu erstellen
  • mysqldump die Daten vom Master in den Slave

Meine ursprünglich gepostete Antwort gilt als "alte Schule". In diesem Fall würde ich jedoch definitiv die Dateiformate untersuchen, die von .ibd und/oder ibdata1 verwendet werden.

2
RolandoMySQLDBA