Database Mirroring con SQL Server 2005

Oltre a una sempre efficace politica di backup dei database, ci sono scenari in cui si rende necessario adottare una soluzione di alta disponibilità (high availability) dei dati, applicando tecniche in grado di far fronte a una mancata di disponibilità del servizio offerto dal DMBS (DataBase Management System) dovuto a un definitivo failure del server di database in una delle sue componenti (per esempio lo storage), o un suo temporaneo failover (per esempio per l'assenza di connettività di rete).

Il più alto livello di disponibilità (cosiddetto Always On) è quello in grado di fronteggiare oltre ai downtime pianificati per le tipiche operazioni di amministrazione del sistema o dei database (software o hardware upgrade, ricostruzione degli indici, etc.), anche quelli non pianificati, per esempio i downtime causati da errori umani (errate cancellazioni/modifiche di dati), failure di sistema (RAM, rete, dischi, processori), recovery di database per dati corrotti, disastri naturali (incendi, allagamenti).

Il database mirroring è una soluzione di alta disponibilità dei dati introdotta con MS-SQL Server 2005. Va ad affiancarsi alle soluzioni di clustering, replica e log-shipping, già presenti nelle precedenti versioni. In particolare, non è da considerarsi un sostituto del clustering (soluzione di alta disponibilità per eccellenza, che però non da protezione dal danneggiamento dello storage). Piuttosto, si tratta di una tecnica più completa di log-shipping in grado di creare e tenere allineata una copia di un database (e non dell'intera istanza come avviene nel clustering) su un'altra istanza di SQL Server (anche remota). Per cui, può essere ritenuto un ottimo sostituto del log-shipping e della replica finalizzata al mantenimento di una copia di database. Se opportunamente configurato, il database mirroring è in grado di assicurare l'Always On.

Concetti chiave

Il processo di database mirroring coinvolge tre componenti essenziali:

• un database principal: è il database in linea oggetto del mirroring
• un database mirror: è il database "specchio" del principal, tenuto allineato al principal dal processo di mirroring
• un server di witness (opzionale): è un servizio SQL Server 2005 che funge da arbitro in fase di failover rendendo possibile il failover automatico.

Il principal e il mirror vengono detti entrambi failover partner, devono risiedere su istanze diverse di SQL Server 2005 e devono avere lo stesso nome.

Come funziona

SQL Server registra le modifiche dei dati prima nel transaction-log (t-log) quindi, a intervalli regolari (checkpoint) replica i dati presenti nel t-log nelle pagine di dati vere e proprie. Il funzionamento del mirroring è basato sulla distribuzione dei log dal principal verso il mirror, perciò occorre che il recovery model del database principal sia impostato a Full. Inizialmente, il database mirror deve essere creato facendo un ripristino di un backup del principal lasciandolo nello stato di NORECOVERY. Questo stato, che normalmente serve a rendere possibile il ripristino di backup del log, consente al processo di mirroring di aggiungere i log records inviati man mano dal principal.

Quando un client invia una modifica, questa viene registrata nel transaction-log del database principal il quale invia simultaneamente al suo failover partner i log registrati nel t-log. A questo punto sia il principal che il mirror hanno nel t-log i dati modificati, pronti per essere registrati nel file di dati dal processo di checkpoint.

Il mirroring di un database può essere realizzato in due diverse modalità: sincrona (synchrounous mode) e asincona (asynchrounous mode). In quella sincrona, una qualsiasi transazione viene registrata nel principal quindi nel mirror, e solo dopo l'avvenuta registrazione nel mirror viene notificata al client che l'ha comandata. Nella modalità asincrona, la registrazione di una transazione nei due database avviene in momenti diversi, per cui può accadere che una modifica realizzata nel principal non venga replicata sul mirror per un eventuale failover, procurando così una perdita di dati che si traduce in un disallineamento tra i due database.

La modalità sincrona o asincrona viene decisa dal transaction safety del database:

• FULL = sincrono
• OFF = asincrono

Per impostarlo basta lanciare l'istruzione:

Se la transaction safety è impostata a OFF (asincrono), si parla di modalità operativa di tipo High Performance. In caso contrario (safety FULL-sincrono), e senza la presenza del witness, la modalità è detta High Protection o High Safety Mode without a witness. Se la safety è FULL e c'è il witness si parla di High Availability o High Safety Mode with a witness.

In caso di failure o failover temporaneo del principal, occorre che il mirror sia promosso a principal per poter essere accessibile, infatti fintanto che un database mantiene il ruolo di mirror, esso è in uno stato di standby.
Per fare ciò si può intervenire manualmente, forzandolo mediante l'impostazione FORCE_SERVICE_ALLOW_DATA_LOSS, la quale, però, può produrre una perdita di dati.

Se invece c'è il witness, sarà questo in modo autonomo a invertire i ruoli dei due database. Esso farà diventare principal il mirror e viceversa, e riallineerà il vecchio principal (divenuto mirror a seguito al failover) qualora ritorni in vita, lasciandolo nel ruolo di mirror fino a che un nuovo failover (sia automatico che manuale) colpisca l'attuale principal. In presenza di un failure , che quindi compromette il database principal, sarà necessario ricrearlo con un nuovo database, cancellando prima il processo di mirroring impostato in precedenza.

Se, infine, i due failover partner sono attivi (synchronized), è possibile scambiare di ruolo tra principal e mirror senza alcuna perdita di dati con l'impostazione

a meno che siamo in modalità asincrona (safety OFF, altrimenti detta high-performance), nel qual caso occorre necessariamente forzare il servizio con FORCE_SERVICE_ALLOW_DATA_LOSS, oppure per evitare perdite di dati cambiare prima la transaction safety a FULL per produrre il failover manuale.

Caratteristiche

Prima di cimentarci in un'implementazione di esempio, analizziamo in dettaglio le caratteristiche del mirroring riassunte nella figura che segue, in cui ogni caratteristica viene anche confrontata con le altre tecniche di alta disponibilità di SQL Server 2005.

dove:

1. In FULL SAFETY mode
2. In presenza di WITNESS
3. Utilizzando le funzionalità di SNAPSHOT
4. Accessibilità intermittente in funzione delle attività di ripristino

Perdita di dati

Nella modalità FULL SAFETY, ovvero la modalità sincrona, il database mirroring assicura la non perdita dei dati, ovvero fa in modo che una transazione coinvolga sicuramente sia il database principal che il mirror. Perciò, il completamento di una modifica di un dato viene notificato al client solo se la modifica viene realizzata in entrambi i database coinvolti nel processo di morroring, in caso contrario, a causa del downtime del server che ospita il principal o il mirror, in nessuno dei due database sarà registrata la modifica.

Failover automatico

In presenza di un witness avviene il failover in modo automatico. In tal caso, sarà appunto il witness a elevare a principal il database mirror, senza richiedere alcun intervento da parte del DBA.

Tempo di failover

Il tempo medio di failover è inferiore ai 3 secondi, sensibilmente più basso di quello fornito dalle altre tecniche.

Reindirizzamento trasparente dei client

I seguenti data provider sono in grado di realizzare il redirect automatico della connessione:

• ADO.NET 2.0 provider for SQL Server 2005 (SqlClient)
• SQL Native Client
• SQL Server 2005 JDBC (Java Database Connectivity) 1.1 Driver

Quello che occorre fare è specificare nella connection string il nome del servizio SQL che ospita il mirror attraverso l'opzione "Failover Partner". Per esempio:

"Data Source=ServerPrincipal;Failover Partner=ServerMirror;Initial Catalog=AdventureWorks;Integrated Security=True;"

Attenzione alla sintassi della keyword "Failover Partner", poiché differisce leggermente a seconda del metodo di connessione utilizzato.

L'effetto di questa specifica è il redirect della connessione del client verso il database mirror in caso di irraggiungibilità del database principal. Le vecchie applicazioni che non utilizzano ADO.NET 2.0 o SQL Native Client, possono comunque realizzare un redirect abbastanza avegole usando gli alias nel DNS, anche se necessario un intervento manuale. Infatti, se la connection string usasse nel "Data Scource" un alias dell'host del SQL Server primario, in presenza di un failover basterebbe cambiare il nome host a cui fa riferimento l'alias nel DNS e forzarne la replica.

Standby read only

Dal momento della sua creazione fino a quando viene elevato a principal, il database mirror è in uno stato di standby, ovvero non operazionale. Perciò non può essere neppure usato per operazioni di sola lettura. L'unico modo per accedervi in lettura è quello di crearne uno snapshot che consiste in un particolare database in cui SQL Server andrà a registrare le pagine di dati presenti nel database origine dello snapshot così come sono al momento esatto della creazione dello snapshot, e solo quanto queste vengono modificate nel database d'origine. In questo modo, interrogando il database snapshot si possono leggere i dati del database mirror al momento della creazione dello snapshot.

È indispensabile creare lo snapshot nella stessa istanza del database origine:

Granularità

Con questo termine si intende l'unità più piccola di database su cui è possibile applicare la tecnica di alta disponibilità. La granularità del database mirroring è l'intero database.

Protezione disk failure

Se il mirror risiede su un'istanza SQL presente su un server remoto, viene garantito il failure dello storage - soluzione ideale per fronteggiare i disastri naturali.

Hardware specifico

Diversamente dal clustering, non è richiesto un hardware specifico per implementare il mirroring.

Complessità

Confrontato con le altre tecniche, il mirroring risulta di più semplice implementazione.

Il mirroring in pratica

Va premesso che l'esempio che segue assume la presenza della service pack 1 o successiva sui server SQL coinvolti (al momento in cui è stato scritto questo articolo è disponibile la SP2 scaricabile direttamente dal sito Microsoft). L'uso della RTM non è consigliata in produzione e necessita l'abilitazione del trace flag 1400. I trace flag sono parametri che possono essere introdotti tra gli argomenti di esecuzione del servizio SQL. Solitamente introdotti dal team di sviluppo per uso interno, possono essere configurati mediante il tool SQL Server Configuration Manager aggiungendoli nella voce "Startup Parameters" presente nelle proprietà del servizio. Per il trace flag 1400 va aggiunto "-T 1400;".

Nel nostro esempio definiremo un mirroring sul database AdventureWorks, in modalità High Availability (high safety mode with a witness), supponendo di lavorare con tre istanze nominate di SQL Server 2005 (presenti su altrettanti PC oppure sullo stesso come nel nostro esempio, anche se questa soluzione non ha senso in un ambiente di produzione), di cui una ospita il futuro principal (SQL2005ServerPrincipal), un'altra ospiterà il mirror (SQL2005ServerMirror) e l'ultima farà da witness (SQL2005ServerWitness)

Ecco i passi da seguire (in ordine) per impostare un mirroring in modalità High Availability:

1. Fare un backup del database e ripristinarlo con l'opzione NORECOVERY sul server mirror.

2. Creare su ciascun server un endpoint di mirroring. L'endopoint è l'astrazione di una porta TCP attraverso cui il servizio SQL comunica con il proprio failover partner (o col witness). Basterà identificare una porta TCP libera su ciascuno dei server, meglio se scelta fra le porte private cioè quelle compresa tra 49152 a 65535. Attenzione che se si utilizza la stessa macchina per installare le varie istanze di SQL, occorrono tre porte diverse, una per ogni istanza (principal, mirror e witness).

3. Assicurarsi che i tre server si "riconoscano" tra loro. Il che si traduce, in un Windows Domain, nel fatto che gli account di servizio di ognuna delle instanze di SQL Server abbia i diritti necessari per connettersi agli altri server. Se tutti i server utilizzano lo stesso account di servizio, il problema non si pone. In caso contrario occorre creare ogni account nelle diverse istanze (mediante CREATE LOGIN) concedendo loro l'accesso all'endpoint di mirror (con GRANT CONNECT ON ENDPOINT). In assenza di trusted-domains, bisogna far uso di certificati digitali che è possibile creare col comando CREATE CERTIFICATE.

4. Rendere noto l'endpoint del principal al database mirror.

5. Rendere noto l'endpoint del mirror e del witness al database principal.

6. Impostare la transaction safety a OFF o a FULL se si vuole, rispettivamente, una modalità asincrona oppure sincrona.

A questo punto, per provare il failover automatico reso possibile dalla presenza del witness, possiamo effettuare modifiche ai dati di AdventureWorks (per esempio creare una nuova tabella in cui fare subito dopo delle insert) e a simulare un failover del server SQL2005ServerPrincipal arrestandolo con il tool SQL Server Configuration Manager. In meno di 3 secondi, il database AdventureWorks dell'istanza SQL2005ServerMirror sarà promosso a principal e sarà interrogabile in lettura e scrittura. Dopo aver verificato l'esistenza della nuova tabella creata in precedenza sul principal, avviando nuovamente il servizio SQL2005ServerPrincipal questo assumerà il ruolo di mirror (come si potrà evincere facilmente dal SQL Server Management Studio che nell'Object Explore presenterà affianco al nome del database la frase "(Mirror, Synchronized/Restoring...)" anzicchè "(Principal, Synchronized)".

Un failover del SQL2005ServerMirror, il quale nel frattempo è divenuto principal del processo di mirroring, porterà alla situazione originaria con SQL2005ServerPrincipal nel ruolo di principal e SQL2005ServerMirror nel ruolo di mirror. Senza attendere quest'ultimo failover o provocarlo con l'arresto del servizio, possiamo lanciare un failover manualmente (come già visto prima) sul SQL2005ServerMirror con la frase T-SQL:

Con quali edizioni di SQL Server 2005 è disponibile il mirroring? Le edizioni che consentono l'implementazione del mirroring sono la Enterprise, la Standard e la Developer (ricordo che quest'ultima è in tutto e per tutto equivalente alla Enterprise eccetto che per la licenza che è mono-utente e a soli scopi di sviluppo, in altre parole non può essere usata in produzione). La Standard non supporta la modalità asincrona (safety OFF).

Una nota particolare va fatta per il witness che può invece ospitare una qualsiasi edizione, persino la SQL Express che è free. Inoltre, se si vuole accedere in lettura al mirror, è necessaria la Enterprise poiché è l'unica a permette la creazione di Snapshot. Infine, è opportuno installare la Service Pack 1 o successiva di SQL Server perché Microsoft non fornisce supporto in caso di RTM, nel qual caso sconsiglia di utilizzare il mirroring in ambiente di produzione.

Per quanto riguarda il licencing, per l'istanza di mirror non è richiesta alcuna licenza fintanto che essa ospita esclusivamente database mirror. Basta la presenza di un altro database estraneo al mirroring così come uno snapshot di uno di questi database mirror, a giustificare l'acquisto di una licenza server e delle dovute licenze client.

Conclusione

La bassa complessità e i bassi costi di implementazione, insieme ai tanti altri vantaggi rispetto al classico clustering failover, così come a log-shipping e replication, fanno del Database Mirroring una tecnica molto appetibile nei numerosi scenari in cui l'alta disponibilità è un requisito fondamentale. È, però, importante ricordare che non è da intendere come un sostituto del clustering, poiché è più semplicemente una tecnica di distribuzione del log da un database di un'istanza di SQL a un altro database su un'altra istanza, mantenendo così un database di standby sempre allieanto al database primario, pronto all'uso in caso di failure o failover del database primario.