nicht angemeldet
Wer kann mir diesen Datenverlust erklären?
Hi,
vorhin rief ein Kunde an, der nur sehr sporadisch bis gar nicht mehr in seine DB kam.
*Ich habe das erst nicht nachvollziehen können, habe sogar einen Eintrag vorgenommen und diesen anschließend auf sein Vorhandensein kontrolliert.
Ich bin dann aber dennoch ein bischen am Ball geblieben und tatsächlich, der mysql-Dienst schien erst nur zu hinken und danach kam ich gar nicht mehr in irgendeine auf diesem Server liegende db.
Anruf beim Hoster, der mir versicherte, selber die mysql-dbs von mir ansprechen zu können. Ich konnte es weder über phpmyadmin, noch über 2 andere Scripte. Auch nicht über die Administrationsoberfläche des Hosters.
Der Supporter hat dann angeleiert, dass der mysql-Dienst rebootet wird und alles lief wieder wie gewohnt.
Allerdings war mein *Kontrolleintrag verschwunden und ist es auch jetzt noch.
Wie kann das sein? Hat dafür einer eine Erklärung?
Der Eintrag muß defakto in der DB gewesen sein, sonst hätte ich ihn dort nicht nochmal aufrufen können, um ihn zu kontrollieren.
Und nach reboot des mysql-Dienstes ist er weg.
Dankbar für Hinweise, John
-
Hi,
Allerdings war mein *Kontrolleintrag verschwunden und ist es auch jetzt noch.
Wie kann das sein? Hat dafür einer eine Erklärung?
Der Eintrag muß defakto in der DB gewesen sein, sonst hätte ich ihn dort nicht nochmal aufrufen können, um ihn zu kontrollieren.
Caching von Datem im RAM, bevor sie tatsächlich auf Platte geschrieben wurden?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Caching von Datem im RAM, bevor sie tatsächlich auf Platte geschrieben wurden?
Hi Chris,
hm... meinst'?
Gruß, John
-
-
Hello,
Der Supporter hat dann angeleiert, dass der mysql-Dienst rebootet wird und alles lief wieder wie gewohnt.
Wie hat er das denn gemacht? Hat er den MySQL-Server ordentlich heruntergefahren und dann wieder gestartet, oder hat er den Server-Prozess einfach abgewürgt?
Allerdings war mein *Kontrolleintrag verschwunden und ist es auch jetzt noch.
Wie kann das sein? Hat dafür einer eine Erklärung?
Der Eintrag muß defakto in der DB gewesen sein, sonst hätte ich ihn dort nicht nochmal aufrufen können, um ihn zu kontrollieren.
Daten des Servers müssen erst persistent gemacht werden, bevor man den Server "abschaltet". Beim ordentlichen Herunterfahren übernimmt dies der Server automatisch.
Aber mal zur Information: Welches MySQL wird denn benutzt? Hast Du mal eine version()-Abfrage gemacht?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Wie hat er das denn gemacht? Hat er den MySQL-Server ordentlich heruntergefahren und dann wieder gestartet, oder hat er den Server-Prozess einfach abgewürgt?
Keine Ahnung. Aber der Eintrag des später verlorene Eintrags war auch schon sicher 15 Minuten vergangen...
Gruß, John
-
Wie hat er das denn gemacht? Hat er den MySQL-Server ordentlich heruntergefahren und dann wieder gestartet, oder hat er den Server-Prozess einfach abgewürgt?
Allerdings war mein *Kontrolleintrag verschwunden und ist es auch jetzt noch.
Wie kann das sein? Hat dafür einer eine Erklärung?
Der Eintrag muß defakto in der DB gewesen sein, sonst hätte ich ihn dort nicht nochmal aufrufen können, um ihn zu kontrollieren.
Daten des Servers müssen erst persistent gemacht werden, bevor man den Server "abschaltet". Beim ordentlichen Herunterfahren übernimmt dies der Server automatisch.
Du scheinst den Nagel auf den Kopf getroffen zu haben:
...
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110524 17:29:01 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
...Ätzend, sowas!
-
Hello,
Wie hat er das denn gemacht? Hat er den MySQL-Server ordentlich heruntergefahren und dann wieder gestartet, oder hat er den Server-Prozess einfach abgewürgt?
Allerdings war mein *Kontrolleintrag verschwunden und ist es auch jetzt noch.
Wie kann das sein? Hat dafür einer eine Erklärung?
Der Eintrag muß defakto in der DB gewesen sein, sonst hätte ich ihn dort nicht nochmal aufrufen können, um ihn zu kontrollieren.
Daten des Servers müssen erst persistent gemacht werden, bevor man den Server "abschaltet". Beim ordentlichen Herunterfahren übernimmt dies der Server automatisch.
Du scheinst den Nagel auf den Kopf getroffen zu haben:
...
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110524 17:29:01 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
...Ätzend, sowas!
Ja, schlimm, wenn es aus Dummheit und nicht aus technischem Problem heraus passiert.
Das wirst Du den Provider zwar (höflich) fragen können, damit es nicht nochmal passiert, aber kaum beweisen können.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi Tom,
Ätzend, sowas!
Absolut! Und das bei einer DB im Produktivbetrieb! Da helfen auch noch so viele Backups nicht mehr. Wenn eine DB hierdurch dann Inkonsistenzen aufweist, hast Du wirklich die "goldene Zitrone" gewonnen!
Das Schlimme: Ich habs nun so weit wie möglich kontrolliert, aber die Unsicherheit bleibt.
Und was noch schlimmer ist: Das jemand im 1.Level-Support anscheinend die fachliche Kompetenz hierzu nicht aufweist, aber dazu legitimiert ist.
Das Ganze fand auch noch auf einem Virtuellen Server statt, d.h. das es möglicherweise nun "weitere "Leidensgenossen" gibt, die noch gar nichts von ihrem Glück wissen!Das wirst Du den Provider zwar (höflich) fragen können, damit es nicht nochmal passiert, aber kaum beweisen können.
Habe ich bereits genau so gemacht.
Ich frage mich aber eh, ob die mich für dumm verkaufen wollen. Es muß doch der Technik auch ein Protokoll sämtlicher vom 1st-Level-Support gemachten Dinge vorliegen. Stattdessen wird salamischeibenmäßig genau das zugegeben, was ich selber vorher schon herausgefunden habe.Ich werde wohl den Provider nach diesem Vorfall wechseln und einen entsprechenden Beitrag bei webhostlist verfassen müssen.
Traurige Sache, das.
Grüße, John
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-