InnoDB 10.4.17 reparieren

[Franky27]

Hallo,

meine mySQL-Installation in XAMPP startete nicht mehr, die Tabelle ./mysql/db war korrupt laut Windows-Ereignisprotokoll.
Ich habe die 4 db.*-Dateien aus dem letzten Backup zurückgespielt, nun startet das Programm wieder und es scheint auch alles zu funktionieren.
Allerdings finden sich im mysql_error.log ca 100 kB solcher Einträge vom Start:

2021-07-29 13:29:12 0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=0, page number=328] with future log sequence number 453456634
2021-07-29 13:29:12 0 [Warning] InnoDB: Ignoring a doublewrite copy of page [page id: space=0, page number=445] with future log sequence number 453456502

Und solche:
2021-07-29 13:29:12 0 [ERROR] InnoDB: Page [page id: space=0, page number=262] log sequence number 453805249 is in the future! Current system log sequence number 452152270.
2021-07-29 13:29:12 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to InnoDB Recovery Modes for information about forcing recovery.

Wie bekomme ich die DB wieder in einen konsistenten Zustand?
innodb_force_recovery soll man ja nur in einer Notsituation verwenden laut Doku.
Vermutlich muss ja nur die Logsequenznummer korrigiert werden, aber wie?

Vielen Dank schon mal für kluge Tipps sagt

Franky

 

[akretschmer]

Vielen Dank schon mal für kluge Tipps

Backup einspielen, und drüber nachdenken, in Zukunft vielleicht was besseres zu verwenden.

 

[Franky27]

Sehr hilfreich war die Antwort nicht.
Was ist "was besseres"?
Das ist meine lokale Testdatenbank für die Webpräsenz, auf der nur mySQL verfügbar ist.
Außerdem sind Tabellen drin, die mit Libreoffice benutzt werden.

 

[akretschmer]

Was ist "was besseres"?

siehe meine Signatur.

 

[Franky27]

Ich hatte in meinem langen Arbeitsleben nur mit 2 DB-Crashs zu tun, das erste war dBase (ca 20 Jahre her) und das zweite PostgreSQL (ca 6 Jahre her)

 

[akretschmer]

Ich hatte in meinem langen Arbeitsleben nur mit 2 DB-Crashs zu tun, das erste war dBase (ca 20 Jahre her) und das zweite PostgreSQL (ca 6 Jahre her)

Du hast ein gutes Langzeitgedächtniss, aber offenbar ein sehr schlechtes Kurzzeitgedächniss. Zur Erinnerung: #1, das war gestern.

 

[Franky27]

Ich hab von meinem Arbeitsleben geschrieben, jetzt bin ich im Rentnerleben.
Aber eigentlich hab ich mich im Forum angemeldet, um geholfen bekommen und nicht, um dumm vollgepflaumt zu werden.
Das Forum heißt "MySQL und MariaDB" aber scheinbar sind die Leute, die sich damit auskennen, alle gerade im Urlaub.

 

[akretschmer]

was genau ist an "Backup einspielen" dumm?

 

[dabadepdu]

Ich kann leider nicht helfen (auch wenn ich keinen Urlaub habe), aber ich würde als Frage noch ergänzen:
Was hat zu dem Crash geführt/wie kann ich das zukünftig vermeiden / war das Backup oder das Rückspielen korrekt erfolgt.

Vielleicht kommst Du um ein force recovery nicht herum.

 

[Franky27]

was genau ist an "Backup einspielen" dumm?

Nichts. Das galt deiner Beurteilung meines Gedächtnisses.

 

[Franky27]

Was hat zu dem Crash geführt/wie kann ich das zukünftig vermeiden / war das Backup oder das Rückspielen korrekt erfolgt.

Ich habe mysql ganz normal beendet, anschließend ein backup gemacht. Am nächsten Tag startete mysql nicht mehr.
Also habe ich die Tabelle ./mysql/db aus einem älteren Backup wieder zurück gespielt, siehe Beitrag #1
Nun gibt es die beschriebenen Probleme.
Das gleiche alte Backup für die Daten zu verwenden ist nicht möglich, weil an dem betreffenden Tag sehr viele Daten erfasst wurden.
Die Tabellen sind ja ok, nur halt nicht synchron mit mysql/db

 

[akretschmer]

Dein Vorgehen ist IMHO prinzipiell falsch, man kopiert nicht einzelne Dateien rum, sondern macht mit dem, was die DB mitliefert, ein Backup. Bei PostgreSQL wäre das pg_dump, pg_dumpall oder pg_basebackup, MySQL hat mysqldump.
Alles andere führt zielsicher zu Inkonsistenzen.

Wenn Du MySQL beendet hattest und dann ein Backup gemacht hast (Frage: wie? Ein Dump kann es ja nicht sein ...), dann solltest Du das KOMPLETTE Backup nutzen. Die am Tag erfaßten Daten SIND im Backup, welches Du nach dem runterfahren von MySQL gemacht hast.

 

[Franky27]

Mein Backup war das gesamte data-Verzeichnis.
Da die DB ja bis zuletzt lief, konnte ich davon ausgehen, dass das konsistent war. War es aber nicht, weil die Tabelle mysql/db zerschossen war (auch im letzten Backup) Die db.MAI ist bei mir eigentlich 24 kB groß, die kaputte war knapp 1 MB groß.
Ich vermute mal mysqldump hättte mir hier nicht weitergeholfen, denn wie hätte ich da was zurückspielen können, wenn mysql gar nicht startet?

Außerdem gibt es in mysql wohl Selbstheilungskräfte. Heute kleines Wunder beim Start:

2021-07-31 7:30:02 0 [Note] mysqld.exe: Aria engine: starting recovery
recovered pages: 0% 10% 21% 34% 59% 75% 87% 97% 100% (0.1 seconds); tables to flush: 8 7 6 5 4 3 2 1 0 (0.0 seconds);
2021-07-31 7:30:02 0 [Note] mysqld.exe: Aria engine: recovery done
InnoDB: using atomic writes.
...

Nun findet sich kein Fehler mehr im heutigen error log

 

[dabadepdu]

24 KB ist eine recht kleine DB, Tippfehler?
Aber was solls, es läuft wieder.

"Selbstheilungskräfte" hat jede Datenbank implementiert, die etwas auf sich hält. Ein normaler Stromausfall o.ä., auch unter Last, sollte verkraftbar sein. Es werden beim Neustart alle abgeschlossenen (commit) Änderungen aus den Logfiles nach gefahren, die nicht in den Datenfiles stehen. Jedes System macht das etwas anders. Die Prinzipien ähneln sich. Wie es bei MySQL läuft, keine Ahnung. Fehlerhafte Sektoren oder Kopieraktionen im laufenden Datenbankbetrieb sind allerdings schon eine andere Liga als Stromausfall.
Ich arbeite schon lange mit DB und habe es noch nie geschafft, eine kaputt zu bekommen, auch wenn es früher vielleicht sogar einfacher war. Daher mein ursprünglicher Rat, zu analysieren, wie es überhaupt zu dem Fehler kam.

 

[akretschmer]

Ich vermute mal mysqldump hättte mir hier nicht weitergeholfen, denn wie hätte ich da was zurückspielen können, wenn mysql gar nicht startet?

Stchwort für Google wäre hier "desaster recovery", und gerade als MySQL-User sollte man sich sehr intensiv damit beschäftigen.