Discussion:
mysqldump risico?
(te oud om op te antwoorden)
houghi
2010-02-05 16:13:03 UTC
Permalink
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?

Natuurlijk wel lastig als die dan niet werkt en de server het nodig
heeft.

houghi
--
Maltho thi afrio lito.
Hans W
2010-02-05 18:13:47 UTC
Permalink
Post by houghi
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?
Natuurlijk wel lastig als die dan niet werkt en de server het nodig
heeft.
Voor backups heb je tegenwoordig betere tools die wel van een live
server kunnen backuppen. Mocht je die niet willen/kunnen inzetten dan
is het het beste om even de database server uit te zetten, zo verlies
je
geen gegevens.

Als alternatief kun je MySQL replicated opzetten en van de replicated
server daar dan een dump van maken terwijl die even uit staat.

Groet,

Hans
houghi
2010-02-06 10:49:56 UTC
Permalink
Post by Hans W
Post by houghi
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?
Natuurlijk wel lastig als die dan niet werkt en de server het nodig
heeft.
Voor backups heb je tegenwoordig betere tools die wel van een live
server kunnen backuppen.
Welke?
Post by Hans W
Mocht je die niet willen/kunnen inzetten dan
is het het beste om even de database server uit te zetten, zo verlies
je
geen gegevens.
OK. Iemand een URL met meer uitleg hierover om te zien hoe groot het
risico is.
Post by Hans W
Als alternatief kun je MySQL replicated opzetten en van de replicated
server daar dan een dump van maken terwijl die even uit staat.
Op dit moment nog even niet aan de orde. De mysql dump is een voorlopige
oplossing tot er een complete backup uitgewerkt is.

houghi
--
Maltho thi afrio lito.
Paul van der Vlis
2010-02-06 12:07:43 UTC
Permalink
Post by houghi
Post by Hans W
Post by houghi
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?
Natuurlijk wel lastig als die dan niet werkt en de server het nodig
heeft.
Voor backups heb je tegenwoordig betere tools die wel van een live
server kunnen backuppen.
Welke?
Je hebt iets wat mysqlhotcopy heet.
Post by houghi
Post by Hans W
Mocht je die niet willen/kunnen inzetten dan
is het het beste om even de database server uit te zetten, zo verlies
je geen gegevens.
OK. Iemand een URL met meer uitleg hierover om te zien hoe groot het
risico is.
Ik ken geen risico, volgens mij hoef je mysql niet uit te zetten als je
mysqldump gebruikt.

Wat ik wel weet is dat de hoeveelheid data soms te groot kan worden, dat
moet je in de gaten houden. Dit is te wijzigen in my.cnf.

Mochten er inderdaad risico's aan mysqldump zitten dan hoor ik dit
graag. Ik gebruik het ook voor mijn backups.

Misschien heeft iemand hier nog iets aan:
--------------
# script om alle mysql databases als apart bestand te dumpen

# Mysql root paswoord
password=`cat /path/naar/paswoord`

# Mysql DIR voor mysqldump
MDIR="/path/naar/mysqldumpdirectory"

if ! test -e $MDIR; then mkdir -p $MDIR; chmod 700 $MDIR; fi
cd $MDIR

lijst=`mysql -N -uroot -p"$password" <<EOD
show databases;
EOD`

for database in $lijst; do
echo -n $database
echo -n " "
mysqldump -QR -u root -p$password $database > $database.sql
done
# return:
echo
----------------

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Rob
2010-02-06 12:15:10 UTC
Permalink
Post by Paul van der Vlis
Ik ken geen risico, volgens mij hoef je mysql niet uit te zetten als je
mysqldump gebruikt.
Wat ik wel weet is dat de hoeveelheid data soms te groot kan worden, dat
moet je in de gaten houden. Dit is te wijzigen in my.cnf.
Mochten er inderdaad risico's aan mysqldump zitten dan hoor ik dit
graag. Ik gebruik het ook voor mijn backups.
Ik zie nergens staan dat de dump met een of andere snapshot faciliteit
gemaakt wordt. Dus als je een dump maakt van een database waar op dat
moment in gemuteerd wordt dan zou het kunnen dat hij een resultaat
produceert wat niet consistent is.
(bijvoorbeeld records die verwijzen naar andere records die niet in de
dump staan)

Of dat een probleem is en dus een risico dat zal er vanaf hangen wat
voor soort database je dumpt en hoe actief daarin gemuteerd wordt.

En het hangt ook af van de mysql versie. Hoe nieuwer de versie hoe meer
features er in zitten die iets met consistentie van doen hebben.
(oude versies kennen bijvoorbeeld helemaal geen foreign keys dus moet
je applicatie eventuele problemen met referentiele integriteit zelf al
kunnen afhandelen)
houghi
2010-02-06 14:12:22 UTC
Permalink
Ik heb ongeveer het zelfde.
Post by Paul van der Vlis
--------------
# script om alle mysql databases als apart bestand te dumpen
# Mysql root paswoord
password=`cat /path/naar/paswoord`
Ik doe het volgende:
. /path/naar/paswoord
In dat bestand staat dan
MYSQL_PW="PaswoordVoorMySQL"
Dat bestand is enkel leesbaar voor root.
Post by Paul van der Vlis
# Mysql DIR voor mysqldump
MDIR="/path/naar/mysqldumpdirectory"
if ! test -e $MDIR; then mkdir -p $MDIR; chmod 700 $MDIR; fi
cd $MDIR
lijst=`mysql -N -uroot -p"$password" <<EOD
show databases;
EOD`
for database in $lijst; do
Kun je het volgende niet gebruiken:
for database in `mysql -N -uroot -p"$password"` do

In ieder geval bedankt.

houghi
--
Maltho thi afrio lito.
Rob
2010-02-06 14:38:23 UTC
Permalink
Post by houghi
Post by Paul van der Vlis
lijst=`mysql -N -uroot -p"$password" <<EOD
show databases;
EOD`
for database in $lijst; do
for database in `mysql -N -uroot -p"$password"` do
Dan ontbreekt er nog: -e "show databases;"

En ik zou -B erbij zetten.
Kees Bakker
2010-02-09 11:05:32 UTC
Permalink
Post by Paul van der Vlis
--------------
# script om alle mysql databases als apart bestand te dumpen
# Mysql root paswoord
password=`cat /path/naar/paswoord`
# Mysql DIR voor mysqldump
MDIR="/path/naar/mysqldumpdirectory"
if ! test -e $MDIR; then mkdir -p $MDIR; chmod 700 $MDIR; fi
cd $MDIR
lijst=`mysql -N -uroot -p"$password" <<EOD
show databases;
EOD`
for database in $lijst; do
echo -n $database
echo -n " "
mysqldump -QR -u root -p$password $database > $database.sql
done
echo
----------------
Houd er wel rekening mee dat het password voor iedereen zichtbaar is
dmv "ps axwww". Als er meerdere gebruikers bij dit systeem kunnen,
dan zou ik liever met ~/.my.cnf werken.
--
Kees
houghi
2010-02-09 12:37:10 UTC
Permalink
Post by Kees Bakker
Houd er wel rekening mee dat het password voor iedereen zichtbaar is
dmv "ps axwww". Als er meerdere gebruikers bij dit systeem kunnen,
dan zou ik liever met ~/.my.cnf werken.
Dank hiervoor. Op dit moment is dat niet echt van toepassing. Alle (3)
users die kunnen inloggen hebben ook het root paswoord al. Ze kunnen dus
hoe dan ook al aan alles.

Maar het blijft natuurlijk wel een goed punt.

houghi
--
Maltho thi afrio lito.
Paul van der Vlis
2010-02-09 15:28:28 UTC
Permalink
Post by Kees Bakker
Post by Paul van der Vlis
--------------
# script om alle mysql databases als apart bestand te dumpen
# Mysql root paswoord
password=`cat /path/naar/paswoord`
# Mysql DIR voor mysqldump
MDIR="/path/naar/mysqldumpdirectory"
if ! test -e $MDIR; then mkdir -p $MDIR; chmod 700 $MDIR; fi
cd $MDIR
lijst=`mysql -N -uroot -p"$password" <<EOD
show databases;
EOD`
for database in $lijst; do
echo -n $database
echo -n " "
mysqldump -QR -u root -p$password $database > $database.sql
done
echo
----------------
Houd er wel rekening mee dat het password voor iedereen zichtbaar is
dmv "ps axwww".
Inderdaad, maar wel ca. 0,001 seconde (namelijk tot cat klaar is), en
dat midden in de nacht. Dus een groot risico lijkt het me niet...
Post by Kees Bakker
Als er meerdere gebruikers bij dit systeem kunnen,
dan zou ik liever met ~/.my.cnf werken.
Hmm, inderdaad wel een goed idee. Er kunnen dit soort dingen in:
---------
[client]
user = DBUSERNAME
password = DBPASSWORD
host = DBSERVER
----------

Verder alles wat in my.cnf staat, lees ik. Dus je kunt ook met andere
instellingen werken voor de backup.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Joost de Heer
2010-02-09 16:40:52 UTC
Permalink
Post by Paul van der Vlis
Post by Kees Bakker
mysqldump -QR -u root -p$password $database> $database.sql
Houd er wel rekening mee dat het password voor iedereen zichtbaar is
dmv "ps axwww".
Inderdaad, maar wel ca. 0,001 seconde (namelijk tot cat klaar is), en
dat midden in de nacht. Dus een groot risico lijkt het me niet...
Jouw database dump van hierboven is in 0.001 seconde klaar?

Joost
houghi
2010-02-09 16:59:13 UTC
Permalink
Post by Joost de Heer
Post by Paul van der Vlis
Inderdaad, maar wel ca. 0,001 seconde (namelijk tot cat klaar is), en
dat midden in de nacht. Dus een groot risico lijkt het me niet...
Jouw database dump van hierboven is in 0.001 seconde klaar?
LOL. Net even een test gedaan voor de leute. Kan zijn dat het ergens
anders sneller gaat:
***@intranet : time MySQLbackup
real 0m0.643s
user 0m0.286s
sys 0m0.038s

Dat zijn twee databases die ieder naar een bzip gepiped worden.


houghi
--
Maltho thi afrio lito.
Paul van der Vlis
2010-02-10 14:53:51 UTC
Permalink
Post by Joost de Heer
Post by Paul van der Vlis
Post by Kees Bakker
mysqldump -QR -u root -p$password $database> $database.sql
Houd er wel rekening mee dat het password voor iedereen zichtbaar is
dmv "ps axwww".
Inderdaad, maar wel ca. 0,001 seconde (namelijk tot cat klaar is), en
dat midden in de nacht. Dus een groot risico lijkt het me niet...
Jouw database dump van hierboven is in 0.001 seconde klaar?
Hmm, je hebt gelijk. Ook tijdens de dump is het zichtbaar.

Met vriendelijke groet,
Paul van der Vlis.
--
http://www.vandervlis.nl/
Hans W
2010-02-06 13:53:24 UTC
Permalink
Post by houghi
Post by Hans W
Post by houghi
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?
Natuurlijk wel lastig als die dan niet werkt en de server het nodig
heeft.
Voor backups heb je tegenwoordig betere tools die wel van een live
server kunnen backuppen.
Welke?
Post by Hans W
Mocht je die niet willen/kunnen inzetten dan
is het het beste om even de database server uit te zetten, zo verlies
je
geen gegevens.
OK. Iemand een URL met meer uitleg hierover om te zien hoe groot het
risico is.
Post by Hans W
Als alternatief kun je MySQL replicated opzetten en van de replicated
server daar dan een dump van maken terwijl die even uit staat.
Op dit moment nog even niet aan de orde. De mysql dump is een voorlopige
oplossing tot er een complete backup uitgewerkt is.
Iemand noemde al de hotcopy versie. Er zijn ook diverse
commerciele oplossingen die wel of niet op Linux draaien.
Een voorbeeld van die laatste groep is Ahsay. Dit is echter
meer een totale oplossing.

De nadelen van een live backup maken via een dump zijn
al aangegeven. Wil je dat netjes doen dan moet je eigenlijk
een read/write lock plaatsen (dus kun je net zo goed de
database even down brengen). Wel kun je een database
locken als je er meerdere hebt en die dan achter elkaar
wil backuppen. Vergeet dan niet dat je eigenlijk de tables
moet flushen en dan de read lock moet plaatsen. Is wel
te automatiseren.

Groet,

Hans
Rob
2010-02-06 14:03:14 UTC
Permalink
Post by Hans W
De nadelen van een live backup maken via een dump zijn
al aangegeven. Wil je dat netjes doen dan moet je eigenlijk
een read/write lock plaatsen (dus kun je net zo goed de
database even down brengen). Wel kun je een database
locken als je er meerdere hebt en die dan achter elkaar
wil backuppen. Vergeet dan niet dat je eigenlijk de tables
moet flushen en dan de read lock moet plaatsen. Is wel
te automatiseren.
Ja dat is nou net wat mysqlhotcopy doet...

Het is ook maar wat je met de backup wilt doen.
Een mysqldump kun je in principe ook in een andere database inlezen.
Als je nog iets met een hotcopy wilt na een totale systeem disaster dan
zul je weer een mysql op moeten brengen. En wieweet is er tegen die
tijd een incompatabiliteit, dus moet je dan eigenlijk dezelfde versie
nog hebben.

Afhankelijk van hoe je de database gebruikt kunnen allerlei simpele
methoden prima zijn, of er kan een probleem optreden. Hoe ernstig dat
probleem is dat hangt weer van je gebruik af. Een bank die transactie
integriteit eist zal andere eisen stellen dan een website waar de
database alleen door de webmaster gemuteerd wordt.
(en een toepassing met zware eisen zal meestal geen mysql gebruiken)
houghi
2010-02-06 14:16:38 UTC
Permalink
Post by Rob
Post by Hans W
De nadelen van een live backup maken via een dump zijn
al aangegeven. Wil je dat netjes doen dan moet je eigenlijk
een read/write lock plaatsen (dus kun je net zo goed de
database even down brengen). Wel kun je een database
locken als je er meerdere hebt en die dan achter elkaar
wil backuppen. Vergeet dan niet dat je eigenlijk de tables
moet flushen en dan de read lock moet plaatsen. Is wel
te automatiseren.
Ja dat is nou net wat mysqlhotcopy doet...
Bedank. Zal het eens bekijken.
Post by Rob
Het is ook maar wat je met de backup wilt doen.
Een mysqldump kun je in principe ook in een andere database inlezen.
Als je nog iets met een hotcopy wilt na een totale systeem disaster dan
zul je weer een mysql op moeten brengen. En wieweet is er tegen die
tijd een incompatabiliteit, dus moet je dan eigenlijk dezelfde versie
nog hebben.
Het een een backup in geval van een serieuze crash. Het systeem zal
identiek zijn.
Post by Rob
Afhankelijk van hoe je de database gebruikt kunnen allerlei simpele
methoden prima zijn, of er kan een probleem optreden. Hoe ernstig dat
probleem is dat hangt weer van je gebruik af. Een bank die transactie
integriteit eist zal andere eisen stellen dan een website waar de
database alleen door de webmaster gemuteerd wordt.
(en een toepassing met zware eisen zal meestal geen mysql gebruiken)
Niet al te zwaar, maar toch meer dan enkel de webmaster die zaken
aanpast. Ik verwacht wel niet enorm veel verkeer om 3:30, maar je weet
nooit dat een verdwaalde ziel nog aan het werk is en net op dat moment
bezig is met een aanpassing.

houghi
--
Maltho thi afrio lito.
Hans W
2010-02-06 19:59:42 UTC
Permalink
Post by Rob
Post by Hans W
De nadelen van een live backup maken via een dump zijn
al aangegeven. Wil je dat netjes doen dan moet je eigenlijk
een read/write lock plaatsen (dus kun je net zo goed de
database even down brengen). Wel kun je een database
locken als je er meerdere hebt en die dan achter elkaar
wil backuppen. Vergeet dan niet dat je eigenlijk de tables
moet flushen en dan de read lock moet plaatsen. Is wel
te automatiseren.
Ja dat is nou net wat mysqlhotcopy doet...
Dan heeft die oplossing eigenlijk een foute naam :-) Moet ook
eerlijk zeggen dat ik niet weet hoe de commerciele oplossingen
het doen. Verstandigste lijkt me nog steeds het repliceren en dan
op de slave een stop te doen, volledige dump, slave aan en weer
syncen.

Dat heeft overigens nog een groot voordeel. Als je een beetje
grote query cache hebt waarbij alleen bepaalde queries erin gezet
worden dan hoef je die niet opnieuw te vullen. Weet niet of die flush
de cache vern**kt. Idem voor thread en table caches.

Groet,

Hans
Rob
2010-02-07 10:09:48 UTC
Permalink
Post by Hans W
Post by Rob
Post by Hans W
De nadelen van een live backup maken via een dump zijn
al aangegeven. Wil je dat netjes doen dan moet je eigenlijk
een read/write lock plaatsen (dus kun je net zo goed de
database even down brengen). Wel kun je een database
locken als je er meerdere hebt en die dan achter elkaar
wil backuppen. Vergeet dan niet dat je eigenlijk de tables
moet flushen en dan de read lock moet plaatsen. Is wel
te automatiseren.
Ja dat is nou net wat mysqlhotcopy doet...
Dan heeft die oplossing eigenlijk een foute naam :-)
Dat zie je wel vaker ja.
Post by Hans W
Moet ook
eerlijk zeggen dat ik niet weet hoe de commerciele oplossingen
het doen. Verstandigste lijkt me nog steeds het repliceren en dan
op de slave een stop te doen, volledige dump, slave aan en weer
syncen.
Dit soort oplossingen kan ook binnen 1 systeem wel gedaan worden.
Er wordt dan een snapshot gemaakt, waarbij de database bevroren is
en updates in een apart gebied worden bijgehouden (bijv de redo log)
waarna de backup gemaakt wordt en de snapshot weer vrijgegeven.

Dit kan overigens zowel op het nivo van database transacties als op
het onderliggende blockdevice gebeuren. Bijvoorbeeld in een SAN
of een logical volume manager.
Den Voldere
2010-02-06 14:57:20 UTC
Permalink
Hoi,
Post by houghi
Zijn er gevaren of risico's om een mysqldump te doen op een draaiende
server, of is het beter om mysql af te zetten, de dump doen en opnieuw
opstarten?
Jullie thread zo lezende..

Ik gebruik ook een script die alle beschikbare db's eerst in
een lijstje zet en vervolgens apart 'dumpt' en het script
hier is mooier, dus ;-) Maar feitenlijk leunt mijn recovery
op een replication opzet, mysqlhotcopy is een extra
veiligheidsnet.

Maar terugkomend op je idee om 'mysql af te zetten': dat heb
ik jaren geleden besloten op een productie bak die achter een
ISP-order-inschiet php frontend hing: gewoon om 0200 's
nachts /etc/rc.d/mysql stop, met tar de raw files dumpen en
klaarzetten in /var/backup/mysql en /etc/rc.d/mysql start.
En een tijdje later kwam er een rsync opdracht om de hele
zaak over te pompen. Met een find /var/backup/mysql -ctime
+<veeluren>h -exec rm -f {} hield ik de retentie in de hand.

Tis vies, maar wellicht is er geen 24x7 eis die je
tegenhoudt.

Robert
Loading...