Dotaz: Inkrementální záloha MySQL

[Heron]

Dobrý den.

Stojím před problémem narůstajícího objemu dat v DB. Kompletní záloha trvá příliš dlouho a změň je oproti předchozímu dni relativně málo. Napadlo mě to řešit pomocí inkrementální zálohy - používáte něco hotového?

DB schema měnit můžu, ale nechce se mi tam bezhlavě nastrkat sloupec TIMESTAMP s vlastností ON UPDATE CURRENT_TIMESTAMP. Pak může nastat situace, že zálohy pomocí SELECT ... WHERE `time`>last nebudou kompletní z hlediska cizích klíčů. Jak byste to řešili?

Odpovědi

[kafa]

Využil bych k zálohám incrementální logy pro replikaci, nebo bych prostě vytvořil repliku a zálohoval tu. Na čase pak nezáleží.

[RapMan]

Ahoj, jako zalohu take pouzivame replikaci. Na dalsim virtualnim stroji bezi mysql server, kam se replikuji vsechna data z primarniho mysql serveru, v pripade havarie je tedy ihned k dispozici nejaktualnejsi online zaloha.

[Peter Lehotsky]

Replikace !=zaloha, abyste jednou nekoukal na 2 zborcene servery a netrhal si vsechny chlupy .

[azurIt]

tak tak, pripomina mi to ako dost vela ludi povazuje RAID za zalohovanie :)

[Heron]

JJ, těch je taky dost.

Nápad s replikací mi nic neřeší. Délka zálohy se tím neomezí, jen se přesune jinam (a je mi jedno, zda 6h zálohuji server A, nebo B). Snad pomohou ty binlogy, zatím jsem se na ne nedíval a jen jsem trochu změnil schema, ať není potřeba denně tahat x desítek GB.

[Peter Lehotsky]

Bacula nebo TSM?

[Heron]

Bacula umí zálohovat SQL?

[Peter Lehotsky]

Dost kopiruji funkcionalitu TSM, tak to snad umi. Pouzival jsem ji pouze na soubory.

[Peter Lehotsky]

tak si neco vyber

[Ivan]

TSM tohle urcite nevyresi. Sice umi inkrementalne zalohovat Oracle nebo Informix, ale pouziva k tomu prostredky databaze. Tzn. pokud vase databaze nema podporu pro online/incrementalni zalohu, tak mate smulu. Muzete mozna pouzit snapshoty nad LVM. Pokud verite tomu, ze MySQL ma v kazdem okamziku data na disku konzistentni.

[kafa]

Zatímco zálohujete repliku B, server A může normálně pracovat. Takže jedno to rozhodně není. Naopak. Zálohování pouhých změn znamená delší a složitější obnovu a větší riziko chyb. Přitom čas obnovy je rozhodně kritičtější, než doba zálohy, běžící "na pozadí".

[pupala]

Preto je výhodná kombinovaná záloha, cez týždeň inkrementálna, a v noci zo soboty na nedeľu kompletná.

[RapMan]

Ano, replikace neni zaloha, nejsme hloupi, ale delani zalohy z replikovaneho serveru je mnohem jednodussi nez z produkcniho serveru.

[finc]

My provadime zalohu klasicky, pres mysqldump, ktery je naplanovan v crone. Vzdy vytvorime soubor nesouci nazevdb_den_v_tydnu.gz. Tak mam v podstate 7 zaloh, ktere se stale opakuji.

Pri spousteni dotazu provedu dump s ulozenymi procedurami a v jedne transakci (duvodem je prave innodb a reference). Cely vystup je pak zabalen do gz.

Osobne jsem nekolik let zkoumal, jak to udelat efektivneji a lepe. Bohuzel, mozna bohudik, jsem nic jineho nenalezl. Toto je naprosto nejjednodussi, nejrychlesi a nejspolehlivejsi zpusob.

Jedna DB ma priblizne kolem 2GB, samotny dump je otazka par minut, takze nejde o nic hrozneho.

Pokud pouzivas referencni integrity a replikaci nepovazujes za zalohu (s cimz souhlasim), tak si myslim, ze stejne nic elegantniho nenaleznes.

[Heron]

Asi to tak nakonec dopadne, řešení to není špatné (sice vyžaduje trochu změnu schematu, ale nic velkého). Udělám dump do vedlejší DB, kterou následně pomocí mysqldump zazálohuji. A každý týden asi o víkendu udělám full. Import 40GB nebo 40GB * 6 * par stovek MB není zas takový rozdíla úspora času bude značná.

Dík všem za návrhy.

[jahor]

ahoj,

doporucuji podivat se na mylvmbackup (http://lenz.homelinux.org/mylvmbackup/) jde o maly nastroj, ktery pokud je mysql na lvm, umi udelat snapshot a kompletni zalohu. v mem pripade prave testuji toto nasazeni pro db kde konzistentni zaloha pomoci mysqldumpu jiz nebyla mozna (prilis dlouhy lock cele db). prijde mi jako idealni kombinace ve spojitosti s replikou kde pak probiha normalni mysqldump. sice je to zdvojene ale to neni na skodu. mysql na lvm lze take vyuzit v pripade kdyz se nejak poskodi replikace a je treba ji dat dokupy. zajimave jeste je ZRM (www.zmanda.org) ktery umi i point-in-time recovery z provedenych zaloh. ale s tim nemam praktickou zkusenost.