nach Datenbank-Restore geht nichts mehr

[steffi]

hallo

mit mysqlbackup habe ich die datenbank gesichert. danach habe ich versuchsweise änderungen an der datenbank vorgenommen. im anchsluss wollte ich die datenbank restoren.

nun erhalte ich beim zugriff auf meine foren folgende meldung:

SQL ERROR [ mysqli ]

Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) [2002]

An sql error occurred while fetching this page. Please contact an administrator if this problem persists.

beim zugriff auf die datenbank direkt kommt folgende meldung:

#2002 - Der Server antwortet nicht. (evtl. ist auch der Socket des lokalen MySQL-Servers socket nicht korrekt konfiguriert)

puuuuh, was ist hier los? kann mir jemand helfen

 

[steffi]

erledigt.

ursache nicht bekannt.

lösung: firmware neu aufspielen

 

[Trolli]

Wie hattest Du denn die Datenbank wiederhergestellt?

 

[steffi]

durch drücken des buttons "Restore"

erst ein backup erstellt, dann änderungen an der datanbank vorgenommen. dann restore und schwubs kam die fehlermeldung

 

[Trolli]

Kannst Du vielleicht noch mal genau sagen, um welches Programm es sich handelt, mysqlbackup kann ich nämlich nicht finden...

 

[steffi]

das hier mysqlbackup von itari

 

[Trolli]

Aah - sorry. Ich stand wohl etwas auf dem Schlauch... Ich dachte, Du hättest ein externes Programm wie phpmyBackup verwendet.

 

[itari]

Bei mir läuft der Restore gut durch (hab ich an anderer Stelle schon geschrieben). Allerdings scheint es so, als würde zwischen meiner Firmware (721) und den allgemein Üblichen eine Differenz hinsichtlich der Datenbank-Datei-Verzeichnisse bestehen. Bei mit ist im Verzeichnis /volume1/@database nur ein Unterverzeichnis mysql.

Das Problem, was vermutlich zu der Störung geführt hat, ist, dass beim Restore kein Datenbank-Server (mysqld) aktiv sein darf. Ich fahre zwar im Skript die Datenbank mit /usr/syno/etc/rc.d/S21mysql stop herunter und warte ein paar Sekunden bevor ich mit dem Zurückkopieren anfange, aber es kann natürlich sein, dass die Datenbank länger bracht oder aus irgendeinem Grunde Probleme mit dem Stoppen hat.

Das ist eine Vermutung - keine Gewissheit.

itari

 

[jahlives]

Ich fahre zwar im Skript die Datenbank mit /usr/syno/etc/rc.d/S21mysql stop herunter und warte ein paar Sekunden bevor ich mit dem Zurückkopieren anfange, aber es kann natürlich sein, dass die Datenbank länger bracht oder aus irgendeinem Grunde Probleme mit dem Stoppen hat.

Geht doch mit einer Schleife wesentlich zuverlässiger. Nach dem Motto durchlaufe die Schleife solange wie mysql noch eine PID hat (pidof). Sollte noch eine PID vorhanden sein, dann einfach eine Sekunde schlafen legen und den nächsten Schleifendurchlauf starten. Wenn keine PID mehr vorhanden ist kann ja eigentlich auch kein Daemon mehr laufen. Oder liege ich da falsch?
Das brauche ich z.B. wenn ich die Mailbox meines Dovecot Server backupen will. Da muss ich ja auch zuerst prüfen ob das Script zum Abholen externer Mails noch läuft und das funzt mit pidof sehr zuverlässig. Sobald das Script nicht mehr läuft kann ich den Mailserver runternehmen, das Backup starten und nach Abschlusss Dovecot wieder anwerfen.

 

[itari]

Also es gibt ja immer mehrere Inkarnationen des mysqld und auch möglicherweise mehrere mysql-Server (standard und ipkg), da ist es mit dem pidof nicht ganz so einfach, aber man könnte die pid-file (/tmp/mysqld.pid) abfragen, so ginge schon.

Wie gesagt, es ist ja auch erstmal ein Vermutung, dass das Problem daher kommt, dass noch ein DS-Server aktiv ist. Normalerweise würde der Server ja auch die Files sperren (lock) gegen Überschreiben, aber das File-Locking ist ja nicht gerade auf der DS sehr ausgeprägt

Aber wie auch schon in anderen Post zu diesem Thema gesagt, überlege ich mir eine Lösung, "alles" zu sichern und restoren in einem allgemeinen Skript. Ich denke da an eine Simulation des init s, so dass keine daemonen mehr laufen und auch die Aktivitäten bis auf das File-System down sind. In diesem Zustand könnte man auch vorher bzw. nachher (beim restore) einen fsck fahren ...

itari

 

[steffi]

hallo

ich vermute auch einen bedienerfehler. ich bin davon ausgegangen, dass die telnet befehle zum stoppen und starten der datenbank in der anwendung enthalten sind. da dies nicht der fall ist, liegt da vermutlich der fehler. ich selber habe die datenbank (in diesem fall müsste es ja mehr als nur die sql datenbank sein -- es wird ja auch mehr gesichert!) nicht händisch gestoppt.