Un "Disaster Recovery Plan" nell'amministrazione delle basi di dati è in pratica un piano d'emergenza che può essere adottato nel caso in cui un database venga coinvolto da malfunzionamenti o danneggiamenti tali da rendere inaccessibili o inutilizzabili le informazioni archiviate.
Lo scopo di un piano di ripristino è in pratica quello di riportare quanto prima un database nelle condizioni precedenti al verificarsi della problematica che lo ha colpito, per cui è possibile affermare che un piano ben organizzato si contraddistingue per la velocità di risposta ad un malfunzionamento, l'obiettivo (oltre naturalmente a quello relativo alla salvaguardia dell'integrità dei dati) è diminuire quanto più possibile i tempi in cui un servizio rimane off line in attesa del completamento di un ripristino.
Nel corso di questa breve trattazione verranno esaminate le possibili cause di un grave malfunzionamento e i rimedi da pianificare in vista di un'eventuale riattivazione.
Le possibili cause di un disastro
In genere è possibile identificare una caratteristica che accomuna tutti i malfunzionamenti: essi giungono solitamente inaspettati; in generale è molto difficile, se non impossibile, prevedere quando una determinata problematica potrà avere luogo e con quali modalità si presenterà, per questo motivo un buon piano di ripristino può rivelarsi particolarmente utile.
Ma quali possono essere le cause di un disastro a carico di un database? Le tipologie sono molteplici ma è possibile creare alcune macrocategorie in grado di accomunarne la maggior parte:
- cracking: si tratta di una categoria che ricomprende in sé tutte le tipologie di attacchi informatici provenienti dall'interno di una rete o dall'esterno tramite Internet, con lo scopo di arrecare danno ad un sistema o di sottrarre ai legittimi proprietari le informazioni da esso gestite.
- errore umano: un evento spesso sottovalutato, che deve essere considerato invece con la massima attenzione perché giunge nella maggior parte dei casi inaspettato; un errore umano è dovuto generalmente all'errata digitazione di un'istruzione SQL come per esempio l'eliminazione di una tabella tramite il comando DROP, l'errato UPDATE di uno o più record, l'utilizzo del comando DELETE senza il ricorso alla clausola WHERE per specificare l'intervallo di record che dovrebbe essere correttamente interessato da un'istruzione per la cancellazione.
- problematiche di sistema: si tratta di una categoria che racchiude tutti i possibili fattori ambientali che possono causare un danno a carico del funzionamento di una base di dati, di un'applicazione che si interfaccia ad un database o di un Database manager. Si pensi per esempio di dover effettuare un aggiornamento per un sistema operativo, si immagini inoltre di dover effettuare un riavvio della piattaforma e che al fine di questa procedura il sistema non riesca ad riattivare i processi arrestati (ad esempio per un kernel panic su Linux o una schermata blu su Windows), in questo caso è molto probabile che il DBMS non subisca alcun danno, ma non potrà funzionare in quanto l'Os non sarà in grado di attivarne il relativo processo.
- problematiche hardware: anche per quanto riguarda questa categoria non ci si trova davanti ad un problema che riguarda direttamente le basi di dati o il DBMS che le gestisce, ma la macchina che ospita fisicamente i dati (physical disaster); con l'introduzione di tecnologie come per esempio i sistemi RAID per la condivisione e la duplicazione delle informazioni, questo tipo di problematiche sono oggi sempre meno comuni, ma la loro possibile occorrenza non è da escludersi a priori.
Le categorie elencate dimostrano che un buon recovery plan non debba essere mirato elusivamente al ripristino di una situazione precedente, ma anche alla messa in sicurezza dei dati in modo che l'evento alla base di un malfunzionamento, di un danneggiamento o di una violazione non possa ripetersi in futuro.
Nella gestione delle basi di dati il concetto di piano di ripristino è fortemente collegato a quello di High Availability, essi vengono spesso utilizzati come sinonimi ma presentano un fondamentale differenza: mentre il primo infatti è mirato a limitare quanto più possibile i tempi in cui un servizio risulta essere off line, il secondo invece mira a tenere un servizio in linea quanto più tempo possibile.
Entrambi questi concetti sono però legati ad un altro: la "duplicazione" o "replica" dei dati (replication).
In MySQL la replica è uno strumento che permette di replicare automaticamente e senza interruzioni delle basi di dati tra due server presenti all'interno di una Rete, nel caso in cui si dovesse verificare un malfunzionamento sarà quindi immediatamente disponibile un copia funzionante dei dati gestiti.
Nella duplicazione i server sono ordinati gerarchicamente, per cui si avrà un master, il server destinato all'accesso ai dati, e uno slave, cioè il server destinato ad ospitare le copie; naturalmente ad un master potranno corrispondere più slave, nello stesso modo uno slave potrà a sua volta essere master di slave secondari.
In ogni caso la duplicazione avrà luogo attraverso il comune protocollo di comunicazione TCP/IP e consisterà in un processo a carico dello slave suddiviso in due ulteriori sottoprocessi:
- un sottoprocesso di input output;
- un sottoprocesso SQL.
Il primo sottoprocesso è destinato a ricevere gli aggiornamenti che si verificano nel master e di scriverli in un file di log, il secondo sottoprocesso leggerà il log ed eseguirà gli aggiornamenti necessari per rendere le copie identiche agli originali; i due sottoprocessi sono completamente indipendenti, ciò vuol dire che uno di essi potrà essere fermato senza influire sull'altro, per cui:
- fermando il sottoprocesso di input output, quello SQL continuerà ad aggiornare le copie sulla base di quanto scritto sul log al momento corrente;
- fermando il sottoprocesso SQL, l'altro sottoprocesso continuerà a compilare il file di log, una volta riavviato l'SQL questo ricomincerà a completare le copie a partire dal punto in cui era stato arrestato.
L'utilizzo della duplicazione soddisfa quindi pienamente sia le esigenze legate alla pianificazione dei ripristini che alla High Availability, perché questo strumento possa essere utilizzato è però necessario che:
- master e slave presentino la stessa versione di MySQL;
- ciascuno slave dovrà avere un account relativo al proprio master;
- prima della duplicazione master e slave dovranno contenere due copie esatte dello stesso database.
Una volta verificata la presenza dei requisiti appena elencati, sarà possibile configurare master e slave per la duplicazione utilizzando la seguente procedura:
- arrestare il master;
- nel file di configurazione di MySQL, assegnare come "id" univoco al master un valore numerico intero, ad esempio:
server-id = 100 - nel file di configurazione di MySQL, definire il file in cui verranno scritti i log:
log-bin = nome_slave_100.log - creare un account nel master a cui lo slave può connettersi:
CREATE USER duplicazione@host_slave; - aggiungere i privilegi di duplicazione all'utente appena creato:
GRANT REPLICATION SLAVE ON *.* to duplicazione@host_slave IDENTIFIED BY 'password'; - riavviare il master;
- arrestare lo slave nel caso in cui sia attivo e configurarlo, nel file di configurazione di MySQL, per la connessione al master:
# un valore intero univoco da assegnare come id
# differente da quello del master
server-id = 101
# nome host o indirizzo IP del master
master-host = ip-del-master
# nome utente dell’account creato per il master
master-user = duplicazione
# password dell’account creato per il master
master-password = password- avviare lo slave;
- se necessario, escludere le basi di dati che non dovranno essere replicate:
binlog-ignore-db = nome_database
Naturalmente sarà possibile effettuare una procedura di duplicazione anche all'interno dello stesso server e quindi della stessa macchina ospitante; per far questo però bisognerà utilizzare due installazioni del database manager situate in due directory o in due partizioni ben distinte, in questo caso però nel passaggio relativo alla configurazione della connessione tra master e slave sarà necessario indicare come indirizzo IP 127.0.0.1, non localhost, in modo da assicurarsi il buon funzionamento delle comunicazioni via TCP/IP.
Conclusioni
In questa breve trattazione è stato affrontato l'argomento relativo agli accorgimenti necessari per approntare un buon piano di ripristino nel caso in cui una base di dati incorra in un malfunzionamento che la renda irraggiungibile o inutilizzabile.
Per far questo sono state elencate le possibili cause di malfunzionamenti ed è stato introdotto il concetto della duplicazione, uno strumento che permette di creare delle copie di una o più basi di dati che consentano di limitare al minimo i tempi di permanenza off line in caso di malfunzionamenti.
