---

Hej,
Jeg er ved at lave en procedure til et dump af en produktions server
(Windows2003server + 4.0.22)

Jeg har fået mysqldump til nogenlunde at makke ret, men jeg mangler en eller
anden log, for at kunne se om det gik skidt eller godt.

jeg har prøvet med --verbose og den skriver da rigtigtnok noget info til
konsollen, men " > fil.log" virker ikke.

jeg har prøvet med --debug som skrevet i afsnit 8.8 på mysql.com men mangler
en forklaring på:
"The debug_options string often is 'd:t:o,file_name'"
Hvad betyder d:t:o ??? og skriver den kun hvis det gik skidt??

Har i andre ideer til hvordan jeg kan overvåge om dump'et gik godt?
(Uden at jeg skal sidde med programmet hver søndag aften og vente på at den
får spyttet ca 3.8GB ud...)

mvh
Jesper

---

On Tue, 1 Feb 2005 22:40:23 +0100, "Jesper" <jesper_eva@mail.ko.dk>
wrote:

>Hej,
>Jeg er ved at lave en procedure til et dump af en produktions server
>(Windows2003server + 4.0.22)
>
>Jeg har fået mysqldump til nogenlunde at makke ret, men jeg mangler en eller
>anden log, for at kunne se om det gik skidt eller godt.
>
>jeg har prøvet med --debug som skrevet i afsnit 8.8 på mysql.com men mangler
>en forklaring på:
>"The debug_options string often is 'd:t:o,file_name'"
>Hvad betyder d:t:o ??? og skriver den kun hvis det gik skidt??
>
>Har i andre ideer til hvordan jeg kan overvåge om dump'et gik godt?
>(Uden at jeg skal sidde med programmet hver søndag aften og vente på at den
>får spyttet ca 3.8GB ud...)

Jeg lavede engang to meget små (quick and dirty) til at lave det, men
har slettet dem. Det var på en linux version

Selve dumpet blev lavet i msd.sh (hvor også der blev navngivet via
dato).

Dette script blev kaldt via cron (scheduler i Windows), og skrev til
en log fil.

Så ca. sådan ud.

msd.sh:
..
mysqldump -v -u username -p password > dump.sql
..
..

shell.sh:
..
../msd.sh >> msd.log 2>&1
..
..

Du kan selvfølgelig også checke på errorcodes som i en hvilken som
helst batch fil.
Løsningen er altså at lave en .bat fil der kan dumpe og lave fejlcheke
bagefter.

/Anders

---

<snip>
>
> Selve dumpet blev lavet i msd.sh (hvor også der blev navngivet via
> dato).
>
> Dette script blev kaldt via cron (scheduler i Windows), og skrev til
> en log fil.
>
> Så ca. sådan ud.
>
> msd.sh:
> mysqldump -v -u username -p password > dump.sql
>
Dejligt simpelt -Jeg er kommet frem til at bruge:
c:\mysql\bin\mysqldump -u[bruger] -p[pw] -P3306 --all-databases --delete-mas
ter-logs --opt --quote-names --result-file="d:\backup\mysql3306\3306_dump.sq
l"

>
> shell.sh:
> ./msd.sh >> msd.log 2>&1
> .
Det var jo det jeg ikke kunne få windows udgaven til.
Det lader til at output bliver skrevet til console og ikke til stdout
Jeg kan ikke få re-diregeret output til en fil.

/jesper

---

Jesper wrote:
> Hej,
> Jeg er ved at lave en procedure til et dump af en produktions server
> (Windows2003server + 4.0.22)
>
> Jeg har fået mysqldump til nogenlunde at makke ret, men jeg mangler en eller
> anden log, for at kunne se om det gik skidt eller godt.
>
> jeg har prøvet med --verbose og den skriver da rigtigtnok noget info til
> konsollen, men " > fil.log" virker ikke.

Output er til stderr. " 2> fil.log"

> jeg har prøvet med --debug som skrevet i afsnit 8.8 på mysql.com men mangler
> en forklaring på:
> "The debug_options string often is 'd:t:o,file_name'"
> Hvad betyder d:t:o ??? og skriver den kun hvis det gik skidt??

Tror ikke det er noget du skal bekymre dig om. De nævner et andet sted
at output er en trace-fil, så det er nok til når det står rigtigt skidt
til, og programmørerne hos mysql skal have noget at kigge på.

> Har i andre ideer til hvordan jeg kan overvåge om dump'et gik godt?
> (Uden at jeg skal sidde med programmet hver søndag aften og vente på at den
> får spyttet ca 3.8GB ud...)

Har du overvejet at lave en kold backup. Hvis du bruger MyISAM til nogle
tabeller garanterer mysqldump ikke en konsistent backup, hvis der
samtidig er tilsluttede klienter som "piller".


/Bent