Ieri sera la tabella wp_posts di questo blog ha deciso di andare in sciopero. Di colpo è diventata di 0kb. Dopo i primi momenti di panico, corredati da fantasticherie su possibili attacchi lamer ricevuti (grazie ad Andrea per avermi sopportato), è tornata la ragione e con lei la soluzione del problema.

L’errore restituito all’accesso alla tabella wp_posts era:

Messaggio di MySQL:

#144 – Table ‘./Sql130140_2/wp_posts’ is marked as crashed and last (automatic?) repair failed

Un primo, classico:

REPAIR TABLE wp_posts;

non ha funzionato. Positivo invece il secondo tentativo:

REPAIR TABLE wp_posts use_frm;

con il quale in tempo zero, come era sparito, tutto il contenuto di wp_posts è tornato.

Come potrete notare i due statement differiscono per il finale, che nel caso del REPAIR vincente comprende “use_frm”.  La differenza stà nel fatto che mentre il semplice REPAIR TABLE <nometabella> tenta di riscostruire unicamente i file di indice, il REPAIR TABLE <nometabella> use_frm è più viscerale: ricrea da zero l’header della tabella. Il risultato è una riparazione più efficace, ma pure più rischiosa, da usare unicamente nel caso in cui l’header della tabella risulti corrotto. Nel mio caso specifico un sintomo di header corrotto era il fatto che il campo “Records” della tabella wp_posts restituisse come valore ~0 al quadrato, decisamento poco credibile.

Tutto risolto dunque, se mai vi capiterà qualcosa di simile, questa può essere una soluzione.

Dai visibilità al problema: