Raspberry PI 3: MySQLDump versagt.Es wird kein Fehler zurückgegeben.

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

FFFF schrieb:
> if ! mysqldump -u$User -p$Password --all-databases \

mysqldump -u $User -p"$Password" --all-databases


Das manual ist dein Freund.

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.

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.

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.

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.