Citazione:
Ah! quindi le ripartenze non sono da cron, ma da un qualche tool di monitoraggio. Sono rimasto indietro sul mysql... Quale per curiosita? E su quali parametri decide la ripartenza?
PS O forse crasha tutto il server e c'e' un watchdog che lo fa ripartire? C'e' un adagio sempre valido e non tanto stupido: when it crashes there is a bug
Non viene fatto il riavvio sistematico del database ogni x secondi o minuti via cron, io con "crash" non intendevo il crash completo del server, ma il crash dei singoli figli.
Di fatto questo crash non ha conseguenze globali ma genera, come suppongo, il fatidico errore, ed eventualmente una corruzione della tabella se in update.
Più o meno frequentemente tutti i figli muoiono, per intenderci, nell'error log:
Citazione:
Number of processes running now: 0
031103 16:34:01 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.16-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306
Number of processes running now: 0
031103 18:09:01 mysqld restarted
/usr/sbin/mysqld: ready for connections.
Version: '4.0.16-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306
E la distanza tra i due restart, evento totalmente autonomo e non forzato da alcunchè, può variare molto, a volte si arriva anche a giorni come anche a minuti.
Il crash completo del database è sì un evento che si verifica, ma è relativamente raro.
Nel caso peggiore se ne verificano 3 o 4 la settimana, mediamente 1 ogni 15 giorni, su alcuni server addirittura 1 ogni 2 mesi o mai per alcuni periodi di tempo.
Esiste comunque un sistema di monitoraggio (sviluppato in casa) che tiene d'occhio il database e, in caso di crash completo o comunque stallo lo riavvia autonomamente entro 4 minuti
Citazione:
Bisognerebe avere a disposizione il show full processlist per analizzare bene il problema, se il problema 'server has gone' e' dovuto alle ripartenze, e le ripartenze sono dovute a 'too many connections', allora la causa e' quest'ultima, altrimenti...
'server has gone' e' un problema che riguarda un singolo child di mysql, che muore (ma forse perche' e' stato killato insieme a tutti gli altri per una ripsrtenza). 'too many connections' e' un problema di stallo generale, tutto il servizio smette di ridpondere.
Proprio in base a quello che ho scritto sopra il problema, amio parere, non riguarda tanto uno stallo generale ma sembrerebbe relativo al sigolo processo, proprio perchè se di stallo generale si trattasse il sistema di monitoraggio riavvierebbe il database molto più spesso, inoltre quando si ha un riavvio viene anche loggato l'eventuale messaggio d'errore restituito da una query di prova, ed esso è in genere il classico "Can't connect to local MySQL server through socket 'xxx' (2)".
Citazione:
Una query cattiva puo' essere una che inserisce una immagine in un blob... Alzare il max_allowed_packets e' la soluzione prima da provare
L'inserimento di immagini o di dati binari nel database può essere senz'altro una possibile causa, sebbene questo genere di appicazioni, siano piuttosto di "nicchia" su AlterVista, senz'altro comunque sarà provata anche questa possibilità.
Sottolineo però che tale errore si manifesta anche con query poco impegnative su basi di dati relativamente piccole.
Citazione:
Forse confrontando il setup in uso sulla versione 3 e quello attuale si puo' capire qualcosa....
Purtroppo il setup è proprio ricalcato su quello vecchio, sono state aggiunte alcune impostazioni per abilitare la query cache, non disponibile nelle vecchie versioni, skip-name-resolve e adeguati parametri in base alla crescente disponibilità di memoria, nulla di più :?