All'interno di Microsoft.comGuida introduttiva al mirroring del database

Saleem Hakani

La mancanza di disponibilità del database è un grave problema. Ma grazie a SQL Server 2005 con SP1 e al mirroring del database è possibile evitare un simile disastro. Questa nuova tecnologia ad alta disponibilità consente di mantenere una copia hot standby del database pronta per l'uso quando il server del database di produzione non

è disponibile. La funzione di mirroring del database opera trasferendo i record del registro delle transazioni di un database dal server primario al server secondario, che svolge la funzione di hot standby. Con il mirroring del database, le modifiche di dati sono registrate nel registro delle transazioni prima di essere apportate alle pagine di dati effettive, analogamente a quanto avviene con gli aggiornamenti di SQL Server™. I record del registro sono memorizzati inizialmente nel buffer di registro del database principale, quindi salvati in modo permanente nel disco. I registri delle transazioni vengono copiati e riprodotti nel database del server mirror. In questo modo le modifiche del database principale vengono duplicate nel database mirror. Notare che soltanto il database principale è accessibile alle connessioni client. Quando il database principale riceve le modifiche richieste dai client, il server principale invia le modifiche attive al server mirror; il database mirror non esegue tali azioni. Una volta abilitato il mirroring del database, quando nel database principale si verifica un errore, il database mirror diventa disponibile.

Funzionamento del mirroring del database

Il mirroring del database funziona con tutto l'hardware standard che supporta SQL Server 2005 e garantisce che non si verifichino perdite di dati nel caso di errori del database. Il database mirror è sempre aggiornato con la transazione in fase di elaborazione sul server del database primario. Nella Figura 1 è illustrato il flusso di dati.

Se il server principale ha un problema, il server mirror fornisce una copia precisa e aggiornata del database principale risalente all'ultima transazione per cui è stato eseguito il commit. Così, il server mirror è sempre pronto ad assumere il ruolo di server principale.

Figura 1** Replica di dati nel mirror **(Fare clic sull'immagine per ingrandirla)

Nella topologia del mirroring del database, occorre un terzo server chiamato server di controllo per attivare il failover automatico tra il server mirror e quello principale e viceversa. Un server di controllo è un qualunque computer in grado di supportare SQL Server 2005.

Modalità di funzionamento

La topologia di mirroring del database utilizzata dipenderà dalla protezione della transazione e dalle modalità di funzionamento scelte. Le modalità di funzionamento supportate dal mirroring del database includono una protezione (con o senza failover automatico) e prestazioni molto elevate.

Protezione elevata con failover automatico: questa modalità supporta i massimi livelli di disponibilità del database con trasferimento di dati sincrono e failover automatico al database mirror. Questa modalità operativa è consigliata in presenza di comunicazione veloce e affidabile tra i server mirror e principale e quando il failover automatico è richiesto per un solo database. In questo schema, il database principale non esegue il commit per la transazione finché non riceve un messaggio dal server mirror comunicante che quest'ultimo ha attivato la protezione del registro delle transazioni nel disco.

Protezione elevata senza failover automatico: questa modalità supporta i massimi livelli di disponibilità del database con trasferimento di dati sincrono senza failover automatico al database mirror. In questa modalità, se l'istanza del server mirror non è più disponibile, quella del server principale continua a funzionare ma non sarà in grado di effettuare il mirroring di dati. Se il server principale ha dei problemi, il mirroring del database viene sospeso, ma è possibile forzare manualmente il servizio per eseguire il failover.

Alte prestazioni: in questa modalità di funzionamento il trasferimento di dati è asincrono. Il server principale non attende il riconoscimento dal server mirror come accade nelle due modalità sopra descritte. Il server mirror cerca di rimanere al passo dell'originale, ma non è garantito che tutte le transazioni recenti del server principale siano protette nel registro delle transazioni del server mirror. Se il server principale ha dei problemi, il mirroring del database viene sospeso, ma è possibile forzare manualmente il servizio per eseguire il failover.

Configurazione di base

La preparazione del mirror del database è un processo semplice se vengono poste solide basi e si seguono alcune procedure consigliate.

Edizione del server Accertarsi che entrambi i server eseguano la stessa edizione di SQL Server 2005, Standard o Enterprise.

Disponibilità del server di controllo Se si intende utilizzare la protezione elevata con failover automatico, accertarsi che il server di controllo sia disponibile e che SQL Server 2005 sia installato (qualunque edizione). Il server di controllo può essere eseguito su un qualunque computer affidabile in grado di supportare SQL Server 2005.

Immagine mirror Assicurarsi che l'istanza del server mirror condivida processi, account di accesso, pacchetti SQL Server Integration Services (SSIS), partizioni del disco, posizioni dei file e configurazione del server con l'istanza del server principale. Se si configura il server mirror esattamente come il server principale si avrà la garanzia che esso funzionerà esattamente come il primo.

Recupero con registrazione completa È importante che tutti i database che partecipano al mirroring del database siano impostati sul modello di recupero con registrazione completa (FULL).

Master e TempDB Verificare che tutte le istanze del server nella topologia di mirroring si avvalgano delle regole di confronto e della tabella codici Master e TempDB. Le differenze tra regole di confronto e tabella codici potrebbero causare dei problemi durante la configurazione del mirroring del database.

Backup Se il database soggetto a mirroring è grande, occorre eseguire un backup completo del database, quindi ripristinarlo sull'istanza del server mirror utilizzando l'opzione NORECOVERY.

Pianificazione Determinare in anticipo tutti i nomi, i numeri di porta, gli account di protezione dei server e le posizioni del database e documentarli. Per un elenco di controllo, vedere "Procedure consigliate per il mirroring del database" nella barra laterale.

Una volta verificati questi elementi di base, è possibile passare alla configurazione del mirroring del database nell'ambiente in uso.

Procedure consigliate per il mirroring del database

1. Utilizzare server partner che abbiano CPU, memoria, archiviazione e capacità di rete identiche.
2. Assicurarsi che entrambi i partner abbiano la stessa edizione del sistema operativo, di SQL Server, compresi service pack e aggiornamenti.
3. Installare SQL Server sulle stesse directory e strutture di unità su entrambe le istanze del server, mirror e principale.
4. Se le prestazioni rappresentano un problema, prendere in considerazione una scheda di interfaccia di rete dedicata per separare il carico.
5. Come per i partner server, accertarsi che entrambe le istanze del server, mirror e principale, siano identiche in termini di CPU, memoria, archiviazione e capacità di rete. Verificare che entrambi i server abbiano la stessa struttura di directory, lo stesso schema di partizione del disco e la medesima configurazione di SQL Server per evitare di dover modificare il partner mirror durante o dopo il failover.
6. Assicurarsi che tutte le applicazioni siano in grado di connettersi e di eseguire tutte le azioni necessarie e che tutti gli accessi SQL Server attivi (e le relative autorizzazioni) sull'istanza del server principale siano presenti anche sull'istanza del server mirror. Per farlo, è possibile utilizzare l'attività Trasferisci account di accesso di SQL Server 2005 Integration Services.
7. Copiare processi e avvisi di SQL Server Agent, pacchetti SSIS, database di supporto, definizioni del server collegate, periferiche di backup, progetti di manutenzione, profili di posta del database e così via dal server principale al server mirror.
8. Definire una procedura che consenta di ripetere o replicare automaticamente eventuali modifiche del server principale (modifiche hardware, software, impostazioni SQL Server o oggetti di database) e di trasferirle all'istanza del server mirror.
9. Eseguire più prove di failover prima di quella effettiva.

Configurazione

Questa configurazione del mirroring del database è del tipo Protezione elevata con failover automatico (come spiegato, sarà necessario implementare un server di controllo). Sono utilizzati nell'esempio i nomi di server e database riportati nella Figura 2, in cui è anche specificato il ruolo di ogni server.

Poiché la configurazione può avere un impatto sulle prestazioni durante la copia del registro delle transazioni in sospeso dal server principale al server mirror, potrebbe essere preferibile eseguire la configurazione iniziale del mirroring del database lontano dalle ore di punta.

La configurazione del mirroring si divide in tre fasi: creazione di endpoint nei server partecipanti, esecuzione di backup e ripristino del database principale, attivazione delle sessioni di mirroring su tutti i server partecipanti.

Prima di stabilire una sessione di mirroring del database, occorre stabilire il meccanismo di comunicazione tra tutti i server che partecipano al mirroring del database. Per farlo, è necessario creare degli endpoint su tutti i server eseguendo questa istruzione sul ServerA e ServerB:

Create Endpoint Mirroring_Endpoint
State= Started as TCP (Listener_Port=5001)
For Database_Mirroring (Role=Partner);

Per il ServerC (che agirà da server di controllo), occorre modificare (Role=Partner) in (Role=Witness) ed eseguire l'istruzione. In questo modo si controlla la porta TCP di attesa per le singole istanze.

Per il prossimo passaggio, occorre eseguire un backup del database completo, un backup del registro del database DBM_Demo dal server principale, quindi ripristinare il backup sull'istanza del server mirror utilizzando l'opzione NORECOVERY. L'uso di NORECOVERY assicura che il database mirror rimanga nello stato di ripristino per l'applicazione del registro delle transazioni.

Ecco l'istruzione T-SQL per eseguire il backup completo del database per il database DBM_Demo del ServerA (istanza del server principale):

Backup Database DBM_Demo to DISK='E:\MSSQL\Bak\DBM_Demo_FULL.bak';

Se dopo il backup completo del database sono apportate modifiche, eseguire un backup del registro del database.

Se necessario, utilizzare l'istruzione T-SQL che segue per eseguire un backup del registro del database DBM_Demo del ServerA:

Backup Log DBM_Demo to Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak';

Una volta eseguiti tutti i backup, spostare i file di backup nel ServerB o in una posizione condivisa per il ripristino sul ServerB. Dopo averlo fatto, ripristinare eventuali backup del registro delle transazioni eseguiti a partire dall'ultimo backup del database completo del ServerA.

Utilizzare l'istruzione T-SQL seguente per ripristinare il backup completo e il backup del registro sul ServerB utilizzando l'opzione NORECOVERY:

--Restore full database backup on the mirror --server instance
Restore Database DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_FULL.bak' with NORECOVERY;

Infine, utilizzare l'istruzione T-SQL seguente per ripristinare il backup del registro sul server mirror utilizzando l'opzione NORECOVERY:

Restore Log DBM_Demo from Disk='E:\MSSQL\Bak\DBM_Demo_Log.bak' with NORECOVERY;

Una volta ripristinati tutti i backup, è possibile passare alla fase finale e attivare la sessione di mirroring del database su tutti i server partecipanti.

Per preparare una sessione di mirroring del database occorre un indirizzo di rete server per ogni istanza del server. Questo indirizzo deve identificare l'istanza fornendo un indirizzo di sistema e il numero di porta di attesa per l'istanza. La sintassi di un indirizzo di rete server è simile alla seguente:

TCP://<System-address>:<port>

<Indirizzo del sistema>: Nome di dominio completo o indirizzo IP; questa informazione è reperibile eseguendo IPCONFIG sul computer locale dal prompt dei comandi.

La <Porta> è stata definita durante la creazione degli endpoint.

È possibile iniziare la sessione di mirroring del database sul ServerB:

Alter Database DBM_Demo
Set Partner= 'TCP://ServerA.com:5001';

Eseguire quindi l'istruzione T-SQL seguente per iniziare la sessione sul ServerA:

Alter Database DBM_Demo
Set Partner='TCP://ServerB.com:5001';

Attivare la sessione di mirroring sul ServerC (il server di controllo):

Alter Database DBM_Demo
Set Witness='TCP://ServerC.com:5001';

Il mirroring del database è adesso pronto per essere eseguito nell'ambiente in uso. Qualunque oggetto di database aggiunto o modificato sul database DBM_Demo sarà trasferito alla copia ServerB. In caso di assenza di disponibilità del database del ServerA, potrebbe verificarsi un failover, modificando il ruolo del database mirror in ruolo principale.

Adesso che il mirroring del database è funzionante, sarà sempre disponibile un database hot standby per ovviare ai problemi del database di produzione.

Saleem Hakani è senior database engineer presso Microsoft e vanta oltre 14 anni di esperienza nel settore dei sistemi di database. Ha fondato e conduce la Microsoft SQL Community ed è responsabile degli standard e dell'automazione SQL Server nell'organizzazione Windows Live. Saleem possiede le certificazioni MCTS, MCDBA e MCSA. Per contattarlo, scrivere a Saleem@sqlcommunity.net.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.