Indice dei contenuti dell'articolo:
Una delle casistiche poco conosciute all’utente finale di un sito Web è quello inerente a problemi di disponibilità del sito che avvengono quando il server esegue il backup del database MySQL.
Anche se le attività di manutenzione e backup sono tipicamente pianificate durante le ore notturne, momento in cui ci si aspetta che il flusso di traffico sia minimo e che il carico sul server sia di conseguenza inferiore, può sorgere una questione particolarmente rilevante. Cosa succede, infatti, se proprio in quel preciso intervallo temporale i crawler di Google stanno attraversando il tuo sito per scansionare i nuovi contenuti e procedere alla loro indicizzazione?
Se il backup è stato progettato con cura, utilizzando le tecnologie più adeguate e tenendo in considerazione la dimensione del dataset su cui operare, tutto dovrebbe svolgersi senza intoppi. Google avrà modo di scansionare correttamente il tuo sito, rilevare i nuovi contenuti e successivamente procedere alla loro indicizzazione. Tuttavia, se il backup non è stato progettato e realizzato in maniera ottimale, le conseguenze potrebbero essere ben diverse.
In uno scenario meno favorevole, il crawler di Google si troverebbe di fronte a una serie di errori del tipo 500, problematiche che indicano un malfunzionamento del server. In tali circostanze, una volta esaurito il cosiddetto “crawling budget”, ovvero la quantità di risorse che Google destina alle operazioni di crawling sul tuo sito, il crawler si ritirerebbe senza aver avuto l’opportunità di recuperare e indicizzare i nuovi contenuti. Ancora più problematico, il crawler avrebbe registrato una serie di errori del tipo 500, circostanza che potrebbe avere un impatto negativo sul posizionamento del tuo sito nei risultati di ricerca.
Questo è particolarmente vero nel medio-lungo termine, dato che un elevato numero di errori, che si traduce in un alto “error ratio”, potrebbe effettivamente compromettere la visibilità e la reputazione del tuo sito web agli occhi dei motori di ricerca. In tal senso, diventa quindi fondamentale garantire che le operazioni di backup siano realizzate con la massima attenzione, prendendo in considerazione tutti gli aspetti tecnici e logici, al fine di evitare inconvenienti e garantire la corretta e costante indicizzazione del sito da parte di Google.
Ma perché avviene questo?
Per comprendere pienamente le ragioni alla base di questi problemi – situazioni che, pur non essendo particolarmente frequenti, non sono nemmeno così sporadiche – è fondamentale analizzare le modalità standard di operatività di un hosting provider. In particolare, dobbiamo focalizzare l’attenzione su come avviene la gestione dei backup a livello di server, e ancor di più, sulle dinamiche specifiche che intervengono nel momento in cui l’hosting provider procede a effettuare il backup del database del nostro sito web.
Supponiamo, ad esempio, di trovarci di fronte a una circostanza in cui, mentre l’hosting provider sta copiando i dati, giunge al nostro sito una richiesta. Questa richiesta, processata tramite il linguaggio di scripting PHP, risulterà nell’esecuzione di numerose query SQL dirette verso il database. Che cosa succede in un contesto del genere?
In una situazione contraddistinta da un’ottica di pura e semplice inefficienza, ciò che otterremmo è un backup “sporco”, reso inconsistente da queste azioni. Immaginiamo, ad esempio, che nel preciso istante in cui viene eseguito il backup, noi procediamo a un aggiornamento di un nuovo record all’interno della nostra ipotetica tabella anagrafica, ma senza conseguentemente registrare il corrispondente record nella tabella dedicata al codice fiscale. Di conseguenza, otterremmo un backup che non rispecchia la realtà dei fatti, essendo mancante di un elemento critico.
In una realtà più ordinata e gestita in modo standard, il sistemista o il pannello di controllo avrebbero la responsabilità di eseguire l’utility “mysqldump”, sfruttando i parametri di locking. Questi parametri consentono di bloccare le tabelle sia in lettura che in scrittura durante l’esecuzione del backup, garantendo così un dump del database che sia integro e coerente. Tuttavia, questa operazione presenta delle controindicazioni, come la generazione di problemi di locking, ovvero il blocco delle risorse durante il processo. Il risultato? Le query non potrebbero essere completate nel tempo prestabilito dal web server, causando nella migliore delle ipotesi un timeout, o addirittura “appendendo” il crawler per svariati secondi e generando timeout sul lato del crawler stesso.
Tuttavia, si possono evitare tali situazioni problematiche grazie a una serie di precauzioni specifiche. E’ fondamentale una valutazione oculata dello scenario in cui ci si trova, considerando variabili come la tecnologia impiegata, la dimensione del dataset, il tipo di tabelle coinvolte e, non da ultimo, il budget a disposizione del cliente. In tal modo, si potrà pianificare con tranquillità la soluzione migliore e più adatta, che rispetti le esigenze economiche del cliente.
Backup MySQL tramite mysqldump
L’uso di mysqldump per il backup di MySQL è forse il metodo più semplice e diffuso, sebbene sia spesso considerato improprio. La sua popolarità può essere attribuita al fatto che mysqldump fa parte dei programmi client di MySQL, risultando quindi installato di default. Questo strumento permette di realizzare backup logici e ha la capacità di eseguire il backup di tutti i database, di un singolo database, di tutte le tabelle o di una o più tabelle all’interno dello stesso database. Il dump viene poi inviato all’uscita standard, permettendo così di trasferire l’output ad altri programmi per l’interoperabilità. Per esempio, è possibile collegare l’output a gzip per la compressione dei dati, dal momento che mysqldump non offre una funzionalità di compressione incorporata.
La criticità più evidente di mysqldump è la sua lentezza quando si tratta di gestire grandi database. Questa inefficienza è dovuta non solo al fatto che realizza backup logici, ma anche perché sia il backup che il processo di ripristino sono basati su un singolo thread. Il dump prodotto include istruzioni SQL per la creazione delle tabelle, per il popolamento dei dati, o entrambi.
Come già accennato, utilizzare mysqldump per effettuare il backup di un database MySQL, Percona Server o MariaDB è considerato l’approccio più errato. Se non te ne fossi ancora reso conto, siamo nel 2023, non nel 2005, e potrebbe essere tempo per te e il tuo hosting provider di prendere coscienza dei problemi che questa utility può creare, soprattutto quando si tratta di gestire grandi database di diverse dimensioni, misurabili in gigabyte. Se il tuo provider non si adeguasse, potrebbe essere il caso di considerare un cambio di fornitore, soprattutto se il tuo progetto è particolarmente ambizioso e importante per te.
Mysqldump ha la capacità di estrarre e copiare il contenuto delle tabelle riga per riga, oppure può estrarre l’intero contenuto della tabella e immagazzinarlo in un buffer di memoria prima di procedere alla copia. Quest’ultimo approccio può presentare problemi quando si tratta di gestire tabelle di grandi dimensioni.
In sostanza, l’obiettivo di mysqldump è quello di generare un file .sql, noto come dump, che contiene le istruzioni necessarie per ricreare il database. Per garantire un backup del database coerente, mysqldump utilizza dei parametri specifici per il locking delle tabelle: per le tabelle InnoDB, viene utilizzata l’opzione –single-transaction, mentre per le tabelle MyISAM si ricorre all’opzione –lock-tables.
Se il tuo database ha una dimensione di pochi o una decina di megabyte, puoi “tranquillamente” utilizzare questo approccio, che richiede solo pochi secondi o poco più per generare un dump .sql. Tuttavia, se stiamo parlando di un database di dimensioni significativamente maggiori, misurabili in gigabyte, l’operazione di backup potrebbe richiedere un tempo considerevole, dall’ordine delle decine di minuti fino ad arrivare a diverse ore.
Durante questo lasso di tempo, il database si troverà in uno stato di locking, impedendo qualsiasi operazione di lettura o scrittura. Questa situazione potrebbe creare problemi anche per i crawler di Google, i quali si troverebbero a dover gestire errori del server.
Percona XtraBackup. Come fare un backup MySQL da professionisti.
Mentre il metodo prima elencato esegue backup logici, con una lentezza estenuante, un approccio simile diventa inutilizzabile man mano che un database inizia a crescere di qualche gigabyte. Xtrabackup è il software di backup fisico MySQL più diffuso. Può creare un backup caldo (il che significa che non è necessario fermare il server del database), è molto più veloce e supporta backup completamente non bloccanti, a condizione che tutte le tabelle siano InnoDB o XtraDB. Può creare file di backup locali o un flusso di output standard, quindi è molto versatile. Ad esempio, utilizzando strumenti come gof3r è possibile eseguire lo streaming dei backup su Amazon S3 e caricare il backup al volo (senza conservarlo localmente). La dimensione dei backup è grande quasi quanto l’intero database, ma xtrabackup supporta i backup compressi utilizzando qpress, riducendo notevolmente la dimensione finale. Un’altra grande caratteristica è che può crittografare i backup o lo streaming con AES128, AES192 e AES256.
Oltre ad avere molti altri vantaggi in primis un restore dell’intero DB praticamente immediato e molte altre feature che andrebbero ben oltre il nostro scopo focalizzato su problematiche sistemistiche che sfociano in problematiche di tipo SEO, il vantaggio principale è quello di non bloccare col locking il database e dunque continuare a rispondere ad eventuale query di visitatori notturni, spider e crawler.
Spiegato in termini semplici, l’approccio di mysqldump al backup di un database comporta una serie di passaggi: prima deve bloccare le tabelle, quindi procede con l’esecuzione del backup e infine sblocca le tabelle. Questa procedura può essere lunga e impegnativa, specialmente con database di dimensioni maggiori, e può causare tempi di inattività per l’accesso al database durante il processo di backup.
In contrasto con questo approccio, Percona XtraBackup sfrutta una caratteristica nativa di MySQL e dei software DBMS derivati, come MariaDB o Percona Server. Questa funzione è nota come binary log (binlog) ed è uno dei componenti fondamentali per garantire la consistenza dei dati e la ripristinabilità del database.
Il binary log registra tutte le modifiche ai dati o alle strutture dei dati effettuate dal database. Queste registrazioni comprendono non solo le istruzioni SQL che modificano i dati (come INSERT, UPDATE, DELETE, ecc.), ma anche informazioni dettagliate sui cambiamenti a livello di schema dei dati, come la creazione di nuove tabelle o l’alterazione delle tabelle esistenti.
In pratica, il binary log funziona come un diario di tutte le operazioni di scrittura e modifica effettuate nel database. Percona XtraBackup utilizza queste informazioni per eseguire un backup “a caldo” del database, cioè un backup che viene eseguito mentre il database è ancora in funzione e accessibile per le operazioni di lettura e scrittura. Ciò elimina la necessità di bloccare le tabelle durante il processo di backup, riducendo così i tempi di inattività e aumentando la disponibilità del database.
Questo meccanismo di backup consente a Percona XtraBackup di catturare una fotografia istantanea del database, che include tutte le transazioni completate fino al momento del backup. Le transazioni successive vengono poi registrate nel binary log, che può essere utilizzato per ripristinare il database allo stato desiderato in caso di guasto.
Quindi, in sintesi, mentre mysqldump richiede l’esecuzione di un backup “a freddo” che richiede il blocco delle tabelle e potenziali tempi di inattività, Percona XtraBackup utilizza il binary log per eseguire un backup “a caldo” che riduce al minimo l’impatto sulle operazioni del database.
Performance MySQLdump VS Percona XtraBackup
Se vogliamo toccare con mano dei numeri reali ovvero misurare per decidere, possiamo vedere brevemente un benchmark tra i due tool per comprendere di cosa stiamo parlando e perchè mysqldump deve essere considerato come un giocattolino inadeguato per sistemi in produzione, andato a creare backup mysql lenti.
Dal nostro esame, è evidente che, anche lavorando sullo stesso set di dati di ben 73GB, un backup eseguito con mysqldump risulta essere addirittura 50 volte più lento rispetto a uno realizzato con Percona XtraBackup. Questo significa che un backup che potrebbe richiedere ore se eseguito con mysqldump, potrebbe essere completato in pochi minuti con Percona XtraBackup. Questo può fare una differenza significativa per le imprese che necessitano di eseguire frequentemente backup del database e hanno l’obiettivo di minimizzare i tempi di inattività.
È importante sottolineare, inoltre, che Percona XtraBackup è un software completamente gratuito, senza alcuna limitazione. Attualmente, è considerata la migliore soluzione di backup disponibile per i sistemi basati su MySQL e sui suoi derivati. Il valore offerto da questo strumento è tale che supera addirittura MySQL Enterprise Backup, un prodotto sviluppato dal team di sviluppatori di MySQL stessa.
In un tono chiaramente sarcastico, va notato che MySQL Enterprise Backup viene offerto al prezzo non esattamente modesto di 5000 dollari all’anno per server. Questo rende l’offerta di Percona XtraBackup ancora più impressionante, considerando che non solo offre una soluzione di backup di alta qualità, ma lo fa a costo zero. Questo dimostra come Percona XtraBackup rappresenti una scelta eccellente sia dal punto di vista delle prestazioni che del rapporto qualità-prezzo per le imprese che utilizzano MySQL o un suo derivato come sistema di gestione del database.
Non esiste insomma alcun motivo per non utilizzare Percona XtraBackup se non solo superficialità ed ignoranza conclamata.
Usi pannelli come cPanel o Plesk ? Attenzione, anche loro usano mysqldump
Purtroppo il dilettantismo e il pressapochismo non riguarda solo sistemisti della domenica e improvvisati tuttofare ma anche aziende di un certo spessore che producono pannelli di controllo commerciali come cPanel o Plesk.
Leggendo infatti sul loro sito possiamo leggere in data gennaio 2019 inerentemente all’utilizzo di Percona :
Oltretutto anche rispetto ad altre tipologie di backup ecco un semplice specchietto riassuntivo che mostra perchè dovreste utilizzare questo modo di lavorare invece di improvvisarvi con utility antiquate e altamente non performanti.
Percona XtraBackup è l’unica soluzione in grado di soddisfare tutti i requisiti, utilizzabile in maniera assolutamente proficua anche insieme ad una replica MASTER / SLAVE ma questo è un altro discorso.
Conclusione
In conclusione, se ti ritrovi a dover gestire backup di singoli database e vari file .sql nel tuo spazio di backup giornaliero o settimanale, è giunto il momento di prendere in considerazione alcuni cambiamenti importanti. La lentezza del backup di MySQL non dovrebbe essere una norma accettabile, ma piuttosto un segnale di allarme che ti spinge a fare delle domande fondamentali sulle pratiche di backup attuali.
Osserva attentamente il comportamento del tuo sito: se noti errori dallo spider di Google, è il momento di iniziare a preoccuparti. Ancora peggio, se scopri che il tuo fornitore di hosting utilizza mysqldump per i backup, dovresti considerare seriamente la possibilità di cambiare fornitore. In effetti, se il tuo progetto web è la tua fonte principale di reddito e sei sicuro che il tuo fornitore di hosting non utilizza Percona XtraBackup, ti consigliamo vivamente di cercare un’alternativa.
La nostra intenzione non è screditare qualcuno in particolare, ma è importante riconoscere che un approccio dilettantistico ai backup può rappresentare un pericolo non solo per la salute del tuo business, ma anche per la tua tranquillità. Un backup inefficace o inaffidabile può portare a perdite di dati catastrofiche e potenzialmente irreversibili.
La tua attività merita il meglio e il passaggio a un provider che utilizza Percona XtraBackup può rappresentare un enorme passo avanti in termini di velocità, efficienza e affidabilità. Prenditi il tempo necessario per valutare le tue opzioni e non esitare a fare il salto quando ti rendi conto che è il momento di fare un upgrade.
Il futuro del tuo business potrebbe dipendere da questa decisione. Ricorda: un business digitale sicuro è un business che può crescere e prosperare. Investi nella tua tranquillità e nella sicurezza dei tuoi dati. Non aspettare che sia troppo tardi, agisci adesso.