Discussioni sul sistema operativo Linux
 

Bacula: recovery tabella Filename

gandalf.corvotempesta@gmail.com 18 Giu 2015 11:08
E' 5 giorni che sta cercando di fare il recovery della tabella Filename, è
oltre 100GB e durante il recovery con myisamchk il backup ovviamente è fermo.

Faccio prima a droppare e ricreare.

C'è modo, con Bacula, di ripopolare la tabella in questione partendo magari dai
******* di volume ?

Alternative ?
gandalf.corvotempesta@gmail.com 18 Giu 2015 16:18
Il giorno giovedì 18 giugno 2015 11:08:39 UTC+2, gandalf.co...@gmail.com ha
scritto:
> C'è modo, con Bacula, di ripopolare la tabella in questione partendo magari
dai ******* di volume ?

Si può ripopolare con bscan, ed è quello che sto facendo.

Confermo il mio o***** verso questo software.
Enrico Bianchi 19 Giu 2015 00:10
gandalf.corvotempesta@gmail.com wrote:

> Confermo il mio o***** verso questo software.

Quale, Bacula o MySQL? :P
In ogni caso, ti consiglio di convertire quelle tabelle in
InnoDB (anche se e` rischioso, se hanno previsto MyISAM
probabilmente non gestiscono le transazioni) o di passare a
PostgreSQL :)

Enrico
gandalf.corvotempesta@gmail.com 19 Giu 2015 10:58
Il giorno venerdì 19 giugno 2015 00:10:06 UTC+2, Enrico Bianchi ha scritto:
> Quale, Bacula o MySQL? :P

Bella domanda. Entrambi.

> In ogni caso, ti consiglio di convertire quelle tabelle in
> InnoDB (anche se e` rischioso, se hanno previsto MyISAM
> probabilmente non gestiscono le transazioni) o di passare a
> PostgreSQL :)

A dire il vero, preferisco MyISAM per poterle svuotare in maniera
easy. Ho già notato che bacula gestisce a ******* il database, tant'è
che han fatto un apposito strumento per ripulirlo (dbcheck)

MyISAM, tra i mille difetti, ha un vantaggio: la cancellazione di
record libera il disco. Con innodb per liberare spazio bisogna fare
un bel truncate e considerato che il mio database è centinaia di GB,
mettere tutto su innodb peggiorerebbe solo le cose.

Devo studiarmi Amanda, ma la documentazione è persino peggio di
quella di Bacula, non so da dove cominciare.
Enrico Bianchi 20 Giu 2015 14:41
On Fri, 19 Jun 2015 01:58:17 -0700, gandalf.corvotempesta wrote:

> Con innodb per liberare spazio bisogna fare un bel truncate e
> considerato che il mio database è centinaia di GB, mettere tutto su
> innodb peggiorerebbe solo le cose.

Non capisco dove sia il problema. Lo spazio liberato dal delete viene
riutilizzato dal database nel momento in cui tutti i riferimenti a quei
record vengono terminati (se non ricordo male, MySQL utilizza MVCC per
come sistema di locking). Altrimenti, te lo ripeto, usa PostgreSQL e vivi
felice :)

> Devo studiarmi Amanda, ma la documentazione è persino peggio di quella
> di Bacula, non so da dove cominciare.

Alla fine hai optato per passare a lui? :)
Tieni presente che puoi richiedere una consulenza professionale per
Amanda dagli stessi tizi di BackupPC

Enrico
gandalf.corvotempesta@gmail.com 21 Giu 2015 10:23
Il giorno sabato 20 giugno 2015 14:41:32 UTC+2, Enrico Bianchi ha scritto:
> Non capisco dove sia il problema. Lo spazio liberato dal delete viene
> riutilizzato dal database nel momento in cui tutti i riferimenti a quei
> record vengono terminati (se non ricordo male, MySQL utilizza MVCC per
> come sistema di locking). Altrimenti, te lo ripeto, usa PostgreSQL e vivi
> felice :)

Il problema è che MySQL riesce ad utilizzare lo spazio liberato, ma il resto
del server no. Se finisco lo spazio su disco, anche se cancello milioni di
record obsoleti, il DB torna a funzionare, ma per i backup non c'è comunque
più spazio fisico.

Questo è il problema. Per ora lo aggiro ordinando un Supermicro da 24 dischi, a
quanto pare il server attuale con "soli" 40TB in RAID-6 non è abbastanza
cicciotto.

Ciò che fa rabba è la errata "garbage collection" di bacula, che continua ad
ammucchiare schifezze senza realmente mai cancellarle, facendo rapide *****isi a
colpi di find, vedo che ci sono vagonate di volumi su disco senza i rispettivi
full, vale a dire incrementali inutilizzabili (perchè il primo full esistente
è datato dopo l'incrementale stesso)

Nonostante ciò, le varie retention sono configurate giuste, il full è il
volume con la maggiore retention, ad esempio 60 giorni, tutti gli altri hanno
retention inferiori, quindi non mi capacito di come sia possibile che esistano
incrementali più vecchi del full e che portano via svariati giga di spazio.

> Alla fine hai optato per passare a lui? :)
> Tieni presente che puoi richiedere una consulenza professionale per
> Amanda dagli stessi tizi di BackupPC

Sto valutando, ma il fatto che non esista documentazione mi fa rabbrividire.
Controlla il sito, della 3.3 non c'è documentazione, solo manpages. Googolando
ho trovato un manuale per la 2.5, da li in poi non c'è nulla, solo le singole
manpages dei vari componenti ed alcuni brevi tutorial.

Fa rabbrividire questa cosa....
Enrico Bianchi 21 Giu 2015 14:59
On Sun, 21 Jun 2015 01:23:08 -0700, gandalf.corvotempesta wrote:

> Il problema è che MySQL riesce ad utilizzare lo spazio liberato, ma il
> resto del server no.

E dov'e` il problema? Se quello spazio serve a MySQL perche` dovrebbe
essere utilizzato dal resto del server? In ogni caso, se usi InnoDB, puoi
abilitare la compressione delle tabelle: https://dev.mysql.com/doc/
refman/5.5/en/innodb-compression.html

> Se finisco lo spazio su disco, anche se cancello
> milioni di record obsoleti, il DB torna a funzionare, ma per i backup
> non c'è comunque più spazio fisico.

Ripeto, non capisco dove sia il problema, ma presumo che sia per il fatto
che non consoco la tua architettura...

> Sto valutando, ma il fatto che non esista documentazione mi fa
> rabbrividire.

Se vuoi ti passo il mio (ancora un po' immaturo, a dire il vero) sistema
di backup, alla fine si tratta di lanciare un eseguibile con un ******* di
configurazione autoesplicativo :P

Enrico
gandalf.corvotempesta@gmail.com 22 Giu 2015 09:25
Il giorno domenica 21 giugno 2015 14:59:06 UTC+2, Enrico Bianchi ha scritto:
> E dov'e` il problema? Se quello spazio serve a MySQL perche` dovrebbe
> essere utilizzato dal resto del server? In ogni caso, se usi InnoDB, puoi
> abilitare la compressione delle tabelle: https://dev.mysql.com/doc/
> refman/5.5/en/innodb-compression.html

L'ho scritto dov'è il problema: lo spazio non serve solo al database ma anche
al resto del server per salvare i ******* di backup.

Se ho 100GB a disposizione e MySQL me li usa tutti senza liberare spazio (ma
lasciandosi spazio "per se"), è vero che MySQL potrà continuare a scrivere
dati, ma il resto del server no, ed i backup si bloccano, proprio come ora.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.