[Eisfair] HILFE mein Eis hat 6 Std vor der Urlaubsreise die Platte gekillt

[Marcus Roeckrath]

Hallo Peter,

Peter Schauder wrote:

>>Eventuell hilft:
>>
>>https://www.experts-exchange.com/questions/28137009/MYSQL-Error-1045-Access-Denied-log-sequence-number-ibdata-files-does-not-match.html
> 
> Wenn ich hier richtig verstanden habe, dann könnte der Versuch, die
> Logdatei zu löschen, dazu führen, dass eine neue angelegt wird und,
> vermutlich unter verlust der letzten geänderten Daten, der
> Databaseserver wieder startet?

Ja, so habe ich das auch verstanden.

Ich vermute, dass in den "Log"-Files zunächst die geplanten Transaktionen -
wie im Journal von ext3/4 - hinterlegt werden und nach Abschluss daraus
wieder gelöscht werden. Jedenfalls stelle ich es mir so vor. Nunsind
irgendwelche Transaktionszähler zwischen DB und Log nicht konsistent, weil
vielleicht die Transaktion in die DB gescehen, aber das Log nicht
nachgeführt wurde.

Jemand der wirklich Ahnung von mysl hat, kann dir das bestimmt haarklein
erklären.

> Auf dem Server läuft ein Webtree, ein Mantis und ein Mediawiki, von
> allen drei Datenbanken habe ich ein Backup. Die Nextcloud, die läuft
> ist dummerweise nicht gesichert, aber ich habe ein ältere Fullbackup
> der Platte, von dem ich noch eine Sicherung erzeugen könnte...Kalender
> und Kontakte sind noch aus der Thunderbirdinstallation abgreifbar.
> Insoweit ist alles im grünen Bereich.

IMHO sind nur die DBs betroffen, die als Datenbanktyp InnoDB nutzen, das
wäre bei dir definitiv owncloud.

Woran erkennt man das?

In /srv/mysql/55 liegen für jede DB Unterverzeichnisse, also owncloud, ...

Befinden sich in einem solchen Unterverzeichnis nur *.frm Dateien, ist es
eine InnoDB, deren Daten in /srv/mysql/55/ibdata1, und zwar für alle
InnoDBs gemeinsam; das zugehörige Log wäre ib_logfile0 und ib_logfile1.

Befinden sich in den DB-Unterverzeichnissen auch *MYI und *MYD Dateien, ist
es eine MyIsam-DB, die IMHO von deinem Problem nicht betroffen sind,
jedenfalls wird für solche DBs IMHO kein Log geführt, so dass ein Problem
auf diese Weise gemeldet werden könnte.

> Meine Idee für das weitere Vorgehen wäre:
> 
> 1. Full Backup der aktuellen Installation

Es sollte reichen, den kompletten Verzeichniszweig /srv/mysql/55 für weitere
Rettungsversuche zu sicher, wobei mysql/mariadb nicht laufen darf.

> 2. Starten der "alten" Version und sichern der Nextcloud Daten

Ohne laufende DB kannst du doch nichts sichern.

> 3. Starten der aktuellen Installation und entfernen der Logdatei
> (/srv/mysql/55/ib_logfile0)

Mit starten meinst du Server starten? ich würde wohl ib_logfile0 und
ib_logfile1 entfernen.

> 4. Neustart der Datenbank, wahlweise unter aussprechen von
> Beschwörungformeln, Gebeten, Flüchen oder anderem mir bisher noch
> nicht bekanntem.

Genau.

> 5. Wenn es nicht funktioniert, die Datenbank löschen (auch wenn ich
> noch nicht weiß wie) und die Backups zu installieren.

Erstmal nachdenken; vor allem ist mir nicht klar, in welcher Form liegen
deine Backups vor?

Sind das Sicherungen des Servers oder spezielle Backups der DBs (Dumps der
DBs wie sie auch das mariadb/mysql-Paket erzeugt).

> Könnte das so funktionieren? Oder hast du eine andere Idee? Oder
> Zusätzliche Aufgaben?

Ja.

-- 
Gruss Marcus