
“Pensavamo foste morti.”
Gia’, lo pensavamo pure noi.
Facciamo un resoconto dei casini avvenuti in questo periodo, per far capire che realmente non siamo stati fermi 4 MESI per niente.
Aitch era hostato direttamente su di un VPS che gestivo direttamente (4 core, 2GB di RAM) Debian 6 pulito, NginX e poche altre cose.
A quanto pare sono stato uno dei pochi “fortunati” ad avere un bug con GRUB+RAID10, per cui ad un certo punto dopo un riavvio non partiva piu’ il VPS.
Faccio il backup a mano di /var/lib/mysql/ per non perdere l’ultimo articolo che stavo scrivendo e formatto direttamente il VPS.
Il backup per sicurezza lo copio su 3 vps diversi. Nella stessa webfarm. (yeah, my fault)
Ora, finisco di configurare il VPS appena formattato e me ne vado a dormire, era notte tarda.
La mattina mi sveglio, accendo il pc—– no, rettifico: non parte.
Sono in ufficio, sono le 8.30 e sono li’ a guardare lo schermo nero del mio portatile.
Oh dimenticavo: due settimane prima un cliente molto gentile aveva cosparso il mio portatile di veleno per formiche dato che l’avevo poggiato per 5 minuti su di un muretto mentre ero sopra un tetto a sistemare una antenna WiMAX.
Gia’.
Pensavo di averlo pulito adeguatamente con alcool ma a quanto pare qualcosa era andato storto.
Previsti gli “almeno 3 mesi di attesa” dell’assicurazione Asus, mi prendo un nuovo portatile.
Lo riconfiguro, installo tutti gli strumenti di lavoro e per un po’ tralascio Aitch. Troppe altre cose da sistemare.
Passa circa un mese, un mese e mezzo.
Decido di provare a ricaricare il backup sul VPS di Aitch ma qualcosa va storto.
Non riesco a raggiungere i 3 VPS dove avevo caricato i backup. Chiedo spiegazioni alla webfarm (qualcuno gia’ sta’ iniziando a capire di che webfarm si tratti?) ma noto che molti altri avevano questi problemi.
Diciamo circa.. 95% di packet loss inviando pacchetti di 64byte.
Pare che la compagnia fosse sotto DDoS, allora per un po’ tralascio ancora Aitch, non si riusciva a fare nulla in quel periodo da quei VPS.
La compagnia torna up, “stabile”, e per un po’ mi dimentico addirittura di ricaricare il backup (ormai erano passati due mesi e mezzo..)
Torna il tempo libero, torna la voglia di fare e decido di ripristinare Aitch.
Mi collego ad un VPS ma va estremamente lento.
“Mah, sara’ stato acceso per troppo tempo, li riavvio tutti per sicurezza—”
Morti. Tutti e 3 i VPS.
Vado in panico e cerco di capire cosa sta succedendo.
La webfarm (ora suvvia, dovreste avere capito chi. suggerimento? C@C) aveva notato una possibile vulnerabilita’ del loro sistema di storage, per cui si stava sbrigando a sostituire tutto con un sistema failproof.
Ovviamente il sistema di storage e’ collassato quando erano al 90% del completamento dell’operazione.
Ovviamente i miei 3 VPS erano nel 10% degli storage non ancora failproof.
Su uno dei 3 VPS (NDA: il 2°) fortunatamente si riusciva ancora ad accedere alla console, era stralenta ma si accedeva.
Avvio in modalita’ di ripristino e ovviamente, crasha.
Avvio in init=/dev/sh con tutto montato RO.
Rimane connesso circa 2 minuti e collassa.
In 10h ho ripristinato ben 42MB di dati. Fortunatamente, tutti quelli che mi servivano.
Essendomi rotto pesantemente gli zeri binari ed avendo un server dedicato di un cliente che: “no.. mi son ricordato che non ne ho bisogno.” formatto tutto, ed inizio a ripristinare nel server dedicato.
Ah che gioia e che gaudio, che velocita’ (8 core @2GHz+ 16GB di RAM @1600MHz) comparato ad un VPS ero felicissimo.
Importo il backup e…
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size InnoDB: 512 pages (rounded down to MB) than specified in the .cnf file: InnoDB: initial 640 pages, max 0 (relevant if non-zero) pages!
WTF.
Controllo. ibdata1 e’ di 8 MB, contro i 10MB definiti dal my.cnf
Controllo il checksum ed effettivamente e’ proprio cosi’, ibdata1 non e’ danneggiato ed e’ 8MB.
Allora modifico il my.cnf impostando ibdata1 a 8mb di size e finalmente…
140723 12:58:50 InnoDB: Error: tablespace size must be at least 10 MB 140723 12:58:50 [ERROR] Plugin 'InnoDB' init function returned error. 140723 12:58:50 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140723 12:58:50 [ERROR] Unknown/unsupported storage engine: InnoDB 140723 12:58:50 [ERROR] Aborting
Ma che ca.. Oh well.. allora mi state prendendo in giro.
Controllo in giro e nessuno sa’ come risolvere.
Inizio a studiarmi la configurazione di innodb e finalmente trovo:
The COMBINED size of data files must be at least 10MB.
AHA! Ci siamo dunque!
Ri-eseguo una installazione pulita di mysql, reimporto il tutto, salvo il backup di ibdata1 come ibdata2 lasciando l’ibdata1 creato in automatico dall’installazione pulita.
Aggiungo nel my.cnf:
innodb_data_file_path = ibdata1:10M;ibdata2:8M:autoextend
Salvo, avvio mysql e finalmente…
140723 14:23:54 InnoDB: Error: tablespace size must be at least 10 MB 140723 14:23:54 [ERROR] Plugin 'InnoDB' init function returned error. 140723 14:23:54 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140723 14:23:54 [ERROR] Unknown/unsupported storage engine: InnoDB 140723 14:23:54 [ERROR] Aborting
…No, no no no no.
Lampo di genio momentaneo: sostituiamo ibdata1 con ibdata2.
Li sostituisco, li scambio nel my.cnf e avvio mysql incrociando le dita…
Funziona.
Gaudio e gioia.
Effettuo il dump .sql di tutti i database:
mysqldump -u root -p --all-databases > aitch.sql
Faccio pulizia della cartella /var/lib/mysql/, reinstallo sql pulito, reimporto il backup:
mysql -u root -p < aitch.sql
Aand… We’re online.
Non ho mai sofferto cosi’ tanto per un fottuto backup SQL.
Comunque si, vi vogliamo bene anche se siete stati adottati e nessuno vi ama.
A presto nuove news firmate Aitch.
P.s.: si, ora ho distribuito i backup su diversi altri PC.
P.p.s: si, ora Aitch. e’ su di un server dedicato.
Peace.