Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In questo argomento vengono descritte le modalità operative sincrone e asincrone per le sessioni di mirroring del database.
Annotazioni
Per un'introduzione al mirroring del database, consulta Mirroring del database (SQL Server).
Termini e definizioni
Questa sezione presenta alcuni termini fondamentali per questo argomento.
Modalità a prestazioni elevate
La sessione di mirroring del database funziona in modo asincrono e usa solo 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 opera in modo sincrono e può usare facoltativamente un server di controllo, oltre al server principale e al server mirror.
Sicurezza delle transazioni
Una proprietà del database specifica del mirroring che determina se una sessione di mirroring opera sincrona o asincrona. Esistono due livelli di sicurezza: FULL e OFF.
Testimone
Per l'uso solo con la modalità a protezione elevata, un'istanza facoltativa di SQL Server che consente al server mirror di riconoscere se avviare un failover automatico. A differenza dei due partner di failover, il testimone non gestisce il database. Supportare il failover automatico è l'unico ruolo del witness.
Mirroring asincrono del database ( modalitàHigh-Performance)
Questa sezione descrive il funzionamento del mirroring asincrono del database, quando è appropriato usare la modalità a prestazioni elevate e come rispondere in caso di errore del server principale.
Annotazioni
La maggior parte delle edizioni di SQL Server 2014 supporta solo il mirroring sincrono del database ("Safety Full Only"). Per informazioni sulle edizioni che supportano completamente il mirroring del database, vedere "Disponibilità elevata (AlwaysOn)" in Funzionalità supportate dalle edizioni di SQL Server 2014.
Quando la sicurezza delle transazioni è impostata su OFF, la sessione di mirroring del database viene eseguita in modo asincrono. L'operazione asincrona supporta una sola modalità operativa a prestazioni elevate. Questa modalità migliora le prestazioni a scapito della disponibilità elevata. La modalità a prestazioni elevate usa solo il server principale e il server mirror. I problemi sul server mirror non influisce mai sul server principale. Nella perdita del server principale, il database mirror è contrassegnato come DISCONNECTED ma è disponibile come warm standby.
La modalità a prestazioni elevate supporta solo una forma di cambio di ruolo: servizio forzato (con possibile perdita di dati), che usa il server mirror come server warm standby. Il servizio forzato è una delle possibili risposte all'errore del server principale. Poiché la perdita di dati è possibile, è consigliabile prendere in considerazione altre alternative prima di forzare il servizio al mirror. Per ulteriori informazioni, vedere Rispondere al guasto del principale, più avanti in questo argomento.
Nella figura seguente viene illustrata la configurazione di una sessione che usa la 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. Le transazioni eseguono il commit senza attendere che il server mirror scriva il log su disco. L'operazione asincrona consente l'esecuzione del server principale con latenza minima delle transazioni.
Il server mirror tenta di mantenere il passo con i record di log inviati dal server principale. Tuttavia, il database mirror potrebbe essere leggermente indietro rispetto al database principale, anche se in genere il divario tra i database è ridotto. Tuttavia, il divario può diventare sostanziale se il server principale è sottoposto a un carico di lavoro elevato o il sistema del server specchio è sovraccarico.
Quando è appropriata la modalità High-Performance?
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 influiscano sul server principale.
Annotazioni
Il log shipping può essere un supplemento al mirroring del database ed è un'alternativa favorevole al mirroring asincrono del database. Per informazioni sui vantaggi del log shipping, vedere Soluzioni a disponibilità elevata (SQL Server). Per informazioni sull'uso del log shipping con il mirroring del database, consultare Mirroring del database e log shipping (SQL Server).
Impatto di un testimone in modalità High-Performance
Se si utilizza Transact-SQL per configurare la modalità a prestazioni elevate, ogni volta che la proprietà SAFETY è impostata su OFF, è consigliabile impostare anche la proprietà WITNESS su OFF. Un testimone può coesistere con la modalità a prestazioni elevate, ma il testimone non offre alcun vantaggio e comporta rischi.
Se il testimone viene disconnesso dalla sessione quando uno dei partner diventa inattivo, il database diventa non disponibile. Ciò è dovuto al fatto che, anche se la modalità a prestazioni elevate non richiede un testimone, se ne è impostato uno, la sessione richiede un quorum costituito da due o più istanze del server. Se la sessione perde il quorum, non può gestire il database.
Quando un testimone viene impostato in una sessione in modalità ad alte prestazioni, l'applicazione del quorum significa che:
Se il server mirror viene perso, il server principale deve essere connesso al server testimone. In caso contrario, il server principale porta offline il database fino a quando il server testimone o il server mirror non si unisce nuovamente alla sessione.
Se il server principale viene perso, forzare il servizio al server mirror richiede che il server mirror sia connesso al testimone.
Annotazioni
Per informazioni sui tipi di quorum, vedere Quorum: Come un Witness influisce sulla disponibilità del database (Mirroring del Database).
Rispondere al fallimento del principale
Quando il principale fallisce, il proprietario del database ha diverse opzioni, come indicato di seguito:
Lasciare il database non disponibile fino a quando il principale non diventa nuovamente disponibile.
Se il database principale e il relativo log delle transazioni sono intatti, questa scelta mantiene tutte le transazioni di cui è stato eseguito il commit a scapito 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 perso ma il server principale è ancora in esecuzione, provare immediatamente a eseguire il backup della parte finale del log nel database principale. Se il backup del tail-log ha esito positivo, la rimozione del mirroring potrebbe essere la tua migliore alternativa. Dopo aver rimosso il mirroring, è possibile ripristinare il log nel database mirror precedente, che mantiene tutti i dati.
Annotazioni
Se il backup della parte finale del log non è riuscito e non è possibile attendere il ripristino del server principale, è consigliabile forzare il servizio, con il vantaggio di mantenere lo stato della sessione.
Esegui il servizio (con possibile perdita di dati) sul server replica.
Il servizio forzato è strettamente un metodo di ripristino di emergenza e deve essere usato con moderazione. L'uso forzato del servizio è possibile solo se il server principale è inattivo, la sessione è asincrona (la sicurezza delle transazioni è impostata su OFF) e la sessione non dispone di alcun testimone (la proprietà WITNESS è impostata su OFF) oppure il testimone è connesso al server mirror (ovvero, hanno il quorum).
Forzando il servizio, il server mirror assume il ruolo di principale e serve la sua copia del database ai client. Quando il servizio viene forzato, i log delle transazioni che il server principale non ha ancora inviato al server mirror vengono persi. Pertanto, è consigliabile limitare il servizio forzato a situazioni in cui la possibile perdita di dati è accettabile e la disponibilità immediata del database è fondamentale. Per informazioni sul funzionamento del servizio forzato e sulle procedure consigliate per l'uso, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).
Mirroring sincrono del database (ModalitàHigh-Safety)
Questa sezione descrive come funziona il mirroring sincrono del database, incluse le modalità alternative di alta sicurezza (con e senza failover automatico) e contiene informazioni sul ruolo del testimone nel failover automatico.
Quando la sicurezza delle transazioni è impostata su FULL, la sessione di mirroring del database viene eseguita in modalità a sicurezza elevata e viene eseguita in modo sincrono dopo una fase di sincronizzazione iniziale. Questa sezione descrive i dettagli delle sessioni di mirroring del database configurate per l'operazione sincrona.
Per ottenere un'operazione sincrona per una sessione, il server mirror deve sincronizzare il database mirror con il database principale. All'avvio della sessione, il server principale inizia a inviare il log attivo al server mirror. Il server mirror scrive tutti i record di log in ingresso su disco il più rapidamente possibile. Non appena tutti i record di log ricevuti sono stati scritti su disco, i database vengono sincronizzati. Finché i partner rimangono in comunicazione, i database rimangono sincronizzati.
Annotazioni
Per monitorare le modifiche dello stato in una sessione di mirroring del database, utilizzare la classe di evento Database Mirroring State Change . Per altre informazioni, vedere Classe di evento Database Mirroring State Change.
Al termine della sincronizzazione, viene eseguito anche il commit di ogni transazione eseguita nel database principale nel server mirror, garantendo la protezione dei dati. Questa operazione viene ottenuta attendendo di eseguire il commit di una transazione nel database principale, fino a quando il server principale non riceve un messaggio dal server mirror che informa che è stata completata la protezione avanzata del log della transazione su disco. Si noti che l'attesa di questo messaggio aumenta la latenza della transazione.
Il tempo necessario per la sincronizzazione dipende essenzialmente dalla distanza in cui il database mirror si trovava dietro il database principale all'inizio della sessione (misurato dal numero di record di log inizialmente ricevuti dal server principale), dal carico di lavoro sul database principale e dalla velocità del sistema mirror. Dopo che una sessione è stata sincronizzata, il log consolidato che deve ancora essere ripristinato nel database mirror rimane nella coda di ripristino.
Non appena il database mirror viene sincronizzato, lo stato di entrambe le copie del database viene modificato in SYNCHRONIZED.
L'operazione sincrona viene mantenuta nel modo seguente:
Quando si riceve una transazione da un client, il server principale scrive il log per la transazione nel log delle transazioni.
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 una delle operazioni seguenti al client: un commit della transazione o un rollback.
Il server di replica scrive definitivamente il log su disco e restituisce una conferma al server principale.
Quando riceve l'acknowledgement dal server mirror, il server principale invia un messaggio di conferma al client.
La modalità a sicurezza elevata protegge i dati richiedendo la sincronizzazione dei dati tra due posizioni. Tutte le transazioni di cui è stato eseguito il commit devono essere scritte su disco nel server mirror.
High-Safety modalità senza failover automatico
La figura seguente illustra la configurazione della modalità a sicurezza elevata senza failover automatico. La configurazione è costituita solo dai due partner.
Quando 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 è interessata e continua a funzionare senza protezione, ovvero senza eseguire il mirroring dei dati. Se il server principale viene perso, il mirror viene sospeso, ma il servizio può essere forzato al server mirror (con possibile perdita di dati). Per altre informazioni, vedere Cambio di ruolo durante una sessione di mirroring del database (SQL Server).
High-Safety modalità con failover automatico
Il failover automatico offre disponibilità elevata assicurandosi che il database sia ancora servito dopo la perdita di un server. Il failover automatico richiede che la sessione possieda una terza istanza del server, il witness, che idealmente risiede su un terzo computer. La figura seguente illustra la configurazione di una sessione in modalità a sicurezza elevata che supporta il failover automatico.
A differenza dei due partner, il testimone non serve il database. Il witness supervisiona semplicemente il failover automatico verificando se il server principale è attivo e funzionante. Il server mirror avvia il failover automatico solo se rimane connesso al testimone dopo che entrambi sono stati disconnessi dal server principale.
Quando è impostato un testimone, la sessione richiede un quorum, una relazione tra almeno due istanze del server che consente di rendere disponibile il database. Per ulteriori informazioni, vedere Testimone del mirroring del database e Quorum: in che modo un testimone influisce sulla disponibilità del database (mirroring del database).
Il failover automatico richiede le condizioni seguenti:
Il database è già sincronizzato.
L'errore si verifica mentre tutte e tre le istanze del server sono connesse e il server testimone e il server di mirroring rimangono connessi.
La perdita di un partner ha l'effetto seguente:
Se il server principale non è più disponibile nelle condizioni precedenti, si verifica il failover automatico. Il server mirror passa al ruolo di entità e ne offre il database come database principale.
Se il server principale non è più disponibile quando tali condizioni non vengono soddisfatte, potrebbe essere possibile forzare il servizio (con 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 non è più disponibile, il server principale e il server di witness continuano.
Se la sessione perde il testimone, il quorum richiede entrambi i partner. Se uno dei partner perde il quorum, entrambi i partner perdono il quorum e il database diventa non disponibile fino a quando il quorum non viene ristabilito. Questo requisito del quorum garantisce che in assenza di un server di controllo del mirroring il database non venga mai eseguito esposto, ovvero senza essere sottoposto a mirroring.
Annotazioni
Se ci si aspetta che il testimone rimanga disconnesso per un periodo di tempo significativo, consigliamo di rimuovere il testimone dalla sessione fino a quando non diventa disponibile.
Transact-SQL Impostazioni e modalità operative di mirroring del database
In questa sezione viene descritta una sessione di mirroring del database in termini delle impostazioni e degli stati ALTER DATABASE del database con mirroring e del testimone, ove presente. La sezione è rivolta agli utenti che gestiscono il mirroring del database principalmente o esclusivamente tramite Transact-SQL, anziché usare SQL Server Management Studio.
Suggerimento
In alternativa all'uso di Transact-SQL, è possibile controllare la modalità operativa di una sessione in Esplora oggetti usando la pagina Mirroring della finestra di dialogo Proprietà database . Per altre informazioni, vedere Stabilire una sessione di mirroring del database usando l'autenticazione di Windows (SQL Server Management Studio).
Come la sicurezza delle transazioni e lo stato del witness influiscono sulla modalità operativa
La modalità operativa di una sessione è determinata dalla combinazione dell'impostazione di sicurezza delle transazioni e dallo stato del testimone. In qualsiasi momento, il proprietario del database può modificare il livello di sicurezza delle transazioni e può aggiungere o rimuovere il testimone.
Sicurezza delle transazioni
La sicurezza delle transazioni è una proprietà del database specifica del mirroring che determina se una sessione di mirroring del database opera in modo sincrono o asincrono. Esistono due livelli di sicurezza: FULL e OFF.
Sicurezza Completa
La sicurezza completa delle transazioni fa sì che la sessione funzioni in modo sincrono in modalità a sicurezza elevata. Se è presente un testimone, una sessione supporta il failover automatico.
Quando si stabilisce una sessione utilizzando istruzioni ALTER DATABASE, la sessione inizia con la proprietà SAFETY impostata su FULL; ovvero, la sessione inizia in modalità a sicurezza elevata. Dopo l'inizio della sessione, è possibile aggiungere un testimone.
Per altre informazioni, vedere Mirroring sincrono del database ( modalitàHigh-Safety), come riportato in precedenza in questo argomento.
SAFETY OFF
La disattivazione della sicurezza delle transazioni fa sì che la sessione funzioni in modo asincrono, in modalità a prestazioni elevate. Se la proprietà SAFETY è impostata su OFF, la proprietà WITNESS deve essere impostata anche su OFF (impostazione predefinita). Per informazioni sull'impatto del testimone in modalità ad alte prestazioni, vedere Lo stato del testimone, più avanti in questo argomento. Per altre informazioni sull'esecuzione con sicurezza delle transazioni disattivata, vedere Mirroring asincrono del database (modalitàHigh-Performance) più indietro 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 Testimone
Se è stato impostato un testimone, è richiesto un quorum, quindi lo stato del testimone è sempre significativo.
Se esiste, il testimone ha uno dei due stati.
Quando il server di controllo del mirroring è connesso a un partner, il server di controllo del mirroring si trova nello stato CONNECTED rispetto a tale partner e dispone del quorum con tale partner. In questo caso, il database può essere reso disponibile, anche se uno dei partner non è disponibile.
Quando il testimone esiste ma non è connesso a un partner, il testimone si trova nello stato UNKNOWN o DISCONNECTED rispetto a quel partner. In questo caso, il server di controllo del mirroring non dispone del quorum con tale partner e, se i partner non sono connessi tra loro, il database diventa non disponibile.
Per informazioni sul quorum, vedere Quorum: Come un Testimone Influisce sulla Disponibilità del Database (Mirroring del Database).
Lo stato di ciascun testimone su un'istanza del server viene registrato nella vista del catalogo sys.database_mirroring nelle colonne mirroring_witness_state e mirroring_witness_state_desc. Per altre informazioni, vedere sys.database_mirroring (Transact-SQL).
Nella tabella seguente viene riepilogato il modo in cui la modalità operativa di una sessione dipende dall'impostazione di sicurezza delle transazioni e dallo stato del testimone.
| Modalità operativa | Sicurezza delle transazioni | Stato di testimone |
|---|---|---|
| Modalità a prestazioni elevate | SPENTO | NULL (nessun testimone)2 |
| Modalità a sicurezza elevata senza failover automatico | COMPLETO | NULL (nessun testimone) |
| Modalità a sicurezza elevata con ripristino automatico1 | COMPLETO | CONNESSO |
1 Se il server di testimone viene disconnesso, è consigliabile impostare WITNESS OFF fino a quando l'istanza del server di testimone non sarà nuovamente disponibile.
2 Se un testimone è presente in modalità ad alte prestazioni, il testimone non partecipa alla sessione. Tuttavia, per rendere disponibile il database, almeno due istanze del server devono rimanere connesse. È pertanto consigliabile mantenere impostata la proprietà WITNESS su OFF nelle sessioni in modalità a prestazioni elevate. Per ulteriori informazioni, vedere Quorum: Come un testimone influenza la disponibilità del database (Mirroring del Database).
Visualizzazione dell'impostazione di sicurezza e dello stato del testimone
Per visualizzare l'impostazione di sicurezza e lo stato del testimone per un database, utilizzare la vista del catalogo sys.database_mirroring. Le colonne pertinenti sono le seguenti:
| Fattore | Colonne | Descrizione |
|---|---|---|
| Sicurezza delle transazioni | livello_di_sicurezza_specchio o descrizione_livello_di_sicurezza_specchio | Impostazione di sicurezza delle transazioni per gli aggiornamenti nel database mirror, uno dei seguenti: SCONOSCIUTO SPENTO COMPLETO NULL= il database non è online. |
| Esiste un testimone? | mirroring_witness_name | Nome del server del testimone del mirroring del database o NULL, che indica che non esiste nessun testimone. |
| Stato del server di controllo del mirroring | mirroring_witness_state o mirroring_witness_state_desc | Stato del testimone nel database su un determinato partner: SCONOSCIUTO CONNESSO SCONNESSO NULL = non esiste alcun server di controllo del mirroring o il database non è online. |
Ad esempio, nel server principale o mirror 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 comportamento in caso di perdita del server principale
La tabella seguente riepiloga l'effetto combinato dell'impostazione di sicurezza delle transazioni, lo stato del database e lo stato del server di controllo del mirroring sul comportamento di una sessione di mirroring sulla perdita del server principale.
| Sicurezza delle transazioni | Stato del mirroring del database di mirroring | Stato del testimone | Comportamento quando il principale viene perso |
|---|---|---|---|
| COMPLETO | SINCRONIZZATO | CONNESSO | Si verifica il failover automatico. |
| COMPLETO | SINCRONIZZATO | SCONNESSO | Il server mirror si arresta; il failover non è possibile e il database non può essere reso disponibile. |
| SPENTO | SOSPESO o DISCONNESSO | NULL (nessun testimone) | Un servizio può essere forzato al server mirror (con possibile perdita di dati). |
| COMPLETO | SINCRONIZZAZIONE o SOSPENSIONE | NULL (nessun testimone) | Il servizio può essere costretto al server mirror (con possibile perdita di dati). |
Attività correlate
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)
Vedere anche
Monitoraggio del mirroring del database (SQL Server)
Testimone del Mirroring del Database