[MYSQL5] backup di DB che CRESCE TROPPO

[lino22011]

Buongiorno,
amministro un database legato ad un'applicazione fatto in mysql5 di cui faccio il backup automatico con mysqldump.

Il mio dubbio è :
questo db cresce troppo , nel giro di un anno un suo backup completo arriva a circa 100 MB e il problema è che considerata la logica dell'applicazione il tasso di espansione del db sarà costante!

E' la prima volta che amministro un db che cresce così costantemente.

Vorrei sapere:
esiste un modo pratico, secondo la vostra esperienza personale, che permetta di fare dei backup incrementali...ad esempio solo di record aggiornati dopo una certa data? ma sempre "da riga di comando" tipo mysqldump...

Ho cercato su google e mi sembra che modi ne esistano ma volevo sapere un parere basato su esperienze di "amministrazione vissuta".

Ogni spunto è graditissimo,
Grazie!

[deleted_29]

Originariamente inviato da lino22011
Buongiorno,
amministro un database legato ad un'applicazione fatto in mysql5 di cui faccio il backup automatico con mysqldump.

Il mio dubbio è :
questo db cresce troppo , nel giro di un anno un suo backup completo arriva a circa 100 MB e il problema è che considerata la logica dell'applicazione il tasso di espansione del db sarà costante!

E' la prima volta che amministro un db che cresce così costantemente.

Vorrei sapere:
esiste un modo pratico, secondo la vostra esperienza personale, che permetta di fare dei backup incrementali...ad esempio solo di record aggiornati dopo una certa data? ma sempre "da riga di comando" tipo mysqldump...

Ho cercato su google e mi sembra che modi ne esistano ma volevo sapere un parere basato su esperienze di "amministrazione vissuta".

Ogni spunto è graditissimo,
Grazie!

bhè la dimensione in realtà è minuscola (dipende dalle tue esigenze), non mi è chiarissimo quale sia il problema (a meno che non fai le copie su uno spazio davvero ridotto).

Per quanto riguarda i backup incrementali... la risposta è "ni", nel senso che è possibile (tipicamente usando i log), ma per una situazione così minuscola te li sconsiglio supervivamente, così come lascerei perdere gli mk.
---
In un caso del genere ti consiglio, assai più banalmente, di redirezionare il dump ASCII verso un compattatore qualsiasi; a seconda del sistema operativo che usi non hai che l'imbarazzo della scelta
gzip
arc
rar
7z
pbzip2
p7zip
paq8 (se sei veramente "fanatico")
nz

ti metto qualche esempino
RAR (Windows o linux, per piccoli db non ha un gran senso preoccuparsi del tempo di compressione)
Puoi usare rar32, rar o winrar
Normalmente uso questo (attenzione a dare un nome con -si altrimenti te lo chiama stdin)

mysqldump -uroot -ppassword --opt nomedb |rar32 a -sidumpato.sql compresso.rar

Alternativa free con 7z

mysqldump -uroot -ppassword --opt nomedb |c:\7z\7z a -sidumpato.sql compresso.7z

o magari mettendoci pure un -m0=lzma2 se hai parecchia RAM e più core [ad esempio con 6 core fisici è più veloce del doppio]
...
ma ce ne son tanti altri: per dump grandi e quando non vuoi caricare la macchina pbzip2 (win / linux) è da prediligere,
ad esempio

mysqldump -uroot -ppassword nomedb |pbzip2 -c -1 >compresso.bz2

con molti core è (quasi) veloce come un dump "semplice".
usando il "mitico" gzip (anche se comprime poco), su macchine lente, riduci spesso di 3/4 la dimensione del dump senza grandi patemi (e carico minimo)


Su windows con RAM e CPU arc è la scelta migliore...se vuoi/puoi fare un batch ti puoi "sbizzarrire" come vuoi con i codificatori aritmetici, ideali per i file ASCII

[deleted_29]

OK qualche prova giusto per dare un'idea...
su una macchina potente, in circa 4 minuti, si può ridurre un "normale" backup di circa il 96% (chiaramente cambia a seconda del contenuto)

Dump mysql ASCII

                  183.587.505

primo gruppo: veloci & grassi
vincono
rar -m1 (windows e linux/macchine monocore)
arc (windows, linux 32 bit, macchine pluricore)
menzione per nz (pluricore)

gzip   -1          34.839.188     2,59  s
rar32.zip -m1      34.839.274     2,97  s
arc  -m1           30.680.612     0,389 s
7z   zip  minima   30.531.362     3,41  s
rar       -m1      29.855.743     3,411 s
gzip   -9          27.271.418     9,269 s
rar32.zip -m5      27.291.279    11,47  s
nz -cdp            25.168.345     2,902 s

Gruppo2: intermedi

vince  (!!)
pbzip2 -9 (pluricore)

pbzip2 -1          23.572.029     5,162 s
nz -cDP            23.583,693     8,214 s
bzip2  -1          23.508.384    26,489 s
pbzip2 -9          19.849.395     7,936 s
bzip2  -9          19.799.004    36,256 s
7z                 19.667.906    33,369 s
7z   -m0=lzma2     19.690.032    13,318 s
rar32     -m5      18.290.846    16,616 s


Gruppo4: fanatici 
(*attenzione affidabilità non eccezionale per
gli "esoterici" durilca, nz e paq)

vincono arc (windows, linux32, multicore) e
paq (per fanatici veri)

arc  -mx           16.856.691    77,213 s         
durilca            13.255.836   407,093 s
nz -cc             12.094.343   242,436 s
paq8px  -8          9.742.309 10087,96  s

Se poi sei "veramente" un "fanatico" puoi sempre fare un
diff -u di un dump "storico" per avere le copie "differenziali", per poi comprimere (e conservare) solo quelle.

magari schedulando una volta a settimana il "refresh" del dump storico per calcolare le differenze.

Ovviamente in fase di ripristino farai un "patch"

[deleted_29]

Infine ti segnalo, sempre in linea teorica, visto che la cosa in realtà non ti dovrebbe interessare per db così piccoli, che puoi aggiungere dei campi "ultima modifica" (per ogni tabella) che vengono automaticamente "refreshati" da mysql.

puoi poi estrarre solo le righe delle varie tabelle che sono state modificate dopo una certa data (quella data), con un mysql -e.

Si tratta, però, di una strategia quantomeno scomoda che si adotta nel caso in cui sia veramente oneroso, o addirittura impossibile, fare il backup di un db davvero grande

[lino22011]

Ciao e grazie delle risposte molto interessanti...

sì ammetto: sono un pivello dell'amministrazione di database.
Vengo in effetti dall'ambito sistemistico, ne ho fatti molti di db ma mai amministrati nel tempo quindi francamente mi sembrava grande la velocità con cui cresce ma evidentemente a qualcuno esperto appare minuscola!!

Scusa, per curiosità ma sono note le dimensioni che può raggiungere un db MySQL o non si sa?
Per essere considerato grande un database che soglia deve superare? tanto per avere un'idea...

Ho trovato interessante l'idea di fare backup differenziali con diff e patch...non ci avevo pensato anche se mi hai spiegato che al momento non ho bisogno...

Grazie mille

[deleted_29]

Originariamente inviato da lino22011
Scusa, per curiosità ma sono note le dimensioni che può raggiungere un db MySQL o non si sa?

A memoria sono 4TB per tabella myisam e 64TB per tablespace innodb, magari dai un'occhiata alla documentazione.

Per essere considerato grande un database che soglia deve superare? tanto per avere un'idea...

Normalmente è "grande" quando nella RAM non ci stanno gli indici.

Ovviamente dipende dalla macchina usata; nella mia esperienza fino a qualche centinaio di gigabyte di dati non ci sono grossissimi problemi.
---
Diciamo che 100MB non sono esattamente un problema

[lino22011]

Ok confermo: sono proprio un pivello!

Vado a leggere un altro pò di documentazione...
Grazie mille ancora