Categorie
sviluppo

“mysql has gone away” durante importazione

Da pochi giorni ho cambiato notebook e un pezzo alla volta sto migrando tutto sul nuovo sistema.
Tra le tante cose da portare avevo anche i database dei progetti dei quali ho fatto sviluppo in locale.

Ho deciso di esportarli tutti con un’unico dump e fin qui tutto bene (circa 1gb di dati):
mysqldump -u root -p --all-databases > alldb.sql

Trasferisco da un macchina all’altra e quando provo ad importarli ricevo un bellissimo: mysql has gone away.

mysql-has-gone-away

Ricordo che in passato avevo avuto un problema simile che avevo risolto modificando il timeout.
Breve ricerca su google e aggiungo queste 3 righe nel file di configurazione impostando i valori ben oltre i valori di default.


wait_timeout = 128800
connect_timeout = 120
interactive_timeout = 128800

Il risultato non cambia: mysql has gone away.
Aumento ancora ma nulla…

Prendo in considerazione di esportare i database uno alla volta ma sono più di 50 e non ne ho voglia…

Ricontrollo l’errore e vedo che si ferma sempre alla stessa riga.
Apro il dump e vado a vedere: si tratta di una INSERT multipla molto (molto) lunga.

Scorro le altre variabili presenti nel file di configurazione ed ecco davanti a me la causa del problema:
max_allowed_packet = 1M

Questa variabile globale imposta la dimensione massima dei pacchetti e nel mio caso era troppo piccola per quella query estramamente grossa.
La porto da 1 a 5M, riavvio il servizio e lancio l’importazione che questa volta arriva al fondo senza problemi.

La prossima votla spero di ricordami di aver scritto qui la soluzione…

Illustrazione di Elena Triolo

Categorie
tutorial wordpress

5 nuovi indici per le tabelle di wordpress

Seguendo alcuni suggerimenti di un essere illuminato, sto lentamente mettendo in pratica quanto ascoltato durante l’ iWordCamp.

Mi appunto quindi i comandi da lanciare in modo non dovermi ricordare la sintassi ed evitare refusi…

CREATE INDEX autoload ON wp_options (autoload);
CREATE INDEX post_date ON wp_posts (post_date);
CREATE INDEX post_date_gmt ON wp_posts (post_date_gmt);
CREATE INDEX parent ON wp_term_taxonomy (parent);
CREATE INDEX name ON wp_terms (name);

In alcune installazioni il nome delle vostra tabelle potrebbe essere diverso… verificate quindi prima se avete usato un prefisso.
(file wp-config var $table_prefix)

Mi verrebbe anche voglia di scrivere un piccolo plugin per rendere il lavoro ancora più veloce, ma mi sembra una roba troppo banale.

N.B.
L’applicazione di questi indici è applicabile solo nel caso abbiate una versione di wordpress 2.3 o superiore.

Già che si sono segnalo anche questo script che suggerisce ulteriori tuning per il vostro database server preferito (via giorgio)

Categorie
tutorial

MySQL, indici FullText e la lunghezza delle strighe

Avete mai provato a cercare su un indice FullText con una stringa sotto i 4 caratteri ?

select * from tabella where match (nomecampo) against (‘abc’);

Bhe, io dopo essere diventato scemo, ho scoperto che per default la lunghezza minima è impostata a 4 caratteri.

MySQL, indici FullText e ricerca sotto i 4 caratteri

Se quindi state cercando stringhe come “php“,”htm” o “css“, e nonostante siate sicuri che ci siano riscontri, la ricerca non vi restituisce nessun record, non è dovuto ad una tabella corrotta, ma molto più semplicemente perché l’indice in condizioni normali non gestisce ricerche di questo tipo.

La soluzione, se siete nelle condizioni di modificare il file di configurazione, fortunatamente c’è, e prevede 3 operazioni

  1. E’ necessario definire il valore della variabile ft_min_word_len all’interno del file my.cfg
    ft_min_word_len=3
  2. Riavviare il server in modo che valorizzi in modo corretto la nuova impostazione
  3. Per finire, è necessario fare il rebuild degli indici, in modo che vengano ricostruiti con tutte le informazioni corrette
    REPAIR TABLE nometabella QUICK;

Facile come bere un chupito… basta saperlo.

Per la documentazione ufficiale basta guardare qui

Categorie
bho en ?

mysql backup via mail

Dopo la disavventura di qualche giorno fa ho migliorato un po’ le mie procedure di backup relative ai database mysql, apportando qualche modifica agli script su crontab; questo è quello che “prodotto

mysqldump -u[utente] -p[password] [nomedatabase]| gzip --best -c > [nomedatabase].sql.gz && (date && echo "backup mysql" && uuencode [nomedatabase].sql.gz ) | mail [miamail@dominio.ext] -s "backup mysql"
(qui trovate la gist su github)

In pratica mi mando via mail, le istruzioni per ricreare il db avendo prima cura di comprimerle.

Essendo il comando un po’ lungo, avrei potuto fare uno script per poi eseguirlo, ma la potenza della shell è anche questo: concatenazione e reindirizzamento di comandi.

In reatà se scomponiamo i problemi è molto più semplice di quello che sembra.

Parte uno: con mysqldump genero le istruzioni SQL che permettono di ricreare il database.

mysqldump -u[utente] -p[password] [nomedatabase]

Parte due: raccolgo lo STDOUT e lo passo a gzip che si occupa di comprimerlo e salvarlo

| gzip –best -c > [nomedatabase].sql.gz

Parte tre: aspetto che gzip finisca il suo lavoro e se va tutto bene ( && ) preparo il contenuto della mail
( essendo il file compresso in formato binario uso uuencode allegarlo alla mail )

&& (date && echo “backup mysql” && uuencode [nomedatabase].sql.gz wordpress.sql.gz)

Parte quattro: passo la stringa precedentemente creata al comando mailche infine si occupera di recapitarla nella mia casella di posta

| mail [miamail@dominio.ext] -s “backup mysql”

Se qualcuno ha idee per migliorare quanto scritto mi faccia sapere …

Link di riferimento: mysqldump, shelldorado

[tags]mysql,backup,shell[/tags]