Mirroring sincrono del database (modalità a sicurezza elevata)

Quando il livello di sicurezza delle transazioni viene impostato su FULL, la sessione di mirroring del database viene eseguita in modalità a sicurezza elevata ed opera in modo sincrono dopo una fase di sincronizzazione iniziale. In questo argomento vengono fornite informazioni dettagliate sulle sessioni di mirroring del database configurate per il funzionamento sincrono. In questo argomento si presuppone la conoscenza dei concetti fondamentali relativi alle operazioni di mirroring del database. Per ulteriori informazioni, vedere Sessioni di mirroring del database.

Per ottenere il funzionamento sincrono per una sessione, è necessario che tramite il server mirror vengano sincronizzati il database mirror e il database principale. All'avvio della sessione, il server principale inizia a inviare il proprio log attivo al server mirror. Appena possibile, il server mirror scrive sul disco tutti i record di log in ingresso. Non appena tutti i record di log ricevuti sono stati scritti su disco, i database vengono sincronizzati. I database rimangono sincronizzati fino a quando i partner restano in comunicazione.

[!NOTA] Per monitorare le modifiche dello stato in una sessione di mirroring del database, utilizzare la classe di evento Database Mirroring State Change. Per ulteriori informazioni, vedere Classe di evento Database Mirroring State Change.

Al termine della sincronizzazione, per ogni transazione di cui viene eseguito il commit nel database principale viene eseguito il commit anche nel server mirror, a garanzia della protezione dei dati. A tale scopo, per l'esecuzione del commit di una transazione nel database principale si attende fino a quando il server principale riceve un messaggio dal server mirror indicante il consolidamento del log della transazione nel disco. Si noti che l'attesa di tale messaggio comporta un aumento della latenza della transazione.

Il tempo necessario per la sincronizzazione dipende essenzialmente dal ritardo del database mirror rispetto al database principale al momento dell'avvio della sessione, misurato in base al numero di record di log ricevuti inizialmente dal server principale, dal carico di lavoro nel database principale e dalla velocità del sistema mirror. Dopo la sincronizzazione di una sessione, il log consolidato del quale deve ancora essere eseguito il rollforward nel database mirror rimane nella coda di rollforward. Per ulteriori informazioni, vedere Sessioni di mirroring del database.

Non appena il database mirror è sincronizzato, lo stato di entrambe le copie del database viene impostato come SYNCHRONIZED.

Il funzionamento sincrono viene mantenuto nel modo seguente:

1. Quando riceve una transazione da un client, il server principale scrive il log per la transazione nel log delle transazioni.
2. Il server principale scrive la transazione nel database e, contemporaneamente, invia il record di log al server mirror. Il server principale attende un acknowledgement dal server mirror prima di confermare al client il commit o il rollback di una transazione.
3. Il server mirror consolida il log nel disco e restituisce un acknowledgement al server principale.
4. Quando riceve l'acknowledgement dal server mirror, il server principale invia un messaggio di conferma al client.

La modalità a sicurezza elevata consente di proteggere i dati tramite la richiesta di sincronizzazione tra due posizioni. Tutte le transazioni di cui è stato eseguito il commit vengono scritte nel disco del server mirror.

Modalità a sicurezza elevata senza failover automatico

Nella figura seguente viene illustrata la configurazione della modalità a sicurezza elevata senza failover automatico. La configurazione è composta solo dai due partner.

Se i partner sono connessi e il database è già sincronizzato, è supportato il failover manuale. Se l'istanza del server mirror si arresta, l'istanza del server principale non ne risentirà e verrà eseguita esposta, ovvero senza mirroring dei dati. Se il server principale viene perso, il mirroring viene sospeso, ma è possibile forzare manualmente il servizio nel server mirror, con possibile perdita di dati. Per ulteriori informazioni, vedere Servizio forzato (con possibile perdita di dati).

Modalità a sicurezza elevata con failover automatico

Il failover automatico garantisce disponibilità elevata assicurando il servizio al database anche nel caso di perdita di un server. Per il failover automatico è necessario che la sessione disponga di una terza istanza del server, il server di controllo del mirroring, che idealmente dovrebbe trovarsi in un terzo computer. Nella figura seguente viene illustrata la configurazione di una sessione in modalità a sicurezza elevata che supporta il failover automatico.

A differenza dei due partner, il server di controllo del mirroring non serve il database, ma supporta semplicemente il failover automatico mediante la verifica dell'efficienza del server principale. Il server mirror avvia il failover automatico solo se il mirror e il server di controllo del mirroring rimangono connessi tra loro dopo essere stati entrambi disconnessi dal server principale.

Quando viene impostato un server di controllo del mirroring, la sessione richiede il quorum, una relazione tra un minimo di due istanze del server che consente di rendere disponibile il database. Per ulteriori informazioni, vedere Quorum: Impatto di un server di controllo del mirroring sulla disponibilità del database e Failover automatico. Per ulteriori informazioni, vedere Server di controllo del mirroring del database.

Per l'esecuzione del failover automatico è necessario che si verifichino le condizioni seguenti:

• Il database è già sincronizzato.
• L'errore si verifica mentre tutte e tre le instanze del server sono connesse e il server di controllo del mirroring rimane connesso al server mirror.

La perdita di un partner produce l'effetto seguente:

• Se il server principale non è più disponibile in base alle condizioni precedenti, si verifica il failover automatico. Il server mirror assume il ruolo di server principale e il relativo database diventa il database principale.
• Se il server principale diventa non disponibile quando queste condizioni non sono soddisfatte, si potrebbe riuscire a forzare il servizio, con una possibile perdita di dati. Per ulteriori informazioni, vedere Servizio forzato (con possibile perdita di dati).
• Se solo il server mirror non è più disponibile, le attività nel server principale e nel server di controllo del mirroring continueranno.

Se la sessione perde il relativo server di controllo del mirroring, per il quorum sono necessari entrambi i partner. Se uno dei partner perde il quorum, entrambi lo perdono e il database diventa non disponibile finché il quorum non viene ristabilito. Questo requisito di quorum garantisce che in assenza un server di controllo del mirroring il database non venga mai eseguito senza mirroring.

[!NOTA] Se si prevede che il server di controllo del mirroring rimanga disconnesso per un periodo di tempo prolungato, è consigliabile rimuoverlo dalla sessione finché non diventa disponibile.

Vedere anche

Concetti

Sessioni di mirroring del database
Quorum: Impatto di un server di controllo del mirroring sulla disponibilità del database
Impostazioni di Transact-SQL e modalità operative del mirroring del database

Altre risorse

Monitoraggio del mirroring del database

Guida in linea e informazioni

Assistenza su SQL Server 2005