6
MYSQL abgeschmiert
Hallo zusammen,
mein Windows Server mit Mysql ist komplett abgeschmiert. Der Service startet nicht mehr.
Habe die aktuelle Version von Mysl schon drüber installiert, hat auch nichts geholfen.
Ich habe wöchentliche die Datenbanken der Datenbank gesichert.
Sprich alles was unter C:\ProgramData\MySQL\MySQL Server. 5.5\data liegt.
Was kann ich damit anfangen?
Ich hatte von 20 Webseiten jeweils die aktuelle Sicherung inkl. .sql Datei da nur eben für eine nicht.
Bzw. bekomme ich eine Fehlermeldung wenn ich diese importieren möchte.
Hat jemand eine Idee?
Eckdaten:
Windows Server 2008 R2 aktueller Updatestand
MySQL 5.6.1
PHP 5
PhpMyAdmin in der aktuellen Version
IIS7
Danke euch
mein Windows Server mit Mysql ist komplett abgeschmiert. Der Service startet nicht mehr.
Habe die aktuelle Version von Mysl schon drüber installiert, hat auch nichts geholfen.
Ich habe wöchentliche die Datenbanken der Datenbank gesichert.
Sprich alles was unter C:\ProgramData\MySQL\MySQL Server. 5.5\data liegt.
Was kann ich damit anfangen?
Ich hatte von 20 Webseiten jeweils die aktuelle Sicherung inkl. .sql Datei da nur eben für eine nicht.
Bzw. bekomme ich eine Fehlermeldung wenn ich diese importieren möchte.
Hat jemand eine Idee?
Eckdaten:
Windows Server 2008 R2 aktueller Updatestand
MySQL 5.6.1
PHP 5
PhpMyAdmin in der aktuellen Version
IIS7
Danke euch
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 215164
Url: https://administrator.de/forum/mysql-abgeschmiert-215164.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
6 Kommentare
Neuester Kommentar
Zu aller erst schaut man mal in die Logdateien rein, warum der Server nicht starten will und dann versucht man das Problem zu beheben, ehe man an eine Rücksicherung geht. Ansonsten kann es passieren, dass du zeitnah wieder das Problem hast. Meist sind es nur Kleinigkeiten.
Ich musste vor kurzem bei einer anderen Datenbank eine Rücksicherung machen, weil die manuelle Behebung des Problems Tage gedauert hätte (defekter Datenbestand nach Programmfehler), deswegen wurde die Sicherung des gleichen Tages eingespielt und damit bewusst 5 Stunden Arbeit des Tages vernichtet. Selbst der Schaden kann schon als fünfstellig eingeschätzt werden. Daher Rücksicherungen immer nur dann, wenn der Reparaturaufwand den Betrieb zu lange aufhalten würde und der dabei entstehende Schaden verkraftbar wäre.
Bei der wöchentlichen Sicherung der Dateien ist die Frage, ob du vorher den Datenbankserver heruntergefahren (also den Dienst gestoppt) hast. Wenn nicht, sind die Datenbanken mit hoher Wahrscheinlichkeit nicht konsistent und damit möglicherweise unbrauchbar. Die Datenbanken kannst du nicht importieren, die musst du wieder in das entsprechende Verzeichnis ablegen.
Auf Dauer solltest du dich mal mit mysqldump und der Aufgabenplanung auseinandersetzen, um brauchbare Backups rauszubekommen.
Ich musste vor kurzem bei einer anderen Datenbank eine Rücksicherung machen, weil die manuelle Behebung des Problems Tage gedauert hätte (defekter Datenbestand nach Programmfehler), deswegen wurde die Sicherung des gleichen Tages eingespielt und damit bewusst 5 Stunden Arbeit des Tages vernichtet. Selbst der Schaden kann schon als fünfstellig eingeschätzt werden. Daher Rücksicherungen immer nur dann, wenn der Reparaturaufwand den Betrieb zu lange aufhalten würde und der dabei entstehende Schaden verkraftbar wäre.
Bei der wöchentlichen Sicherung der Dateien ist die Frage, ob du vorher den Datenbankserver heruntergefahren (also den Dienst gestoppt) hast. Wenn nicht, sind die Datenbanken mit hoher Wahrscheinlichkeit nicht konsistent und damit möglicherweise unbrauchbar. Die Datenbanken kannst du nicht importieren, die musst du wieder in das entsprechende Verzeichnis ablegen.
Auf Dauer solltest du dich mal mit mysqldump und der Aufgabenplanung auseinandersetzen, um brauchbare Backups rauszubekommen.
Hallo,
ich war sowieso dabei alle Kunden auf ein Ubuntu Plesk Panel zu migrieren, das habe ich ja zum Glück im Hintergrund schon bei fast allen Kunden gemacht.
Alle Kunden laufen jetzt auf dem Plesk Panel das wenigstens stabil läuft. Die Windows Kiste wollte ich sowieso abschalten.
Das Log File eventvwr.msc unter Windows Protokolle Anwendung sagt folgendes:
Name der fehlerhaften Anwendung: mysqld.exe, Version: 5.5.33.0, Zeitstempel: 0x51e3eb84
Name des fehlerhaften Moduls: mysqld.exe, Version: 5.5.33.0, Zeitstempel: 0x51e3eb84
Ausnahmecode: 0x80000003
Fehleroffset: 0x000000000021c8a2
ID des fehlerhaften Prozesses: 0x1168
Startzeit der fehlerhaften Anwendung: 0x01cea0d58826ff3f
Pfad der fehlerhaften Anwendung: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld.exe
Pfad des fehlerhaften Moduls: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld.exe
Berichtskennung: c9efaa58-0cc8-11e3-8994-000c29c99755
Damit lässt sich nicht viel anfangen, und nein bei der Sicherung habe ich die Datenbank nicht herunter gefahren.
ich war sowieso dabei alle Kunden auf ein Ubuntu Plesk Panel zu migrieren, das habe ich ja zum Glück im Hintergrund schon bei fast allen Kunden gemacht.
Alle Kunden laufen jetzt auf dem Plesk Panel das wenigstens stabil läuft. Die Windows Kiste wollte ich sowieso abschalten.
Das Log File eventvwr.msc unter Windows Protokolle Anwendung sagt folgendes:
Name der fehlerhaften Anwendung: mysqld.exe, Version: 5.5.33.0, Zeitstempel: 0x51e3eb84
Name des fehlerhaften Moduls: mysqld.exe, Version: 5.5.33.0, Zeitstempel: 0x51e3eb84
Ausnahmecode: 0x80000003
Fehleroffset: 0x000000000021c8a2
ID des fehlerhaften Prozesses: 0x1168
Startzeit der fehlerhaften Anwendung: 0x01cea0d58826ff3f
Pfad der fehlerhaften Anwendung: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld.exe
Pfad des fehlerhaften Moduls: C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld.exe
Berichtskennung: c9efaa58-0cc8-11e3-8994-000c29c99755
Damit lässt sich nicht viel anfangen, und nein bei der Sicherung habe ich die Datenbank nicht herunter gefahren.
Es gibt auch noch die Logdateien des MySQL-Servers, da wirst du den Grund oder einen Hinweis auf den Grund finden.
ich habe echt alles versucht diesen Log zu finden oder zu aktivieren.
Leider ohne Erfolg
Jemand eine Idee?
Leider ohne Erfolg
Jemand eine Idee?
Wenn Sie die Option --console weglassen, schreibt der Server die gesamte Diagnoseausgabe in das Fehlerlog im Datenverzeichnis (standardmäßig C:\Programme\MySQL\MySQL Server 5.1\data). Das Fehlerlog ist die Datei mit der Erweiterung .err.
Direkt im Verzeichnis /data gibt es keine Dateien nur zwei weitere Unterordner mit dem Namen "mysql" und "performance_shema".
Auch hier finden sich keine .err Dateien oder irgendwas mit LOG
Auch hier finden sich keine .err Dateien oder irgendwas mit LOG
