Hallo Leute,
Letzte Woche hat mein Serverchen den Geist aufgegeben.(Mein Fehler)
Allerdings ist mir dabvei was aufgefallen:
Ich starte jeden Tag einen Cronetab, welcher mir ein Script ausführt um
den
MySQL Server zu sichern.
Das hat er auch versucht, allerdings war der MySQLServer down.
Er hat zwar ein Archiv erstellt, die SQL Datei darin hat aber eine
Grösse von 0 byte.
Leider komme ich da aber an keinen Fehlercode dran.
Muss ich als erstes einen Dump ausführen und danach erst das Archiv
erstellen?
mfG
FFFF
Scriptauszug:
LogDate=$(date "+%A %d.%m.%Y %H:%M:%S")
FileDate=$(date "+%Y_%m_%d_%H_%M")
echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz"
echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz"
>>$Folder$LogFileName
sudo /usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases
| pigz --best > $Folder$Filename$FileDate'.gz'
LogDate=$(date "+%A %d.%m.%Y %H:%M:%S")
if [ $? -ne 0 ]; then
echo "$LogDate : Error creating SQL Stream" >>$Folder$LogFileName
echo "$LogDate : Error creating SQL Stream"
else
echo "$LogDate : SQL Dump OK" >>$Folder$LogFileName
echo "$LogDate : SQL Dump OK"
fi
$? enthält den returnwert des date befehls
hallo, der erste ansatz waere ein "set -x" im bash script, um zu sehen ob alle variablen sauber im mysqldump call erscheinen. danach mal ohne pigz arbeiten und in eine normale datei schreiben. ich vermute das der dump ansich schon nichts ausgibt, sondern ein fehler kommt. HTH, -- randy
Ich würde zur Sicherheit immer noch mal schauen was im dem Zip gelandet ist. Im einfachsten fall reicht schon die Größe zu prüfen, es sollen z.b. nicht mehr als 10% zum letzten backup abweichen. Oder die Zeit messen wenn das Backup nur 10 Sekunden braucht, stimmt etwas nicht.
Bei mysqldump, warum musst du den ganzen Pfad angeben, und warum setzt du ein sudo davor? Sudo könnte fehlschlagen, oder das Passwort von mysqldump. Tipp, dashier:
1 | sudo /usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases | pigz --best > $Folder$Filename$FileDate'.gz' |
2 | LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") |
3 | if [ $? -ne 0 ]; then |
Würde ich so schreiben: (Gegebenenfalls muss man PATH setzen)
1 | LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") |
2 | if ! mysqldump -u$User -p$Password --all-databases \ |
3 | | pigz --best > "$Folder$Filename$FileDate.gz" |
4 | then |
Daniel A. schrieb: > LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") > if ! mysqldump -u$User -p$Password --all-databases \ > | pigz --best > "$Folder$Filename$FileDate.gz" > then Aktueller Code: if ! mysqldump -u$User -p$Password --all-databases \ | pigz --best > "$Folder$Filename$FileDate.gz" then LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") echo "$LogDate : Error creating SQL Stream" >>$Folder$LogFileName echo "$LogDate : Error creating SQL Stream" else LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") echo "$LogDate : SQL Dump OK" >>$Folder$LogFileName echo "$LogDate : SQL Dump OK" fi Ausgabe aber leider: /usr/local/sbin/MySQLBackup.sh: Zeile 43: mysqldump: Kommando nicht gefunden. Mittwoch 10.08.2016 08:26:36 : SQL Dump OK Zeile 43: if ! mysqldump -u$User -p$Password --all-databases \
Dann wirst du wohl den kompletten Pfad angeben müssen. which mysqldump gibt dir vielleicht einen. Oder aber: Daniel A. schrieb: > (Gegebenenfalls muss man PATH setzen)
Sod.Pfad ist angegeben. Dump funktioniert. Habe nun den Server gestoppt. Resultat: mysqldump: Got error: 2002: Can't connect to local MySQL server through socket '/usr/local/mysql4/var/mysqld.sock' (2) when trying to connect Mittwoch 10.08.2016 08:46:00 : SQL Dump OK Also so funktioniert es auch nicht :-(
FFFF schrieb: > if ! mysqldump -u$User -p$Password --all-databases \ mysqldump -u $User -p"$Password" --all-databases Das manual ist dein Freund.
Nochmals, das Problem, um was es geht: FFFF schrieb: > Hallo Leute, > > Letzte Woche hat mein Serverchen den Geist aufgegeben.(Mein Fehler) > Allerdings ist mir dabvei was aufgefallen: > Ich starte jeden Tag einen Cronetab, welcher mir ein Script ausführt um > den > MySQL Server zu sichern. > Das hat er auch versucht, allerdings war der MySQLServer down. > Er hat zwar ein Archiv erstellt, die SQL Datei darin hat aber eine > Grösse von 0 byte. > Leider komme ich da aber an keinen Fehlercode dran. Das MySQLDumping funktioniert. Wenn was schief geht, wird eine GZ Datei ohne Inhalt erstellt. In der Logfile wird immer "SQLDump OK" eingetragen, obwohl ein Fehler auftritt. Nicht nur "Das Manual lesen"
Schau dir mal den zweiten beitrag hier im thread an. Dort steht das problem wieso sowas immlog steht. Dein log schreibt nämlich nur müll
FFFF schrieb: > Das MySQLDumping funktioniert. Das funktioniert erst, und erst dann kannst du nach weiteren Problemen suchen, wenn dein mysqldump-"Befehl" auf der Bash funktioniert. Das hier: if ! mysqldump -u$User -p$Password --all-databases \ | pigz --best > "$Folder$Filename$FileDate.gz" Gibt doch auch nur wieder das Ergebnis von pigz zurück. Und das wird nicht fehlschlagen.
:
Bearbeitet durch User
Mein code sieht nun wie folgt aus:
LogDate=$(date "+%A %d.%m.%Y %H:%M:%S")
FileDate=$(date "+%Y_%m_%d_%H_%M")
echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz"
echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz"
>>$Folder$LogFileName
if ! /usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases
| pigz --best > "$Folder$Filename$FileDate.gz"
then
LogDate=$(date "+%A %d.%m.%Y %H:%M:%S")
echo "$LogDate : Error creating SQL Stream" >>$Folder$LogFileName
echo "$LogDate : Error creating SQL Stream"
else
LogDate=$(date "+%A %d.%m.%Y %H:%M:%S")
echo "$LogDate : SQL Dump OK" >>$Folder$LogFileName
echo "$LogDate : SQL Dump OK"
fi
Was stimmt nun?
Die Lösung von Daniel Abrecht?
Mach mal
1 | mysqldump -u$User -p$Password --all-databases \ |
2 | | pigz --best > "$Folder$Filename$FileDate.gz" |
3 | if [[ ${PIPESTATUS[0]} -gt 0 ]]
|
4 | then |
5 | ... |
http://stackoverflow.com/questions/1221833/bash-pipe-output-and-capture-exit-status BTW: Falls du genug Ram frei hast, empfehle ich lrzip.
FFFF schrieb: > /usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases Geht dieser Teil denn ohne das restliche drumherum? Die If-Abfrage wird nicht gehen, hatte ich zwei Beiträge weiter oben geschrieben. FFFF schrieb: > Was stimmt nun? > Die Lösung von Daniel Abrecht? Viele Wege führen nach Rom.
:
Bearbeitet durch User
/usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases \
| pigz --best > "$Folder$Filename$FileDate.gz"
if [[ ${PIPESTATUS[0]} -gt 0 ]]
then
Funktioniert. Dankeschön :-D
FFFF schrieb: > Scriptauszug: > LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") > FileDate=$(date "+%Y_%m_%d_%H_%M") > echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz" > echo "$LogDate : Create MySQL dump under: $Folder$Filename$FileDate.gz" >>>$Folder$LogFileName > sudo /usr/local/mysql4/bin/mysqldump -u$User -p$Password --all-databases > | pigz --best > $Folder$Filename$FileDate'.gz' > LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") > if [ $? -ne 0 ]; then > echo "$LogDate : Error creating SQL Stream" >>$Folder$LogFileName > echo "$LogDate : Error creating SQL Stream" > else > echo "$LogDate : SQL Dump OK" >>$Folder$LogFileName > echo "$LogDate : SQL Dump OK" > fi "sudo mysqldump" ergibt keinen Sinn -- schon gar nicht, wenn mysqldump sich ohnehin mit Username und Passwort am MySQL-Server anmeldet. Vermutlich ist das sudo hier auch das Problem, das erwartet nämlich normalerweise eine interaktive Paßworteingabe, wenn Du es nicht explizit mit der "NOPASSWD"-Option eingerichtet hast. Durch die Verwendung der Shell Redirection wird dann zwar eine leere Datei angelegt, aber sudo wartet dann ewig auf die Eingabe eines Paßwortes, ruft daher mysqldump gar nicht auf und dieses liefert dann keine Daten an pigz... Außerdem würde ich das wiederholte "$Folder$Filename$FileDate" sowie "$Folder$LogFileName" einfach eigenen Variablen zuweisen und dann diese benutzen. Es mehrmals zu konstruieren ist unelegant und fehleranfällig. Schon die zweimalige Zuweisung an "LogDate" ist unschön und obendrein fehlerhaft: dadurch kommen Leerzeichen in Deine Dateinamen, die darum gequotet ("") werden müßten. (Wobei ich grundsätzlich von der Nutzung von Leerzeichen in Dateinamen abrate, weil diese bei Shelltools immer wieder zu fehleranfälligen Verrenkungen führen.) Expandier das einfach mal: aus
1 | LogDate=$(date "+%A %d.%m.%Y %H:%M:%S") |
2 | echo "a" > ${LogDate}
|
führt zu:
1 | echo "a" > Mittwoch 10.08.2016 09:57:40 |
Das ist vermutlich nicht das, was Du willst. (Ansonsten rate ich eher dazu, Sekunden seit Epoch zu benutzen (date +"%s") oder wenigsten ein ISO-Datum (date -Iseconds).) Weiterhin würde ich die Logmeldungen nicht in separate Dateien, sondern über logger(1) ins Syslog schreiben. Da gehören solche Logdaten nämlich hin (nicht umsonst haben UNIX-Systeme ein sehr umfangreiches, zentrales Logging), schon alleine damit klassische Logmonitore wie logcheck oder "richtige" Monitoringlösungen wie Icinga oder Zabbix das sehen können. Im Übrigen ist der Rückgabewert eines erfolgreichen Shellkommandos in der Regel NICHT 0, sondern 1 -- das dürfte auch für mysqldump gelten. Zudem bist Du Dir hoffentlich darüber im Klaren, daß Du nicht den Rückgabewert von mysqldump, sondern den von pigz überprüfst.
> Im Übrigen ist der Rückgabewert eines erfolgreichen Shellkommandos in > der Regel NICHT 0, sondern 1 Unfug.
Sheeva P. schrieb: > Im Übrigen ist der Rückgabewert eines erfolgreichen Shellkommandos in > der Regel NICHT 0, sondern 1 -- das dürfte auch für mysqldump gelten. > Zudem bist Du Dir hoffentlich darüber im Klaren, daß Du nicht den > Rückgabewert von mysqldump, sondern den von pigz überprüfst. In welcher Welt lebst du? $ true ; echo $? 0 $ false ; echo $? 1
./. schrieb: >> Im Übrigen ist der Rückgabewert eines erfolgreichen Shellkommandos in >> der Regel NICHT 0, sondern 1 > > Unfug. Upsi, haste Recht. Memo to self: erst Kaffee, dann posten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.