Datenverlust durch Absturz

konabi

Active Member
Dec 14, 2013
108
4
38
Hallo,
wir betreiben zwei Proxmox Nodes /Version 4.4-13) im Rechenzentrum. Als Storage kommt ein ISCSI Storage zum Einsatz. Angebunden ist der Storage über Multipath mit 4 Netzwerkkarten, jeweils 2 Netzwerkkarten an zwei verschiedenen Switchen. Der ISCSI Storage ist auch gespielgelt.
Auf dem Storage ist ein LVM. Alle VMs sind auf den Shared ISCSI Storage als LV abgelegt.

Beide Nodes sind als Cluster ohne HA mit Expected votes = 2 konfiguriert. Der Cluster wird später auf 3 Nodes erweitert so wie gefordert. Da ich kein HA verwende kann im Ausfall auch keine Splitbrain Situation entstehen.


Code:
Quorum information
------------------
Date:             Tue Dec 12 18:15:11 2017
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000001
Ring ID:          1/144
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           1
Flags:            2Node Quorate WaitForAll

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.1 (local)
0x00000002          1 10.10.10.2


Zu meinem Problem. Auf Grund eines Hardware Fehlers ist Node 1 ausgefallen (defekter Controller).
Der Fehler wurde behoben und der Server neu gestartet. Alle virtuellen Maschinen starten wie gewohnt.

Auf allen VMs laufen mySQL Server. Bei 4 der 9 VMs waren die Datenbanken defekt. Ich versuche nun nachzuvollziehen warum.
Mir ist klar daß so etwas im ungünstigsten Fall passieren kann, wenn Schreibvorgänge auf die Festplatte unvollständig sind. Aber mein ISCSI Storage auf welchem die VMs liegen war von dem Defekt nicht betroffen.

Die Festplatten der VMs sind mit der Option "No cache" konfiguriert. Das heißt der Host Page Cache wird nicht verwendet. "Das System informiert das Gastsystem über einen vollständigen Schreibvorgang wenn jeder Block in der Schreibwarteschlage des Storage Systems ist." also in der Schreibwarteschlange meines ISCSI Storage.

"Setting the Cache mode of the hard drive will impact how the host system will notify the guest systems of block write completions. The No cache default means that the guest system will be notified that a write is complete when each block reaches the physical storage write queue, ignoring the host page cache. This provides a good balance between safety and speed."

Unser Auftraggeber stellt nun unsere Virtualisierungslösung und Datensicherheit in Frage.
Deshalb meine Frage gibt es eine Sache die ich bei der Konfiguration eventuell übersehen oder falsch gemacht habe?

Ich bin für jeden Hinweis dankbar.
 
Was heißt genau die Datenbanken waren defekt?

Bei jedem Datenbankabsturz muss man mit Problemen rechnen. Was sagt MySQL was nicht passt?

Sind einzelne Tabellen kaputt oder die ganze Datenbank? Welche Storage Engine wird verwendet?

lg
Gregor
 
Verwendet wird mySQL INNODB. anbei ein Auszug aus dem LOG File:
Code:
171211  3:30:13  InnoDB: Page checksum 3574331667, prior-to-4.0.14-form checksum 1657422990
InnoDB: stored checksum 1163023104, prior-to-4.0.14-form stored checksum 131072
InnoDB: Page lsn 1348825709 1634624878, low 4 bytes of lsn at page end 0
InnoDB: Page number (if stored to page already) 55396673,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 162
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1434.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
171211  3:30:13  InnoDB: Error: space id and page n:o stored in the page
InnoDB: read in are 2684354599:2148016128, should be 3802:1435!
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1435.
InnoDB: You may have to recover from a backup.
171211  3:30:13  InnoDB: Page dump in ascii and hex (16384 bytes):

Ich habe gestern zur Sicherheit noch einmal cache=directsync. eingestellt:

host don't do cache.
guest disk cache mode is writethrough
similar to writethrough, a fsync is made for each write.

Danach habe ich die VMs heruntergefahren und neu gestartet.

Leider mußte ich heute feststellen daß wieder Datenbanken auf verschiedenen Systemen defekt waren.
Ich habe die Dateisysteme der VMs mit fsck geprüft. Alles OK.

Habe ich vieleicht ein anderes Problem kt den VMs? Gibt es Log Files die ich prüfen könnte?
 
Habe ich vieleicht ein anderes Problem kt den VMs? Gibt es Log Files die ich prüfen könnte?

Wenn das Gast-Dateisystem keine Fehler aufweist werden die Fehler wohl auf logischer Ebene von MySQL geschrieben.

Hast du schon mittels check table (wie oben gewünscht) rausgefunden, welche Tabellen und somit welche Dateien betroffen sind?
 
/usr/bin/mysqlcheck --auto-repair --check --all-databases

Code:
mf_f.tberatung
Error    : Table 'mf_f.tberatung' doesn't exist
status   : Operation failed
mf_f.tmitgliedschaft
Error    : Table 'mf_f.tmitgliedschaft' doesn't exist
status   : Operation failed
mf_f.tmitgliedskonto_buch
Error    : Table 'mf_f.tmitgliedskonto_buch' doesn't exist
status   : Operation failed
mf_f.tmitgliedskonto_pos
Error    : Table 'mf_f.tmitgliedskonto_pos' doesn't exist
status   : Operation failed
mf_f.tperson
Error    : Table 'mf_f.tperson' doesn't exist
status   : Operation failed
mf_f.tprotokoll_alt
Error    : Table 'mf_f.tprotokoll_alt' doesn't exist
status   : Operation failed
mf_m.dwapplfields
Error    : Table 'mf_m.dwapplfields' doesn't exist
status   : Operation failed
mf_m.dwfields
Error    : Table 'mf_m.dwfields' doesn't exist
status   : Operation failed
mf_m.dwpictures
Error    : Table 'mf_m.dwpictures' doesn't exist
status   : Operation failed
 
Funktioniert die MySQL Instanz überhaupt noch?

Also kann man sich an der Datenbank anmelden?

Ich würde mal anfangen mit InnoDB one File per Table. Damit crashen nicht gleich mehrere Tables. Dies hilft auf jeden Fall bei einem Recovery der Datenbank.

Wie groß ist die Datenbank überhaupt? Bei einem Crash muss man leider mit Problemen bei InnoDB rechnen.

Du kannst auf jeden Fall versuchen mit innodb_force_recovery 1..6 zu arbeiten. Damit sollte man die Daten aus der Datenbank bekommen. Kommt aber immer drauf an wieviel kaputt gegangen ist.

Soviel ich sehe wird hier eine recht alte MySQL Version verwendet. 5.5 würde ich nicht mehr für den produktiven Einsatz verwenden.

Wie wäre es eigentlich das ganze mit Master Slave oder Master-Master Replication zu lösen. Damit sollte eine Instanz immer einen lesbaren Datenbestand haben.

Von welchem Hersteller ist das Storage?

lg
Gregor
 
Hallo Gregor,
danke für Deine Hilfe soweit.
ich konnte jetzt ein Dump der Datenbank mit Hilfe von "innodb_force_recovery 4" erstellen und weider neu einspielen.
Ich selber hoste nur die virtuellen Maschinen als Diensteleistung. Auf die verwendete Software in den VMs mysqlserver usw. habe ich keinen Einfluss, aber ich werde es mal als Hinweis weitergeben.
Den Storage Hersteller müsste ich mal im Rechenzentrum erfragen.

Viele Grüße
Sven
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!