---

Under /var/lib/mysql ligger der en lang række filer som afspejle de
ændringer der er sket. Mit spørgmål går på hvad man bruger filerne til eller
om man "blot" sletter dem ? Man kan vel "bare" lukke mysql ned, lave en kopi
af database filer, også starte mysql op igen, hvis man ønsker at lave en
kopi fremfor at bruge replikering af data. Min ide er at lukke MySQL ned en
gang om natten, kopiere filerne over i et andet dir, og starte MySQL igen -
hvordan tager I andre backup af data ?

Jørn

---

"Jørn Hundebøll" <news1@dblue.dk> wrote in message
news:3e20bba5$0$83836$edfadb0f@dtext01.news.tele.dk...
> Under /var/lib/mysql ligger der en lang række filer som afspejle de
> ændringer der er sket. Mit spørgmål går på hvad man bruger filerne til
eller
> om man "blot" sletter dem ? Man kan vel "bare" lukke mysql ned, lave en
kopi
> af database filer, også starte mysql op igen, hvis man ønsker at lave en
> kopi fremfor at bruge replikering af data. Min ide er at lukke MySQL ned
en
> gang om natten, kopiere filerne over i et andet dir, og starte MySQL
igen -
> hvordan tager I andre backup af data ?

Det kan du godt, men en bedre løsning ville være at bruge MysqlDump
kommandoen, som laver et dump af en eller flere databaser til en fil.

Dør databasen, sender du filen til Mysql igen, som derefter opretter baser,
tabeller og poster igen som de var da dumpet blev lavet.

Hilsen Søren Reinke

---

"Søren Reinke" <disky@disky.ihsyd.dk> wrote

> Det kan du godt, men en bedre løsning ville være at bruge MysqlDump
> kommandoen, som laver et dump af en eller flere databaser til en fil.
>
> Dør databasen, sender du filen til Mysql igen, som derefter opretter
baser,
> tabeller og poster igen som de var da dumpet blev lavet.

Hvorfor er den bedre? At hælde en dumpet fil tilbage i mysql, tager længere
tid end at kopiere filerne i /var/lib/mysql som Jørn forslår.

--
Kim Emax

---

Kim Emax wrote:
> "Søren Reinke" <disky@disky.ihsyd.dk> wrote
>
>> Det kan du godt, men en bedre løsning ville være at bruge MysqlDump
>> kommandoen, som laver et dump af en eller flere databaser til en fil.
>
> Hvorfor er den bedre? At hælde en dumpet fil tilbage i mysql, tager længere
> tid end at kopiere filerne i /var/lib/mysql som Jørn forslår.

Fordi man så ikke behøver at lukke mysql ned mens man tager backup.

--
Don't waste space

---

"Thomas" wrote

> Fordi man så ikke behøver at lukke mysql ned mens man tager backup.

Du vil stadig rende ind i problemer, hvis en bruger skriver til din
database, efter du har lavet en drop table og mens du derefter hælder dumpet
ind igen, såeee... Jeg ville aldrig hælde et dump efter en aktiv DB

--
Kim Emax

---

"Kim Emax" <news@remove-emax.dk> writes:

> "Thomas" wrote
>
>> Fordi man så ikke behøver at lukke mysql ned mens man tager backup.
>
> Du vil stadig rende ind i problemer, hvis en bruger skriver til din
> database, efter du har lavet en drop table og mens du derefter hælder dumpet
> ind igen, såeee... Jeg ville aldrig hælde et dump efter en aktiv DB

Hvor tit tager du backup af din database for at restore den igen efter
5 minutter? Personligt tager jeg backup af et par Mysql db'er med
mysqldump hver dag, så hvis maskinen skulle crashe eller hvis db'en
skulle gå kold, så har jeg en backup der er forholdsvis ny. En backup
er jo ikke nødvendigvis 100% uptodate. Og når du restore en db så er
det typisk til en "ny" mysql eller hvis du har slettet databasen, så
derfor er der ingen der skriver til den på det tidspunkt. Man kan med
mysql dump vistnok også bestemme hvilken type backup man vil tage,
afhængig af den type restore man efterfølgende regner med at foretage.

/Thomas

--
/"\ | Human Knowledge Belongs To The World
\ / | -- Milo Hoffman in "AntiTrust"
x |
/ \ <-- (ASCII Ribbon Campain against html emails and postings!)

---

"Thomas Rasmussen" <simpsons@kom.auc.dk> wrote

> Hvor tit tager du backup af din database for at restore den igen efter
> 5 minutter?

aldrig

Det jeg argumenterede for var at uanset om jeg valgte at lave en kopi af
/var/lib/mysql eller om jeg lavede en mysqldump, så ville jeg ikke smide
data tilbage til mysql mens den kørte.

--
Kim Emax

---

"Kim Emax" <news@remove-emax.dk> writes:

> Det jeg argumenterede for var at uanset om jeg valgte at lave en kopi af
> /var/lib/mysql eller om jeg lavede en mysqldump, så ville jeg ikke smide
> data tilbage til mysql mens den kørte.

Nej, men så vidt jeg forstod problemet så er det at du skal lukke
mysql ned for at være sikker på at filerne i /var/lib/mysql er
uptodate, dette er ikke et problem med mysqldump. Desuden sker der
ikke noget ved at smide data genereret af mysqldump ind mens mysql
kører, så længe at der naturligvis ikke er andre der bruger den
(Har lige gjort det på en server). Mysqldump generere jo blot en stak
sql filer som kan parses direkte til mysql.

Så umiddelbart må den bedste måde at tage backup være med
mysqldump. Selvf. kan der være problemer hvis databasen er *meget*
stor da det nok er lidt langsommere end at kopiere filerne fra
/var/lib/mysql. Men den ulempe mener jeg opvejer at man slipper for at
lukke mysql ned hver gang man vil tage backup.

/Thomas

--
/"\ | Human Knowledge Belongs To The World
\ / | -- Milo Hoffman in "AntiTrust"
x |
/ \ <-- (ASCII Ribbon Campain against html emails and postings!)

---

"Thomas Rasmussen" wrote

> Nej, men så vidt jeg forstod problemet så er det at du skal lukke
> mysql ned for at være sikker på at filerne i /var/lib/mysql er
> uptodate, dette er ikke et problem med mysqldump. Desuden sker der
> ikke noget ved at smide data genereret af mysqldump ind mens mysql
> kører, så længe at der naturligvis ikke er andre der bruger den

Problemet eksisterer også kun, hvis nogen skriver til databasen _mens_ Bu
indlæses...

> (Har lige gjort det på en server). Mysqldump generere jo blot en stak
> sql filer som kan parses direkte til mysql.

Jeps, men disse har IDer med i deres INSERT og du skal lige huske at lave en
DROP table inden du hælder info ind igen, ellers får du en fejl. Har du nu
en million records og en fætter (eller kusine) ræser ind og skriver til
tabellen imens, så kan du risikere at der kommer spunk i tabellen. Det
undgåes så ved at smide --add-locks på dumpet, når det foretages, men jeg
kan ikke se at man kan låse tabellen, når man smider den op igen... Jeg vil
lige lege lidt med det

Noget andet spændende jeg faldt over er mysqlhotcopy:
http://www.mysql.com/doc/en/mysqlhotcopy.html, men det _skal_ køre på den
server, hvor databasen ligger. Det kan så nemt omgåes... ser interessant ud.

> Så umiddelbart må den bedste måde at tage backup være med
> mysqldump. Selvf. kan der være problemer hvis databasen er *meget*
> stor da det nok er lidt langsommere end at kopiere filerne fra
> /var/lib/mysql. Men den ulempe mener jeg opvejer at man slipper for at
> lukke mysql ned hver gang man vil tage backup.

Som sagt. så ville jeg under alle omstændigheder lige stoppe svinet, når jeg
skulle hælde data ind i den igen. Læser du om mysqldump er de selv inde
på at meget store databaser kan give memory problemer. Det kan så omgåes med
quick eller opt parametrene...

--
Kim Emax

---

Thomas Rasmussen <simpsons@kom.auc.dk> wrote in message
news:28phecabm2g.fsf@bart.aalk.auc.dk...
> "Kim Emax" <news@remove-emax.dk> writes:
>
> > "Thomas" wrote
> >
> >> Fordi man så ikke behøver at lukke mysql ned mens man tager backup.
> >
> > Du vil stadig rende ind i problemer, hvis en bruger skriver til din
> > database, efter du har lavet en drop table og mens du derefter hælder
dumpet
> > ind igen, såeee... Jeg ville aldrig hælde et dump efter en aktiv DB
>
> Hvor tit tager du backup af din database for at restore den igen efter
> 5 minutter? Personligt tager jeg backup af et par Mysql db'er med
> mysqldump hver dag, så hvis maskinen skulle crashe eller hvis db'en
> skulle gå kold, så har jeg en backup der er forholdsvis ny.

Nu er mine databaser så små, at det tager 3-5 sekunder at lave et dump af
databaserne. Men jeg er lidt nervøs for in-konsistens i data, forstået
således at et program skriver i flere felter lige imens man lave dump'et,
derved kan man kommer til at lave en record som peger på en anden record, og
dump'et blev lavet imellem de to records blev skrevet. Hvordan sikre man sig
imod den situation (selvom det er en meget teoretisk situation for mig).


>En backup er jo ikke nødvendigvis 100% uptodate.

Det synes jeg er et stort problem (underforstået vi ikke taler om at der er
kommet nye data efter backup er lavet, og data i backup ellers er 100%
konsistente).



--
Jørn

http://www.dblue.dk - Home of the Gnu.

---

Jørn Hundebøll wrote:

[backup af mysql databaser]

> Nu er mine databaser så små, at det tager 3-5 sekunder at lave et dump af
> databaserne. Men jeg er lidt nervøs for in-konsistens i data, forstået
> således at et program skriver i flere felter lige imens man lave dump'et,

SVJH låser mysql databasen, mens den dumper. Så dine update's afventer
"pænt" at de får adgang til at skrive.

--
Don't waste space

---

Thomas wrote:

> SVJH låser mysql databasen, mens den dumper. Så dine update's afventer
> "pænt" at de får adgang til at skrive.

Der er et parameter --add-locks som man kan tilføje, når man dumper. Så en
hurtig konklusion må være at er dette paramterer ikke med i kommandoen, så
låser den nok ikke noget.

--
Take Care
Kim Emax - Freelance programmør
http://www.emax.dk - http://www.ayianapa.dk
Køb din vin online på http://www.gmvin.dk,
Danmarks måske mest avancerede VinWebShop

---

Jørn Hundebøll wrote:
>
>>En backup er jo ikke nødvendigvis 100% uptodate.
>
> Det synes jeg er et stort problem (underforstået vi ikke taler om at der er
> kommet nye data efter backup er lavet, og data i backup ellers er 100%
> konsistente).

Nu kender jeg ikke dit setup, men hvis du gemmer update-logs, f.o.m. din
backup et tilgængeligt sted (f.eks på en anden server), kan du faktisk
komme næsten up2date.

--
Don't waste space

---

Thomas <intheNOSPAMnews@corell.dk> wrote in message
news:slrnb2bl12.2oi6.intheNOSPAMnews@mail.corell.dk...
> Jørn Hundebøll wrote:
> >
> >>En backup er jo ikke nødvendigvis 100% uptodate.
> >
> > Det synes jeg er et stort problem (underforstået vi ikke taler om at der
er
> > kommet nye data efter backup er lavet, og data i backup ellers er 100%
> > konsistente).
>
> Nu kender jeg ikke dit setup, men hvis du gemmer update-logs, f.o.m. din
> backup et tilgængeligt sted (f.eks på en anden server), kan du faktisk
> komme næsten up2date.


Gemmer og gemmer - jeg har ikke slettet dem endnu, men jeg har ikke styr på
hvordan man faktisk bruger dem. Jeg er lige i øjeblikket i gang med at kører
en ældre pentium server op, som jeg har planer om skal fungere som backup
maskine for mail og web. Det er så meningen at jeg vil dumpe databaserne,
flytte filerne over netværket sammen med de øvrige web-filer og mail filer.
Skulle min hovedmaskine give knuder, er det "blot" at skifte IP forward
adressen på routeren, og jeg vil være i luften igen med det mest nødvendige.
Jeg er som sådan indstillet på at "miste" de data der er kommet til fra
sidste backup af databasen, således at jeg halv manuelt tager en backup, når
jeg har lavet ændringer. Databasen indeholde informationer til webserveren,
og det er en backup i fald webserveren bliver hacket. Derfor vil jeg heller
ikke lave en automatisk backup, for så skulle jeg gemme lang tid tilbage i
stedet for at overskrive, for at undgå at lave en backup af en hacket
udgave. Så jeg har nok ikke det store behov for at anvende update-log
filerne, men ville da meget gerne vide hvordan man anvendte dem.

Jørn

---

Kim Emax wrote:
> "Thomas" wrote
>
>> Fordi man så ikke behøver at lukke mysql ned mens man tager backup.
>
> Du vil stadig rende ind i problemer, hvis en bruger skriver til din
> database, efter du har lavet en drop table og mens du derefter hælder dumpet
> ind igen, såeee... Jeg ville aldrig hælde et dump efter en aktiv DB

Jeg troede vi snakkede backup, ikke restore.

Ja, der vil være nedetid på din database, fra den går (seriøst) i
stykker, til du har restore't data.

--
Don't waste space

---

Thomas wrote:

> Jeg troede vi snakkede backup, ikke restore.

Ja, det har du egenligt ret i... det er Backup, der blev spurgt til... Jeg
var bare (som altid høhø et skridt foran.

> Ja, der vil være nedetid på din database, fra den går (seriøst) i
> stykker, til du har restore't data.

Specielt, hvis det er de mængder data vi har rodet med, da vi arbejdede
sammen. Benytter I stadig MySQL derinde? Kunne være interessant at høre, om
I kan bruge mysqlhotcopy til noget i den forbindelse, måske til erstatning
for MySQLsync?

Kim

---

Der er grundlæggende to muligheder til at lave backup af en MySQL server:

1) Luk MySQL ned og tag backup af dens filer.
2) Benyt mysqldump til at lave en backup.

Hilsen,

Lars.

--
Dybdahl Engineering
http://dybdahl.dk/

---

"Jørn Hundebøll" wrote

> hvordan tager I andre backup af data ?

Jeg faldt over mysqlhotcopy: http://www.mysql.com/doc/en/mysqlhotcopy.html,
men det _skal_ køre på den server, hvor databasen ligger. Det kan så nemt
omgåes... ser interessant ud.

--
Kim Emax

---

Kim Emax <news@remove-emax.dk> wrote in message
news:M0fV9.36084$Hl6.4264872@news010.worldonline.dk...
> "Jørn Hundebøll" wrote
>
> > hvordan tager I andre backup af data ?
>
> Jeg faldt over mysqlhotcopy:
http://www.mysql.com/doc/en/mysqlhotcopy.html,
> men det _skal_ køre på den server, hvor databasen ligger. Det kan så nemt
> omgåes... ser interessant ud.

Jeg faldt selv over linket på et tidspunkt, og skal nok også have undersøgt
det. Men mysqldump er f..... nemt at bruge.

>
> --
> Kim Emax
>
>


--
Jørn

http://www.dblue.dk - Home of the Gnu.

---

"Jørn Hundebøll" wrote

> Jeg faldt selv over linket på et tidspunkt, og skal nok også have
undersøgt
> det. Men mysqldump er f..... nemt at bruge.

Jep, og som Thomas nævnte, så var det jo backup du spurgte til

--
Kim Emax