Newsgroup: it.comp.os.linux.sys
Titolo: Mai far crashare mysql...

.. sopratutto se c'è una tabella con 983.606.622.580 record e ben 7 (sette) indici. Mancano solo 100 miliardi di record da controllare e myisamchk sta girando da 2 giorni, a server fermo.
 
Ma a quanto può arrivare a crescere una tabella myisam ? C'è un limite?

 C'è un limite?
 
Ad essere sincero non me lo sono mai chiesto.
 
Comunque:
 
# There is a limit of 232 (~4.295E+09) rows in a MyISAM table.
# If you build MySQL with the --with-big-tables option, the
# row limitation is increased to (232)2 (1.844E+19) rows.
 
http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html
 
 

 Ma a quanto può arrivare a crescere una tabella myisam ? C'è un limite?
 
Limite o non limite, se voglio usare MySQL (e in alcuni casi sono costretto) 
una cosa che mi premuro di fare e` NON usare tabelle MyISAM a meno che non 
abbia una lupara puntata dietro la schiena ed un forcone posizionato 
all'altezza dei testicoli
 
Enrico

 # row limitation is increased to (232)2 (1.844E+19) rows.
 
Che tradotto significa: un sacco di righe.

 all'altezza dei testicoli
 
Premetto che non conosco benissimo innodb ma una sua cosa che odio è il fatto di non liberare spazio rimuovendo record.
Una tabella del genere, convertita in innodb, diventerebbe spesso centinaia di giga senza possibilità di ridurne la dimensione anche svuotandola.
Tant'è che su Zabbix, ad esempio, ho messo in cron un bel DROP TABLE per rimpicciolire la tabella history, visto che il suo housekeeper nonostante rimuova record ogni giorno, non riesce a liberare spazio. Domani ne valuto la conversione in myisam.
 
Ma a parte questo, c'è modo di liberare spazio disco cancellando dati da una tabella innodb?

 tabella innodb?
 
OPTIMIZE TABLE
ciao
 
-- 
************** (.)_(.) *******************
Un amico ï¿œ uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 di troncare la tabella dei log dopo un po di tempo.
 
Cioè non ti sei mai accorto che ti sono spariti qualche decina di TB di
spazio? Ma cos'hai, dischi a capacità infinita?

 OPTIMIZE TABLE
 
No. Questo ottimizza gli indici, ma non libera lo spazio inusato.
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 No. Questo ottimizza gli indici, ma non libera lo spazio inusato.
 
Dici. Il mio inglese e' tutt'altro che buono ma dal manuale on line 
leggo "You can use OPTIMIZE TABLE to reclaim the unused space and to 
defragment the data file". Quel "reclaim the unused space" non vuol 
dire liberare lo spazio non usato?
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,


 liberare lo spazio non usato?
 
Certamente non era così fino alla 4.1, magari con la 5 è cambiato 
qualcosa. Non ho sottomano un mysql da testare, comunque non mi risulta 
che il bug sia chiuso.
http://bugs.mysql.com/bug.php?id=1341
 


 spazio? Ma cos'hai, dischi a capacità infinita?
 
No perchè la partizione con MySQL è in comune con quella dove bacula salva i backup e visto ogni giorno lo spazio crolla non ci ho mai dato peso.
 
ma non è un problema eh, lo faccio finire solo per curiosità, tanto domani tronco la tabella, averla riparata non mi cambierebbe nulla.
 
Comunque non sono decine di tera, ma "solo" centinaia di giga.

 
http://bugs.mysql.com/bug.php?id=1341
 
 
Nemmeno con la 5 si riesce a far stringere il file.
Lo dico perchè io ho la 5.qualcosa ovunque, molte delle quali Percona, ed innodb cresce solo.
 
Se qualcuno avesse una soluzione son tutto orecchi.

 una tabella innodb?
 
Usi un datafile per tabella (invece di grossi datafile cumulativi come da 
configurazione di default) e vai di OPTIMIZE TABLE
 
Enrico

 Comunque non sono decine di tera, ma "solo" centinaia di giga.
 
Ah beh, questo cambia tutto, eh :D
 
Enrico

 posizionato all'altezza dei testicoli
 
Tanto per curiosita', a cosa e' dovuto tutto questo astio ?
 
 
-- 
Stefano L.

 configurazione di default) e vai di OPTIMIZE TABLE
 
Uso già un file per tabella, ma l'optimize non stringe.

 Se qualcuno avesse una soluzione son tutto orecchi.
 
Per zabbix (su MySQL con innodb) ho adottato una soluzione di 
partitioning, ogni giorno č salvato su un unico file della partizione e 
ogni giorno creo le nuove partizioni ed elimino quelle vecchi. Cosě 
volente o nolente lo spazio viene liberato.
Una soluzione analoga con qualche adattamento credo possa essere usata 
per qualunque tabella con timestamp


Suppongo al fatto che MyISAM non è acid compliant e ai lock a livello di 
tabella.
 
-- 
BOFH excuse #315:
 
The recent proliferation of Nuclear Testing

 per qualunque tabella con timestamp
 
Buona idea.
comunque, a me pare una clamorosa ca..ata da parte degli sviluppatori di Zabbix non aver previsto che l'housekeeper notturno non avrebbe liberato un singolo byte, visto che di default fanno tabelle innodb (se non ricordo male eh, perchè ci ho smanettato non poco per adattarlo alla mia infrastruttura)
 
IMHO, dovevano partizionare di default in fase di installazione.

 IMHO, dovevano partizionare di default in fase di installazione.
 
Sě in effetti sarebbe stato parecchio "smart" ma se non ricordo male il 
partitioning su mysql č stato introdotto dalla 5.5
 

 partitioning su mysql è stato introdotto dalla 5.5
 
e vabbè, allora in tal caso non usare innodb per una tabella che diventa di dimensioni ciclopiche. Un po come dire: io ti creo la tabella in innodb perchè mi piace di più, ti metto un housekeeper che cancella i dati, ma il file resterà comunque grosso e ti attacchi.
 
Boh.

 
Il partitioning c'? sicuramente anche nella 5.1

 Che tradotto significa: un sacco di righe.
 
Storage limits : 256TB - avoja :)

 Storage limits : 256TB - avoja :)
 
Vacca boia.
 

 Comunque non sono decine di tera, ma "solo" centinaia di giga.
 
Umh? Mi sto perdendo qualcosa nei conti? Se il nr. di record che hai
postato è corretto, ipotizzando per assurdo 10 byte per record:
 
983.606.622.580 * 10 = 983.606.622 * 10 KB = 983.606 * 10 MB = 983 * 10
GB = 9 TB e rotti.
 
O mysql ha qualche funzionalità per memorizzare i dati in modo compresso?

 O mysql ha qualche funzionalitï¿½ per memorizzare i dati in modo compresso?
 
Non ne ho idea.

 Uso già un file per tabella, ma l'optimize non stringe.
 
Mmm... Ricordavo male... Comunque sia, perche` vuoi recuperare spazio? 
Cioe`, capisco una situazione estrema come quella da te riportata, ma 
pensare di definire una tabella di e.g. 20Gb e poi troncarla nel momento in 
cui supera e.g. 20-5Gb direi che sia una buona strategia di allocazione 
dello spazio, non foss'altro per il fatto che riduci eventuali lag dovuti al 
ridimensionamento del datafile da parte del file system
 
Enrico
P.S. e` ovvio poi che un drop table + create table risolve sempre, eh :)

 Il partitioning c'? sicuramente anche nella 5.1
 
Il partitioning lo emuli pure, eh
 
Enrico


 
manco in war games
 
:-)
 

 ridimensionamento del datafile da parte del file system
 
Forse non ti seguo.
Stai dicendo che è giusto far crescere la tabella all'infinito?
Scusa ma che dischi hai te? Da milioni di terabyte ad espansione dinamica?

 Stai dicendo che è giusto far crescere la tabella all'infinito?
 
No, sto dicendo di dimensionare la tabella ad una determinata dimensione 
(e.g. 20Gb) e di troncarla nel momento in cui raggiunge e/o supera una 
determinata dimensione che pero` rientra nel dimensionamento iniziale (e.g. 
15Gb, ovvero ti tieni 5Gb come "spazio di manovra")
 
Enrico

 15Gb, ovvero ti tieni 5Gb come "spazio di manovra")
 
Può andar bene nel mio caso, ma in linea generale, reputo sia una grossa limitazione di innodb. Utilizzare una tabella innodb per salvare dei dati 'veri' e non dei log che possono essere rimossi a piacere, sapendo di non poter ma rimpicciolire la tabella senza operazioni invasive (truncate, dump+truncate+restore), è una gigantesca limitazione.
 
Non riesco a credere che innodb non si restringa cancellando righe.
E' surreale.

 E' surreale.
 
 
Io trovo surreale tutto 'sto thread, sinceramente. Ma tant'è... ;-)
Il problema non è esattamente come lo dipingi.
 
Prova a leggere questo (commenti e relativi link compresi):
 
http://jeremy.zawodny.com/blog/archives/010504.html
 
 
Ti si aprirà un mondo ;-)

 Ti si aprirà un mondo ;-)
 
Bisogna comunque andare a smanettare sulle tabelle.
Dover modificare la struttura di una tabella per rimpicciolire le dimensioni
non è una soluzione, ma un workaround.

 surreale.
 
Questa frase mi suona come:
Non riesco a credere che ext3 non si restringe cancellando file. E' 
surreale.
In questo ipotetico caso la risposta e' semplice un filesystem non 
funziona cosi', nel tuo caso la risposta e' la stessa: un file di storage 
fisico di un DBMS non funziona cosi'.
 
Ciao.
 
PS La risposta di Enrico e' un approccio corretto.
 
Tannone Raffaele.

 Non riesco a credere che innodb non si restringa cancellando righe.
 
Credici, anche perche` non e` l'unico motore di database ad avere questo 
comportamento. Riflettici bene, quanto sarebbe oneroso rilasciare lo 
spazio occupato dalla tabella ogni volta che la svuoti e richiederlo ogni 
volta che la riempi? La strategia migliore in questo caso e` proprio quella 
adottata da innodb, sia in modalita` datafile unico (imposti una dimensione 
fissa al datafile e lui se ne crea quanti glie ne servono), sia in modalita` 
un datafile per tabella (la dimensione viene sempre aumentata e mai 
esplicitamente rilasciata). Se proprio vuoi seguire per la tua strada, oltre 
al suggerimento che ti ho dato, puoi fare un ALTER TABLE tabella ENGINE = 
MyISAM; ALTER TABLE tabella ENGINE = InnoDB; che non fa altro che 
ricostruire la tabella ma avente come side effect il fatto di 
ridimensionarla
 
Enrico

 esplicitamente rilasciata). 
 
Però MyISAM allora risorse ondemand, quindi un qualche sistema ci sarà...
Bada bene, non è un flame, son proprio curioso di capire come mai MyISAM riesce ad 'adattarsi' mentre InnoDB può solo crescere.
 
 
Per l'esempio con il filesystem: non credo calzi. Su FS se io creo un file con 10 righe, poi ne cancello 5, il file si restringe.
 
Anche gli mdb di access non si restringono? Non lo sapevo, non ci ho mai fatto caso.

 ridimensionarla
 
Quest'ultima possibile non è praticabile in molti casi. Se hai delle foreign key o le spacca tutte (no buono!) o semplicemente non converte. Non so come si comporti MySQL in questi casi.

 mai fatto caso.
 
Parlare di MyISAM e Access in ambito database � un po' come trattare i
trilobiti in etologia...
 
 

 trilobiti in etologia...
 
Ma questo non è un thread sui database, se ci fai caso è un thread senza capo
ne coda, che ho aperto dopo aver visto che diavolo succede facendo crashare un database bacula con moooooooooooooolti log mai rimossi.
 
Non ha alcuno scopo, non è nulla di più che un insieme di chiacchere da bar.

  non converte.
 
Se ho delle foreign key non uso MyISAM (che, se non ricordo male e quindi 
potrei comunque sbagliarmi, non le supporta) :D
 
Enrico

 potrei comunque sbagliarmi, non le supporta) :D
 
Appunto: tu dici che per restringere la soluzione è fare una alter table passando da InnoDB a MySQL per poi tornare su InnoDB.
 
Se hai delle foreinkey (la base di partenza è innodb, quindi puoi averle benissimo) e fai una alter table verso myisam, o il server le spacca tutte, oppure non converte. In ambo i casi, non è una soluzione valida.

 tutte, oppure non converte.
 
Ovvio, ma io non parlavo di una situazione generica, ma della tua :D
Seriamente, il tuo e` in parte un non problema, in quanto difficilmente 
(molto difficilmente) ci sono altri contesti in cui si tende a dare 
importanza alla dimensione della tabella su file system (c'e` comunque da 
dire che io ragiono spesso e volentieri in ottica datawarehouse)
 
Enrico

 Però MyISAM allora risorse ondemand, quindi un qualche sistema ci sarà...
 
Grazie al cappero, MyISAM e` piu` paragonabile ad un file indicizzato che ad 
un sistema di database. Di conseguenza, non mi stupisce il fatto che abbia 
un comportamento del genere
 
Enrico

 dire che io ragiono spesso e volentieri in ottica datawarehouse)
 
A ok. Ma non prendere come esempio il mio "non problema".
So bene che la mia situazione è perfettamente evitabile, ma il database il
questione non ha alcuna importanza (tant'è che io backuppo tutto tranne quella
tabella), ho fatto finire il myisamchk giusto per curiosità, potevo in 
qualunque momento interrompere, cancellare i file, avviare mysql e ricreare al 
tabella vuota. Avrei impiegato 1 minuto invece di una settimana.
 
No, non prendere questo esempio come caso.

 
http://bugs.mysql.com/bug.php?id=1341
 
 
Ciao,
magari a qualcuno interessa.
Oggi ho avuto modo di verificare quanto detto. Memore di questo vecchio 
post ho voluto verificare.
- Dump dei dati antecedenti ad una data
- Delete dei dati antecedenti alla suddetta data
- optimize della tabella
 
Le dimensioni dei file fisici contenente la tabella si sono ridotte 
contestualmente.
OS: Centos 5.8
Mysql: 5.0.1 (mi pare)
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 contestualmente.
 
Sicuro fosse InnoDB :)

Il 23/11/2012, 
gandalf.co...@gmail.com
 ha detto :

Ehm. MyISAM. Sorry ;-(
