19. november 2002 - 10:21Der er
12 kommentarer og 4 løsninger
Backup uden database-brugere forstyrres - HVORDAN ???
Jeg har en MySQL database på 2GB jeg meget gerne vil have lavet backup af. Det tager ca. 300 sekunder at lave backupen. Men databasen får nye data lagt ind hver 10. sekund - DØGNET RUNDT! Og med fx. mysqlhotcopy bliver de aktuelle tabeller låst så de database opdateringer der gerne skulle ske hver 10. sekund - bliver sat i kø. Og det er MEGET uheldigt, fordi det forsinker alle de øvrige systemer!
Hvordan får jeg lavet en backup der IKKE forstyrre de andre SQL opgaver ??
Okay så skal du lave en backup database der er 100% magen til den første rent configurations mæssigt, når du så vil lave et backup sørger du rent programmeringsmæssigt for at du begynder at lægge data over i backupbasen. Derefter laver du et backup af den rigtige base, via mit script. Når du er færdig kobler du tilbage på den rigtige base, og merger data fra backupbasen.
Nej, backupen behøber ikke være 100% magen til. Hvis der mangler de sidste 5 minutters data der er kommet ind samtidig med at jeg laver backupen - det gør ikke noget.
Men det store problem er at der hver 10. sekund kommer data ind som SKAL afleveres i databasen!
Af indlysende årsager kan man ikke umiddelbart lave backup af en database mens den bliver opdateret, fordi man vil få en inkonsistent backup.
For at du overhovedet kan lave en konsistent backup kræver det at du har et tidspunkt T, hvor der ikke er udestående transaktioner.
Men hvis jeg forstå dig korrekt, så har du et vindue på 10 sekunder minus den tid det tager at at indsætte data.
Der er high-end databaser som kan fryse alle data-pages på et sekund og så putte alle rettelser i nye data-pages, mens backup kører. Det tvivler jeg på at MySQL kan.
Der er log-baserede fil-systemer altid skriver en ny disk blok i.s.f. at opdatere en gammel og derfor kan gøre det. Men næppe heller en option.
Så kan du bruge database replikering til at have en kopi standby og du skifter så over til kopien i vinduet på 10 sekunder. Jeg mener bestemt at MySQL kan lave replikering, men jeg ved ikke hvor godt det virker (specielt når den første skal bringes tilbage efter backuppen er færdig).
Nu skrev du "data ind som SKAL afleveres". Betyder det at det er en ren INSERT uafhængig af eksisterende data i databasen ?
Hvis ja, så kan du lave en simpel "store and forward". I 10 sekunders vinduet skifter du til at begynde at gemme de nye INSERT's. Du kan enten gemme data i en tabel magen til de rigtige tabeller eller bare gemme SQL sætningerne. Når så du er færdig med backup henter du de ekstra data. Enten ved at hente data fra en tabel til en anden tabel eller ved at applye SQL sætninger.
1) Du kan godt opfatte det jeg skrev som det samme som dit forslag. Jeg synes at der er nogle ekstra relevante betragtninger.
2) Jeg kan ikke se, hvor han siger at det er OK konsekvent at miste data ved backup. Han siger at det gør ikke noget om de sidste 5 minutter ikke er på backup (=> mister kun data hvis det går galt og han får brug for backup).
Ang. at miste data: Jeg vil selvfølgelig helst ikke miste data. Men hvis de data der kommer ind samtidig med backupen først kommer med næste gang der køres backup gør det ikke noget. På den måde mister jeg kun det data der "skulle være gemt" mellem Tbackupstart og Tbackupfærdig. Så den har Arne gennemskuet!
Ang. div. andre ting: - Det er ikke almindelige INSERT operatoner - men en "LOAD DATA LOCAL INFILE". - Der foretages samtidig med indsættelses operationerne hvert 60. sekund mindst et SELECT kald til samme Tabel. - De omtalte data der bliver indsat hver 10. sekund - er kun en start. Når jeg kommer længere med projektet er der ca. 50 klienter der "IKKE NØDVENDIGVIS SAMTIDIG" sender data hver 10. sekund.
Det kan godt være at den nemmeste løsning er at få klienterne til at arbejde korrekt med tråde så at SQL indsættelsen IKKE får hele programmet til at gå i stå...?
En anden ting - kan replikering laves på 1 PC med FreeBSD - eller skal der flere maskiner til ? Og hvad så når den ene maskine er færdig med backupen og er 2-3 minutter bagefter - synkroniserer maskinerne selv op til hinanden ? Og hvem styrer synkroniseringen - er det MASTER der kontakter SLAVE - eller omvendt. Og vil mine "LOAD DATA LOCAL INFILE" indsættelser blive konverteret til almindelige INSERT operationer - mellem MASTER og SERVER - for så tror jeg at begge servere går i knæ. Det er trods alt ca. 1200 records pr. sekund.
Jeg kender ikke LOAD DATA LOCAL FILE, men det må svare til N x INSERT, så det er OK.
SELECT er readonly. Det bekymrer vi os ikke om. Og iøvrigt er 60 sekunder > 10 sekunder. No problem.
50 klienter som opdaterer hver 10. sekund usynkroniseret er et mega problem. Fordi i worst case så vil der ikke være noget vindue uden outstanding transactions.
Og så nytter alle de billige løsninger ikke. Hvis du har en 5-10 millioner som du ikek ved hvad du skal bruge til, så har IBM eller oracle sikkert en løsning.
Om du kan replikere mellem to databaser på samme server ? Ved jeg ikke - men check i MySQL dokumentation - det bør fremgå klart og tydeligt.
Jeg ved ikke hvordan MySQL laver replikering. Igen tror jeg du må studere dokumentationen.
1200 TPS er 72000 TPM. Det er ret meget. Men hvis en server kan klare det alene, så tror jeg også den kan klare at replikere til en magen til. Det bør ike være specielt dyrt at replikere. Flaskehalsen ved replikation er ofte net-båndbredden mellem systemerne.
Ønsker du at lave backup for at gemme historiske data, eller kun for sikkerhed ved nedbrud?
Hvis det er for at undgå nedbrud vil jeg anbefale software RAID løsning til spejling af diske, men dette er nok ubruglig, hvis du også vil have historiske data gemt.
Hvis du også vil have historiske data gemt, kan du programmere dig fra det, ved at kopiere alle data før de slettes/overskrives til en anden tabel måske i en anden database.
Hvad med en slags manuel replikering? Start med at have en kopi af databasen på en anden computer eller på samme. I løbet af dagen bliver kopien forældet, men det gør ikke noget.
En gang i døgnet flusher du transaktionsloggen. Du skal altså køre med log-update eller log-bin.
Så tager du den gamle transaktionslog og kører den på kopi-databasen. Derefter tager du backup af kopi-databasen. Den gamle transaktionslog kan så slettes.
Det kan laves ret simpelt i scripts.
Så kan databasen køre videre hele tiden. Flush låser ikke noget som helst.
Jeg skulle nu meget stærkt mene at disky har ret i sit første svar.. Den eneste grund til at inserts skulle blive forsinket skulle være rent load-mæssigt, men så må du jo køre mysqldump med lav prioritet. Uden --add-locks vil inserts stadig blive gennemført real-time og være tilgængelige i queries.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
