Modalità operative del mirroring del database

Si applica a:SQL Server

In questo argomento vengono illustrate le modalità di funzionamento sincrona e asincrona per le sessioni di mirroring del database.

Termini e definizioni

In questa sezione vengono introdotti alcuni termini fondamentali ai fini della comprensione dell'argomento.

Modalità a prestazioni elevate
La sessione di mirroring del database viene eseguita in modo asincrono e utilizza unicamente il server principale e il server mirror. L'unica forma di cambio di ruolo è il servizio forzato (con possibile perdita di dati).

Modalità a sicurezza elevata
La sessione di mirroring del database viene eseguita in modo sincrono e, facoltativamente, utilizza un server di controllo, oltre al server principale e al server mirror.

Livello di sicurezza delle transazioni
Proprietà del database specifica del mirroring che determina l'esecuzione della sessione di mirroring del database in modalità sincrona o asincrona. Esistono due livelli di protezione: FULL e OFF.

Testimone
Per l'utilizzo nella sola modalità a sicurezza elevata. Istanza facoltativa di SQL Server che consente al server mirror di stabilire se avviare un failover automatico. A differenza dei due partner di failover, il server di controllo non gestisce il database. L'unico ruolo del testimone è supportare il failover automatico.

Mirroring asincrono del database (modalità a elevate prestazioni)

In questa sezione vengono descritti il funzionamento del mirroring del database asincrono, i casi in cui è consigliabile utilizzare la modalità a elevate prestazioni e le operazioni da effettuare in caso di errore del server principale.

Quando il livello di protezione delle transazioni viene impostato su OFF, la sessione di mirroring del database opera in modo asincrono. Le operazioni asincrone supportano solo una modalità operativa, ovvero la modalità a prestazioni elevate. Questa modalità migliora le prestazioni, ma comporta una riduzione della disponibilità. La modalità a prestazioni elevate utilizza solo il server principale e il server mirror. I problemi relativi al server mirror non hanno mai alcun impatto sul server principale. In caso di perdita del server principale, il database mirror viene contrassegnato come DISCONNECTED, ma rimane disponibile come standby a caldo (warm standby).

La modalità a prestazioni elevate supporta solo una forma di cambio di ruolo, ovvero il servizio forzato (con possibile perdita dei dati), che prevede l'utilizzo del server mirror come server warm standby. Il servizio forzato rappresenta una delle risposte possibili all'errore del server principale. Poiché può verificarsi una perdita di dati, è consigliabile valutare altre alternative prima di forzare il servizio nel server mirror. Per ulteriori informazioni, vedere Risposta agli errori del server principalepiù avanti in questo argomento.

Nella figura seguente viene illustrata la configurazione di una sessione con l'utilizzo della modalità a prestazioni elevate.

In modalità a prestazioni elevate, non appena il server principale invia il log per una transazione al server mirror, il server principale invia una conferma al client, senza attendere un acknowledgement dal server mirror. Il commit delle transazioni viene eseguito senza attendere la scrittura su disco del log da parte del server mirror. L'operazione asincrona consente l'esecuzione del server principale con una latenza minima per le transazioni.

Il server mirror tenta di restare sincronizzato con i record del log inviati dal server principale. Il database mirror, tuttavia, è soggetto sempre a un certo ritardo rispetto al database principale. Il divario tra i database è in genere di entità ridotta, ma può diventare significativo se il server principale è soggetto a un ingente carico di lavoro o se il sistema del server mirror è sottoposto a overload.

Contenuto della sezione

• Casi in cui la modalità a prestazioni elevate rappresenta la soluzione più appropriata

• L'impatto di un witness sulla modalità a prestazioni elevate

• Risposta al guasto del server principale

Casi in cui la modalità a prestazioni elevate rappresenta la soluzione più appropriata

La modalità a prestazioni elevate può essere utile in uno scenario di ripristino di emergenza in cui i server principale e mirror sono separati da una distanza significativa e in cui non si desidera che piccoli errori abbiano un impatto sul server principale.

Impatto di un witness sulla modalità a elevate prestazioni

Se si utilizza Transact-SQL per configurare la modalità a prestazioni elevate, quando la proprietà SAFETY è impostata su OFF è consigliabile impostare su OFF anche la proprietà WITNESS. Un witness può coesistere con la modalità a prestazioni elevate, ma il witness non apporta alcun vantaggio e introduce dei rischi.

Se il witness viene disconnesso dalla sessione quando uno dei due partner non è più operativo, il database diventa indisponibile. Questo perché, sebbene la modalità a prestazioni elevate non richieda un server di controllo del mirroring, se ne viene configurato uno la sessione richiede un quorum costituito da due o più istanze del server. Se la sessione perde il quorum, non può rendere disponibile il database.

Quando in una sessione in modalità a prestazioni elevate viene impostato un server di controllo, l'applicazione del quorum significa quanto segue:

• Se il server mirror non è disponibile, il server principale deve essere connesso al server di controllo. In caso contrario, il server principale mette il database non in linea finché il server witness o il server mirror non rientra nella sessione.

• Se il server principale va perso, per forzare il passaggio del servizio al server mirror è necessario che il server mirror sia connesso al server testimone.

Risposta agli errori del server principale

Quando si verifica un errore nel server principale, il proprietario del database può scegliere tra le operazioni seguenti:

• Rendere il database non disponibile fino a quando il server principale non torna a essere nuovamente disponibile.

  Se il database principale e il relativo log delle transazioni sono intatti, questa scelta consente di mantenere tutte le transazioni di cui è stato eseguito il commit, a fronte di una riduzione della disponibilità.

• Arrestare la sessione di mirroring del database, aggiornare manualmente il database e quindi avviare una nuova sessione di mirroring del database.

  Se il database principale viene perduto ma il server principale resta in esecuzione, tentare immediatamente di eseguire il backup della parte finale del log nel database principale. Se il backup della parte finale del log ha esito positivo, la rimozione del mirroring potrebbe essere l'alternativa migliore. Dopo avere rimosso il mirroring, è possibile ripristinare il log nel database mirror precedente per mantenere tutti i dati.

  Nota

  Se il backup della parte finale del log ha esito negativo e non è possibile attendere il recupero del server principale, valutare la possibilità di forzare il servizio, operazione che consente di mantenere lo stato della sessione.

• Forzare l'avvio del servizio (con possibile perdita di dati) sul server mirror.

  Il servizio forzato rappresenta esclusivamente un metodo di ripristino di emergenza e deve essere utilizzato solo se necessario. È possibile forzare il servizio solo se il server principale non è disponibile, la sessione è asincrona (la sicurezza delle transazioni è impostata su OFF) e la sessione non ha alcun server di controllo del mirroring (la proprietà WITNESS è impostata su OFF) oppure il server di controllo del mirroring è connesso al server mirror (ossia i due dispongono del quorum).

  Forzando il servizio si consente al server mirror di assumere il ruolo di server principale e di rendere disponibile la propria copia del database ai client. Quando il servizio viene forzato, tutti i log delle transazioni non ancora inviati dal server principale al server mirror vengono perduti. È pertanto consigliabile limitare il servizio forzato alle situazioni in cui la perdita dei dati rappresenta un'opzione accettabile e la disponibilità immediata del database è un fattore critico. Per informazioni sul funzionamento del servizio forzato e sulle procedure di utilizzo consigliate, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).

Mirroring sincrono del database (modalità a sicurezza elevata)

Questa sezione descrive il funzionamento del mirroring sincrono del database, incluse le modalità alternative a protezione elevata (con failover automatico e senza failover automatico), e contiene informazioni sul ruolo del testimone nel failover automatico.

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 questa sezione vengono fornite informazioni dettagliate sulle sessioni di mirroring del database configurate per il funzionamento sincrono.

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.

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 sottoposto a hardening che non è stato ancora applicato al database mirror rimane nella coda di redo.

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.

Contenuto della sezione

• Modalità a sicurezza elevata senza failover automatico

• Modalità a sicurezza elevata con failover automatico

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 non è più disponibile, l'istanza del server principale non viene influenzata e continua a essere eseguita senza protezione, ovvero senza eseguire il 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 altre informazioni, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).

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 includa una terza istanza del server, il witness, idealmente situata su 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 witness non gestisce il database. Il witness supporta semplicemente il failover automatico verificando se il server principale è attivo e funzionante. Il server mirror avvia il failover automatico solo se il server mirror e il witness rimangono connessi tra loro dopo che entrambi sono stati disconnessi dal server principale.

Quando viene configurato un testimone, la sessione richiede il quorum, ovvero una relazione tra almeno due istanze del server che consente di rendere disponibile il database. Per altre informazioni, vedere Testimone del mirroring del database e Quorum: effetti di un testimone sulla disponibilità del database (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 istanze del server sono connesse e il server witness e il server mirror rimangono connessi.

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 altre informazioni, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).

• Se l'unico server mirror diventa non disponibile, il server principale e il server di controllo continuano a funzionare.

Se la sessione perde il witness, il quorum richiede 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 di un witness, il database non venga mai eseguito in modalità esposta, cioè senza mirroring.

Impostazioni di Transact-SQL e modalità operative del mirroring del database

In questa sezione viene descritta una sessione di mirroring del database in termini di impostazioni ALTER DATABASE e stati del database di cui viene eseguito il mirroring e dell'eventuale server di controllo. Le informazioni di questa sezione sono rivolte agli utenti che gestiscono il mirroring del database usando principalmente o esclusivamente Transact-SQL anziché SQL Server Management Studio.

Contenuto della sezione

• Come la sicurezza delle transazioni e lo stato del witness influiscono sul modo operativo

• Visualizzazione dell'impostazione di sicurezza e dello stato del witness

• Fattori che influiscono sul funzionamento della sessione in caso di perdita del server principale

Come la sicurezza delle transazioni e lo stato del witness influiscono sulla modalità operativa

La modalità operativa di una sessione è determinata dalla combinazione della sua impostazione della sicurezza delle transazioni e dallo stato del testimone. In qualsiasi momento, il proprietario del database può modificare il livello di sicurezza della transazione e aggiungere o rimuovere il testimone.

Contenuto della sezione

• Sicurezza delle transazioni

• Stato del witness

Sicurezza delle transazioni

Il livello di sicurezza delle transazioni è una proprietà del database specifica del mirroring che determina l'esecuzione della sessione di mirroring del database in modalità sincrona o asincrona. Esistono due livelli di protezione: FULL e OFF.

• Sicurezza Completa

  Il livello di sicurezza delle transazioni completo determina l'esecuzione della sessione in modo sincrono in modalità a sicurezza elevata. Se è presente un witness, una sessione supporta il failover automatico.

  Quando si stabilisce una sessione utilizzando ALTER DATABASE istruzioni, la sessione inizia con la proprietà SAFETY impostata su FULL, ovvero la sessione inizia in modalità a sicurezza elevata. Dopo l'avvio della sessione, è possibile aggiungere un testimone.

  Per altre informazioni, vedere Mirroring sincrono del database (modalità a sicurezza elevata), più indietro in questo argomento.

• SICUREZZA DISATTIVATA

  La disabilitazione della sicurezza delle transazioni determina l'esecuzione della sessione in modalità asincrona a prestazioni elevate. Se la proprietà SAFETY è impostata su OFF, è necessario impostare sul valore predefinito OFF anche la proprietà WITNESS. Per informazioni sull'impatto del witness in modalità a prestazioni elevate, vedere Stato del witness, più avanti in questo argomento. Per ulteriori informazioni sull'esecuzione con la protezione delle transazioni disattivata, vedere Mirroring asincrono del database (modalità a prestazioni elevate), in precedenza in questo argomento.

L'impostazione della sicurezza delle transazioni per il database viene registrata per ogni partner nelle colonne mirroring_safety_level e mirroring_safety_level_desc della vista del catalogo sys.database_mirroring. Per altre informazioni, vedere sys.database_mirroring (Transact-SQL).

Il proprietario del database può modificare il livello di sicurezza delle transazioni in qualsiasi momento.

Stato del witness

Se è stato configurato un witness, il quorum è necessario, quindi lo stato del witness è sempre significativo.

Se esiste, il witness può trovarsi in uno dei due stati:

• Quando il testimone è connesso a un partner, si trova nello stato CONNECTED rispetto a quel partner e ha il quorum con quel partner. In questo caso, è possibile rendere disponibile il database, anche se uno dei partner non è disponibile.

• Quando il witness esiste ma non è connesso a un partner, esso si trova nello stato UNKNOWN o DISCONNECTED rispetto a tale partner. In questo caso, il testimone non ha il quorum con quel partner e, se i partner non sono connessi tra loro, il database diventa indisponibile.

Per informazioni sul quorum, vedere Quorum: come un server di controllo influisce sulla disponibilità del database (mirroring del database).

Lo stato di ogni server di controllo del mirroring in un'istanza del server viene registrato nelle colonne mirroring_witness_state e mirroring_witness_state_desc della vista del catalogo sys.database_mirroring. Per altre informazioni, vedere sys.database_mirroring (Transact-SQL).

La tabella seguente riepiloga come la modalità operativa di una sessione dipenda dall'impostazione della sicurezza delle transazioni e dallo stato del witness.

*Se il witness si disconnette, si consiglia di impostare WITNESS OFF finché l'istanza del server witness non diventa disponibile.

**Se un server di controllo del mirroring è presente in modalità a prestazioni elevate, non partecipa alla sessione. Tuttavia, per rendere disponibile il database, è necessario che almeno due istanze del server rimangano connesse. È pertanto consigliabile mantenere la proprietà WITNESS impostata su OFF nelle sessioni in modalità a prestazioni elevate. Per ulteriori informazioni, vedere Quorum: come un witness influisce sulla disponibilità del database (mirroring del database).

Visualizzazione dell'impostazione di protezione e dello stato del witness

Per visualizzare l'impostazione di sicurezza e lo stato del witness per un database, utilizzare la vista del catalogo sys.database_mirroring. Le colonne rilevanti sono le seguenti:

Nel server principale o nel server mirror, ad esempio, immettere:

SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring  

Per altre informazioni su questa vista del catalogo, vedere sys.database_mirroring (Transact-SQL).

Fattori che influiscono sul funzionamento della sessione in caso di perdita del server principale

Nella tabella seguente sono riepilogati gli effetti combinati dell'impostazione del livello di protezione delle transazioni, dello stato del database e dello stato del server di controllo del mirroring sul funzionamento di una sessione di mirroring in caso di perdita del server principale.

Attività correlate

• Aggiungere o sostituire un server di controllo per il mirroring del database (SQL Server Management Studio)

• Stabilire una sessione di mirroring del database tramite autenticazione di Windows (SQL Server Management Studio)

• Aggiungere un testimone del mirroring del database tramite autenticazione di Windows (Transact-SQL)

• Rimuovere il witness da una sessione di mirroring del database (SQL Server)

• Modifica della protezione delle transazioni in una sessione di mirroring del database (Transact-SQL)

Vedi anche

Monitoraggio del mirroring del database (SQL Server)
Server di controllo del mirroring del database