[erledigt] mySQL auf Windows Server 2012, nach Stromausfall 100% CPU Last durch mySQL

[DS_Starter]

sqlResultNumRows 1

ist das Ergebnis. Dort steht im Normalfall 0.

EDIT bei mir:

Code Auswählen Erweitern


2019-10-17 21:47:26   SqlResultRow_1  0


[Frank_Huber]

Die knapp 2GB werden sicher viele Stunden recovery verursachen.

Keine Ahnung ob man das recovery irgendwo sieht... Guck dich im mysql admin ein bissl um. Ich denke aber das Problem löst sich von selbst, wenn das recovery durch ist.

BTW... Du solltest dein logging einschränken, so viele Daten braucht man doch nicht wirklich.

Danke, dann lass ich das mal rennen und schau was passiert.

Ja, das bereinigen der Historie steht noch auf der Liste.
Hab erst "vor kurzem" alles auf einen zentralen mySQL umgezogen und noch nicht die ganze to do abgearbeitet.
sind aktuell so um die 22Mio Einträge.
Hab das noch nicht angegangen weil die DB auch stabil und gut funktioniert. selbst der dump ist in unter 2 min durch. Aber ja, das muss jetzt dann wohl sein.

[DS_Starter]

Ja dann schau mal. 

[DS_Starter]

Schau aber auch mal ins errorlog rein. Sollte das

/var/log/mysql/error.log

sein.

[DS_Starter]

Ich habe jetzt nochmal in Ruhe gesucht.
Der Read-only mode kommt m.M. nach allein durch dein Setzen von innodb_force_recovery = 4

...
As a safety measure, InnoDB prevents INSERT , UPDATE , or DELETE operations when innodb_force_recovery is greater than 0. An innodb_force_recovery setting of 4 or greater places InnoDB in read-only mode.
..
A value of 4 or greater is considered dangerous because data files can be permanently corrupted.
...

Vermutlich wirst du nicht drumherum kommen die DB aus dem Backup neu aufzubauen. Sollte die Situation nicht besser werden, versuche mit innodb_force_recovery < 4 zu starten und die Datenbank zu löschen. Danach kann man sie wieder neu erzeugen und aus dem Backup die history wieder herstellen.

Na mal schauen ....

[Frank_Huber]

Schau aber auch mal ins errorlog rein. Sollte das

/var/log/mysql/error.log

sein.

In Windows ist es:
C:\ProgramData\MySQL\MySQL Server 8.0\Data\SERVERNAME.err

Die letzten Zeilen hab ich mal als txt angehängt. für den Coder Tag ist es zu viel.
Interessant ist:

Code Auswählen Erweitern

2019-10-17T22:01:39.541798Z 40 [ERROR] [MY-011906] [InnoDB] Database page corruption on disk or a failed file read of page [page id: space=73, page number=199556]. You may have to recover from a backup.
...
...
InnoDB: End of page dump
InnoDB: Page may be an index page where index id is 247

Ist hier womöglich "nur" der Index futsch?
Aber auch den kann ich ja nicht löschen im readonly.

CPU ist übrigens noch an Anschlag.

mit recover 2 kam der server nicht hoch, daher bin ich dann auf 4 und er startete.

Ich geb ihm jetzt mal noch bis Mittag, dannach werd ich schauen dass ich die DB irgendwie vom Restore bekomme.

Danke & Grüße
Frank

[DS_Starter]

Morgen Frank,

ich gehe davon aus dass eine dauerhafte Schädigung vorliegt. Da würde ich auch nicht lange rummmachen, die DB löschen, eine neu anlegen, die Tabellen mit dem Script neu erzeugen und die history aus dem Backup herstellen.
Du musst vorher die Tabellen anlegen !
Das serverside backup erzeugt die Tabellenstruktur nicht selbst.

Grüße,
Heiko

[Frank_Huber]

Danke Heiko,

Denke auch dass da nix zu retten ist.
--> mySQL stoppen,
--> Dateien löschen
--> recovery Zeile wieder auskommentieren
--> mySQL starten
--> Datenbank und Tabellen anlegen
--> restore aus FHEM anstossen

wäre das der richtige Weg?

[DS_Starter]

Ja, sollte so klappen. Aber lies vorher nochmal im Netz ob ein einfaches löschen der Dateien korrekt ist. So einen drastischen Fall hatte ich auch noch nicht. Bin jetzt erstmal paar stunden nicht da ... 

[DS_Starter]

Vllt kannst du mit innodb_force_recovery = 3 starten. Dann wäre die tab nicht read only und du könntest mit drop etc. Arbeiten.

[Frank_Huber]

So,

mit Rescovery=3 ist er immer nach paar Sekunden gecrasht.
Nach einigen Versuchen hab ich es aber geschafft zwischen start und crash die Tabelle zu droppen.
Neu angelegt der Tabelle und des Index anhand der Zeilen aus dem Contrib.
Jetzt läuft der Restore.

Hab vor dem Restore noch nen dump gemacht.
Mal schauen ob ich da noch ein paar Zeilen retten kann.

kurz zum restore, überschreibt der "alles" oder fügt er hinzu?

[DS_Starter]

Dieser Restoretyp aus dem serverside Backup fügt hinzu, wobei Duplikate vermieden werden sofern ein primary Key gesetzt ist. Bei dir war die Tabelle jetzt leer, also nicht so relevant.
Was macht dein cache vom DbLog ? Im Reading cacheUsage dürften schon allerhand drinstehen. Setz dir dort auch noch das Attr bulkInsert 1. Das ist für die Performance wenn nachher die ganzen Events in die DB sollen.

BTW... wenn du in einem ANDEREN DbRep Device ein get ... procinfo ausführst, solltest du den restore und den Fortschritt sehen.

[Frank_Huber]

Die gecachten Ereignisse sind sauber übertragen worden. Das waren je nach Instanz glaub zwischen 1000 und 8000.

Der Restore lief auch sauber durch.

Dann kuck icjh jetzt mal nach dem primary key, falls der da ist kann ich ja den dump vor dem drop restoren,
dadurch müssten ja alle Einträge von gestern nach dem nächtlichen backup bis zum crash nachgezogen werden.

Das mit dem procinfo während dem restore schau ich mir an, das klingt interessant.

[DS_Starter]

Die indexe zeigt dir dbrep mit set ... index list_all an.
wenn der PK nicht da ist, wäre es auch nicht dramatisch. dbrep mit delDoublets bereinigt das wieder. Dauert halt alles etwas.

Aber jetzt vllt. zuerst einen neuen Dump ziehen 

[Frank_Huber]

Aber jetzt vllt. zuerst einen neuen Dump ziehen 

Das war das erste nach dem Restore.

den PK anlegen hat er mir schon verweigert wegen der doubletten.
Werd also erstmal den DelDoubl laufen lassen.