.:: Maurizio Pelizzone ::.

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…

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)

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

Bhe, io dopo essere diventato scemo, ho scoperto che per default la lunghezza minima è impostata a 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

Technorati: database, mysql, full-text search
BlogBabel: database, mysql, full-text search

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“

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.

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

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 )

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

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

Link di riferimento: mysqldump, shelldorado

Technorati: mysql, backup, shell
BlogBabel: mysql, backup, shell

Questa notte qualche “simpatico personaggio ( )”, ha deciso che doveva farmi vedere quanto fosse bravo a fare l’ hacker il cracker.

La sua attenzione è stata focalizzata sul database delle statistiche di PHPstatsche non so se grazie ad un Exploit o ad un attacco brute force ha ceduto miseramente. ( )

Questo è quello che mi sono trovato difronte questa mattina:

(clicca per ingrandire)

Dopo un attimo di sconforto, ho pensato ai backup … ” Ok, nessun problema, li faccio tutte le notti …”

Con un operazione durata circa 20 minuti, mi collego al server di backup, li scarico in locale, fermo il demone di mysql, li ripristino e rifaccio partire mysql ….

Bene, tutto a posto mi dico, ma quando mi ricollego mi rendo conto che il problema è rimasto e realizzo che non so fare i backup.

O meglio, il backup c’è ma viene sovrascritto ogni notte, ed in questo caso, il simpatico personaggio aveva smanettato prima dell’ora x.

Il risultato è che ho perso le statistiche ma dato che è inutile “piangere sul latte versato” vediamo i lati positivi:

• E’ successo a me e non ad un cliente
• Si tratta delle statistiche di un blog … (quindi niente di vitale)
• Ho migliorato la procedura di backup
  ( gestione settimanale, ed invio dump mysql via mail )
• Mi sono reso conto che phpstats è bacato
  ( sarà il caso di cambiarlo ???? )

Se poi vogliamo dirla tutta, per vari motivi, nel corso del tempo ho implementato statistiche anche con Analitycs , Reinvigorate e 103bees quindi il danno è relativamente marginale.

Certo, mi spiace in quanto con phpstats avevo dati da oltre un anno, ad era bello vedere l’andamento degli accessi sempre in crescita, ma questa è la giusta punizione a chi non fa i backup (almeno questo è quello che dico sempre ai miei clienti)

Penso che con l’occasione passerò a mint; è già da un po’ che ci penso ma per vari motivi o sempre rimandato.

Technorati: phpstats, backup
BlogBabel: phpstats, backup

Oggi ho scoperto che usando questi driver per la connessione ad un database MySQL all’interno di una pagina .aspx, nel caso di una SELECT su campo di tipo Text , TintText , MediumText o LongText invece di restituire una stringa restituiscono un insieme di byte.

Se si utilizza un DataReader è possibile convertire in stringa utilizzando il metodo GetString ( credo messo a disposizione proprio per questo) , che però accetta come argomento solo l’indice del campo. Nel caso volessimo utilizzare il nome del campo possiamo ricorrere ad un altro metodo GetOrdinal, che ci restituisce un integer con l’indice della posizione del campo. ( fonte )

Inizialmente l’ho interpretato come un errore del driver ma in realtà ho imparato che MySQL internamente tratta questi campi come array di byte, e quindi, anche se non condivido la scelta dello sviluppatore, si è scelto di restituire lo stesso tipo.

I problemi si complicano se voglio lavorare con un DataTable preparato da un DataAdapter, infatti, anche se internamente viene usato un DataReader, le righe non vengono generate correttamente.

Dopo diverse ricerche, numerosi tentativi falliti e dopo qualche capocciata, ho deciso di aggirare il problema cambiando semplicemente i driver usati per la connessione e passando quindi all’utilizzo dei Connector/Net sviluppati direttamente da MySQL AB.

Fortunatamente le modifiche sono state minime essendo i nomi dei metodi praticamente identici. In pratica ho sostituito le chiamate a MySQLDriverCS trasformandole in MySql.Data.MySqlClient ed ho cambiato il formato della stringa per la connessione.