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.
All'interno del contesto di una sessione di mirroring del database, i ruoli principale e mirror sono in genere intercambiabili in un processo noto come cambio di ruolo. Nel cambio di ruolo, il server mirror funge da partner di failover per il server principale, assumendo il ruolo principale, recuperando la copia del database e portandola online come nuovo database principale. Il server principale precedente, se disponibile, assume il ruolo mirror e il database diventa il nuovo database mirror. Potenzialmente, i ruoli possono alternarsi regolarmente in risposta a molti insuccessi o per scopi amministrativi.
Annotazioni
In questo argomento si presuppone che si abbia familiarità con le modalità operative del mirroring del database. Per altre informazioni, vedere Database Mirroring Operating Modes.
La figura seguente mostra i partner di mirroring, Partner_A e Partner_B, che scambiano i ruoli di principale e mirror, durante una serie di failover automatici o manuali.
Importante
Dopo un cambio di ruolo, i processi eseguiti nel database principale precedente devono essere ricreati nel nuovo server principale per l'esecuzione. Per altre informazioni, vedere Gestione di account di accesso e processi dopo il cambio di ruolo (SQL Server).For more information, see Management of Logins and Jobs After Role Switching (SQL Server).
Esistono tre tipi di cambio di ruolo: failover automatico, failover manuale e servizio forzato (con possibile perdita di dati). Il supporto per ogni modulo dipende dalla modalità operativa della sessione.
Annotazioni
Se non conosci queste modalità operative, vedere Modalità operative del mirroring del database.
Failover manuale
La modalità a sicurezza elevata supporta il failover manuale. Ogni volta che il database viene sincronizzato, il proprietario del database può avviare un failover manuale.
Il failover manuale è previsto per scopi amministrativi. Per altre informazioni, vedere Failover manuale più avanti in questo argomento.
Failover automatico
In presenza di un testimone, la modalità di alta sicurezza supporta il failover automatico. Il failover automatico si verifica solo in caso di perdita del server principale quando il server testimone e il server mirror sono ancora connessi tra loro e il database è già sincronizzato. Per altre informazioni, vedere Failover automatico più avanti in questo argomento.
Servizio forzato (con possibile perdita di dati)
Il servizio forzato è supportato in modalità a sicurezza elevata quando non è impostata alcuna istanza di witness e in modalità ad alte prestazioni. Nella perdita del server principale, il proprietario del database può rendere disponibile il database forzando il servizio al server mirror (con possibile perdita di dati).
Annotazioni
È consigliabile impostare la proprietà WITNESS su OFF in modalità a prestazioni elevate. In caso contrario, per portare online il database, il server mirror deve essere connesso al server di witness.
Per altre informazioni, vedere Servizio forzato (con possibile perdita di dati) più avanti in questo argomento.
Nella tabella seguente sono riepilogate le forme di failover supportate in ognuna delle modalità operative.
| Prestazioni elevate | Modalità ad alta sicurezza senza un testimone | Modalità a sicurezza elevata con un testimone | |
|---|---|---|---|
| Failover automatico | NO | NO | Sì |
| Failover manuale | NO | Sì | Sì |
| Servizio forzato | Sì | Sì | NO |
Dopo un cambio di ruolo, alcuni metadati devono esistere in entrambi i partner per garantire che tutti gli utenti del database possano accedere al nuovo database principale. Inoltre, i processi di backup devono essere creati nel nuovo server principale per assicurarsi che il database continui a essere sottoposto a backup in base alla pianificazione regolare. Per altre informazioni, vedere Gestione di account di accesso e processi dopo il cambio di ruolo (SQL Server).For more information, see Management of Logins and Jobs After Role Switching (SQL Server).
Durante un cambio di ruolo, la quantità di tempo in cui il mirroring del database sarà fuori servizio dipende dal tipo di cambio di ruolo e dalla causa. Per altre informazioni, vedere Stimare l'interruzione del servizio durante il cambio di ruolo (mirroring del database).
Failover manuale
Il failover manuale disconnette i client dal database e inverte i ruoli dei partner. Solo la modalità a sicurezza elevata supporta il failover manuale.
Gestione della disponibilità durante gli aggiornamenti
L'amministratore del database può usare il failover manuale per aggiornare hardware o software senza sacrificare la disponibilità. Per usare il mirroring del database per gli aggiornamenti software, il server mirror e/o il sistema devono aver già ricevuto gli aggiornamenti.
Annotazioni
Il mirroring del database deve essere in grado di eseguire un aggiornamento in sequenza, ma non è garantito, perché le modifiche future sono sconosciute. Per altre informazioni, vedere Ridurre al minimo i tempi di inattività per i database con mirroring durante l'aggiornamento delle istanze del server.
La figura seguente illustra un esempio di utilizzo del failover manuale per mantenere la disponibilità del database durante l'aggiornamento di un'istanza del server di database. Al termine dell'aggiornamento, un amministratore può opzionalmente eseguire il ripristino del failover all'istanza del server originale. Ciò è utile quando l'amministratore vuole arrestare la sessione di mirroring e usare il server mirror altrove. In questo modo, una singola istanza del server può essere usata ripetutamente durante l'aggiornamento di una serie di istanze del server di database.
Condizioni necessarie per un failover manuale
Il failover manuale richiede che la sicurezza delle transazioni sia impostata su FULL( ovvero la modalità a sicurezza elevata). Quando i partner sono connessi e il database è già sincronizzato, è supportato il failover manuale.
Funzionamento del failover manuale
Il failover manuale avvia la sequenza di azioni seguente:
Il server principale disconnette i client dal database principale, invia la parte finale del log al server mirror e, in preparazione al passaggio al ruolo mirror, imposta lo stato del mirroring su SYNCHRONIZING.
Il server mirror registra il numero di sequenza del log (LSN) dell'ultimo record di log ricevuto dal principale come LSN di failover.
Annotazioni
Per visualizzare questo LSN, selezionare la colonna mirroring_failover_lsn da sys.database_mirroring (Transact-SQL).
Se un log è in attesa nella coda di redo, il server mirror completa l'avanzamento del database mirror. La quantità di tempo necessaria dipende dalla velocità del sistema, dal carico di lavoro recente e dalla quantità di log nella coda di redo. Per una modalità operativa sincrona, il tempo di failover può essere regolato limitando le dimensioni della coda di redo. Tuttavia, ciò può causare il rallentamento del server principale per consentire al server mirror di rimanere al passo.
Annotazioni
Per informazioni sulle dimensioni correnti della coda di redo, usare il contatore delle prestazioni Coda di Redo nell'oggetto prestazioni del mirroring del database. Per altre informazioni, vedere Monitoraggio del mirroring del database (SQL Server).
Il server mirror diventa il nuovo server principale e il server principale precedente diventa il nuovo server mirror.
Il nuovo server principale esegue il rollback di tutte le transazioni di cui non è stato eseguito il commit e ne riporta online la copia come database principale.
L'ex preside assume il ruolo di specchio e l'ex database principale diventa il database di specchio. Il nuovo server mirror risincronizza rapidamente il nuovo database mirror con il nuovo database principale.
Annotazioni
Non appena il nuovo server mirror ha risincronizzato i database, è possibile eseguire di nuovo il failover, ma nella direzione inversa.
Dopo il failover, i client devono riconnettersi al database principale corrente. Per altre informazioni, vedere Connettere i client a una sessione di mirroring del database (SQL Server).
Per avviare il failover manuale
Failover automatico
Il failover automatico è supportato solo nelle sessioni di mirroring del database in esecuzione con un server di controllo del mirroring in modalità a sicurezza elevata (modalità a sicurezza elevata con failover automatico). In modalità a sicurezza elevata con failover automatico, una volta sincronizzato il database, se il database principale diventa non disponibile, si verifica un failover automatico. Un failover automatico fa sì che il server mirror assuma il ruolo del server principale e porti online la relativa copia del database come database principale. La richiesta di sincronizzazione del database impedisce la perdita di dati durante il failover, perché viene eseguito anche il commit di ogni transazione nel database principale nel database mirror.
Importante
Per migliorare l'affidabilità del failover automatico, il database mirror e quello principale devono risiedere in computer diversi.
Condizioni necessarie per un failover automatico
Il failover automatico richiede le condizioni seguenti:
La sessione di mirroring del database deve essere in esecuzione in modalità a sicurezza elevata e deve possedere un osservatore. Per altre informazioni, vedere Database Mirroring Operating Modes.
Il database mirror deve essere già sincronizzato. Ciò garantisce che tutto il log inviato al server mirror sia stato scritto su disco.
Il server principale ha perso la comunicazione con il resto della configurazione del mirroring del database, mentre il mirror e il server di controllo mantengono il quorum. Se tutte le istanze del server perdono la comunicazione, tuttavia, il server testimone e il server mirror ristabiliscono successivamente la comunicazione, il failover automatico non si verifica.
Annotazioni
Per ulteriori informazioni, vedere Quorum: Come un testimone influenza la disponibilità del database (Mirroring del Database).
Il server mirror ha rilevato la perdita del server principale.
Il modo in cui il server mirror rileva un errore del server principale dipende dal fatto che si tratti di un errore difficile o flessibile. Per altre informazioni, vedere Possibili errori durante il mirroring del database.
Come funziona il failover automatico
Nelle condizioni precedenti, il failover automatico avvia la sequenza di azioni seguente:
Se il server principale è ancora in esecuzione, cambia lo stato del database principale in DISCONNECTED e disconnette tutti i client dal database principale.
I server witness e mirror registrano che il server principale non è disponibile.
Se un log è in attesa nella coda di redo, il server mirror termina il rollforward del database mirror.
Annotazioni
La quantità di tempo necessaria per applicare il log dipende dalla velocità del sistema, dal carico di lavoro recente e dalla quantità di log nella coda di rifacimento.
Il precedente database specchio diventa attivo online come nuovo database principale e il ripristino pulisce tutte le transazioni non confermate eseguendo il rollback il prima possibile. I blocchi isolano tali transazioni.
Quando il server principale precedente si unisce nuovamente alla sessione, riconosce che il partner di failover detiene ora il ruolo principale. L'ex server principale assume il ruolo di mirror, trasformando il suo database nel database mirror. Il nuovo server mirror sincronizza il nuovo database mirror con il database principale il più rapidamente possibile. Non appena il nuovo server mirror ha risincronizzato i database, è possibile eseguire di nuovo il failover, ma nella direzione inversa.
La figura seguente mostra una singola istanza del failover automatico.
Inizialmente, tutti e tre i server sono connessi (la sessione ha un quorum completo). Partner_A è il server principale e Partner_B è il server mirror. Partner_A (o il database principale in Partner_A) non è più disponibile. Il testimone e Partner_B entrambi riconoscono che il mandante non è più disponibile e la sessione mantiene il quorum. Partner_B diventa il server principale e ne rende disponibile la copia come nuovo database principale. Alla fine, Partner_A si riconnette alla sessione e scopre che Partner_B ora detiene il ruolo principale. Partner_A assume quindi il ruolo mirror.
Dopo il failover, i client devono riconnettersi al database principale corrente. Per altre informazioni, vedere Connettere i client a una sessione di mirroring del database (SQL Server).
Annotazioni
Le transazioni preparate utilizzando Microsoft Distributed Transaction Coordinator, ma non vengono ancora sottoposte a commit quando si verifica un failover, vengono considerate interrotte dopo il failover del database.
Per disabilitare il failover automatico (SQL Server Management Studio)
Aprire la pagina Proprietà databaseMirroring e modificare la modalità operativa selezionando una delle opzioni seguenti:
Sicurezza elevata senza failover automatico (sincrono)
In questa modalità, il database continua a essere sincronizzato e il failover manuale rimane possibile.
Prestazioni elevate (asincrona)
In questa modalità, il database mirror potrebbe essere leggermente in ritardo rispetto al database principale e il failover manuale non è più possibile.
Per disabilitare il failover automatico (tramite Transact-SQL)
In qualsiasi momento in una sessione di mirroring del database, il proprietario del database può disabilitare il failover automatico disattivando il testimone.
Per disattivare il witness
Rimuovere il Witness da una sessione di mirroring del database (SQL Server)
Annotazioni
Disattivare il testimone mantenendo la sicurezza completa delle transazioni inserisce la sessione in modalità di alta sicurezza, senza failover automatico.
Servizio forzato (con possibile perdita di dati)
Il mirroring del database fornisce un servizio forzato (con possibile perdita di dati) come metodo di ripristino di emergenza per consentire di usare un server mirror come server warm standby. Il servizio forzato è possibile solo se il server principale è disconnesso dal server mirror in una sessione di mirroring. Poiché forzare il servizio comporta il rischio di possibili perdite di dati, è consigliabile usarlo con cautela e moderazione.
Il supporto per il servizio forzato dipende dalla modalità operativa e dallo stato della sessione, come indicato di seguito:
In genere, la modalità a prestazioni elevate supporta l'uso forzato del servizio ogni volta che il server principale viene disconnesso. Tuttavia, anche se non necessario, un testimone può esistere per una sessione in modalità ad alte prestazioni. In questo caso, l'uso forzato del servizio richiede che il server mirror e il testimone siano connessi tra loro.
La modalità a sicurezza elevata senza failover automatico supporta l'uso forzato del servizio ogni volta che il server principale viene disconnesso.
La modalità a sicurezza elevata con failover automatico supporta il forzamento del servizio ogni volta che il server mirror e il server testimone sono connessi tra loro e nessuno dei due è connesso al server principale (a condizione che il server mirror non fosse in fase di rollback del database mirror quando era connesso al server principale).
È consigliabile forzare il servizio solo se è necessario ripristinare immediatamente il servizio nel database e si è disposti a rischiare la perdita di dati. L'effetto dell'uso forzato del servizio è simile alla rimozione del mirroring, ad eccezione del fatto che l'uso forzato del servizio facilita la risincronizzazione dei database quando il mirroring viene ripreso, a rischio di possibile perdita di dati. L'uso forzato del servizio avvia una transizione uniforme del ruolo principale al database mirror. Il server mirror assume il ruolo di server principale e fornisce immediatamente la sua copia del database ai client. Il nuovo database principale viene eseguito senza un mirror, ovvero funziona in chiaro.
Importante
Se il server principale è stato semplicemente disconnesso dalla sessione di mirroring del database ed è ancora in esecuzione, alcuni client potrebbero continuare ad accedere al database principale originale. Prima di forzare il servizio, è importante impedire ai client di accedere al server principale originale. In caso contrario, dopo che il servizio è stato forzato, il database principale originale e il database principale corrente possono essere aggiornati indipendentemente dall'altro.
Caso tipico del servizio forzato
La figura seguente illustra un caso tipico di servizio forzato (con possibile perdita di dati).
Nella figura, il server principale originale , Partner_A, diventa non disponibile per il server mirror, Partner_B, causando la disconnessione del database mirror. Dopo aver verificato che Partner_A non sia disponibile per i client, l'amministratore del database forza il servizio, con possibile perdita di dati in Partner_B. Partner_B diventa il server principale e viene eseguito con il database esposto (ovvero, non duplicato). A questo punto, i client possono riconnettersi a Partner_B.
Quando Partner_A diventa disponibile, si riconnette al nuovo server principale, riunendosi alla sessione e assumendo il ruolo di mirror. La sessione di mirroring viene sospesa immediatamente, senza aver sincronizzato il nuovo database mirror. La sospensione della sessione consente all'amministratore del database di decidere se riprendere la sessione o, in casi estremi, rimuovere il mirroring e tentare di recuperare i dati dal database principale precedente. In questo caso, l'amministratore del database sceglie di riprendere il mirroring. A questo punto, Partner_A assume il ruolo del server mirror ed esegue il rollback del database principale precedente al momento dell'ultima transazione sincronizzata correttamente; se le transazioni di cui è stato eseguito il commit non sono state scritte su disco nel server mirror prima che il servizio sia stato forzato, vengono perse. Partner_A quindi esegue il rollforward del nuovo database mirror applicando le modifiche apportate al nuovo database principale dal momento che il server mirror precedente è diventato il nuovo server principale.
Annotazioni
Sebbene la modalità ad alte prestazioni non richieda un witness, se ne è configurato uno, è possibile forzare il servizio solo se il witness è attualmente connesso al server mirror.
Rischi di forzatura del servizio
È essenziale comprendere che l'uso forzato del servizio può causare la perdita di dati. La perdita di dati è possibile perché il server mirror non può comunicare con il server principale e pertanto non può garantire che i due database siano sincronizzati. Il servizio forzato avvia una nuova fork di ripristino. Poiché il database principale originale e il database mirror si trovano in fork di ripristino diversi, ogni database ora contiene dati che l'altro database non contiene: il database principale originale contiene eventuali modifiche non ancora inviate dalla coda di invio al database mirror precedente (il log non inviato); Il database mirror precedente contiene le modifiche apportate dopo che è stato forzato il servizio.
Se il servizio è forzato perché il server principale non è riuscito, la potenziale perdita di dati dipende dal fatto che i log delle transazioni non siano stati inviati al server mirror prima dell'errore. In modalità a sicurezza elevata è possibile solo fino a quando il database mirror non viene sincronizzato. Nella modalità a prestazioni elevate, l'accumulo di log non inviati può sempre verificarsi.
Le implicazioni del forzare il servizio dipendono in parte dal fatto che la sessione abbia un testimone:
In assenza di un testimone, il servizio può essere forzato se i partner vengono disconnessi, ad esempio perché la connessione di rete è interrotta. Se il server principale originale è ancora in esecuzione, entrambi i partner possiedono il ruolo principale. I client che si connettono al nuovo server principale accederanno alla versione corrente del database, mentre i client che si connettono al server principale originale accederanno al database principale originale. Questa situazione aumenta il potenziale di perdita di dati. Se i partner sono autorizzati a riconnettersi, il server principale originale assume il ruolo mirror e modifica lo stato del database in "ripristino", prima che il mirroring venga sospeso. Se la sessione viene ripresa, le transazioni nel database principale originale il cui log si trovava nella coda di invio a partire dalla disconnessione più recente vengono perse. Inoltre, anche le transazioni che si sono verificate dopo che il servizio è stato forzato vengono perse.
In presenza di un testimone, se il server mirror viene disconnesso sia dal server principale che dal testimone, purché gli ultimi due rimangano connessi tra loro, il server principale opera senza protezione. Se il server principale viene disconnesso dal testimone, smette di servire il database. Successivamente, se il server mirror si riconnette al testimone, forzare il servizio diventa possibile. Se il servizio è forzato, tutte le modifiche apportate durante l'esecuzione del server principale originale vengono perse se il server principale originale si riconnette.
Per altre informazioni, vedere Gestione della potenziale perdita di dati più avanti in questo argomento.
Gestione della potenziale perdita di dati
Dopo che il servizio è stato forzato, quando il server principale precedente è disponibile, supponendo che il database non sia danneggiato, è possibile tentare di gestire la potenziale perdita di dati. L'approccio disponibile per la gestione della potenziale perdita di dati dipende dal fatto che il server principale originale si sia riconnesso al proprio partner e si sia unito nuovamente alla sessione di mirroring. Supponendo che il server principale originale possa accedere alla nuova istanza principale, la riconnessione avviene automaticamente e in modo trasparente.
Il server principale originale è stato riconnesso
In genere, dopo un errore, quando il server principale originale viene riavviato si riconnette rapidamente al partner. Alla riconnessione, il server principale originale diventa il server mirror. Il database diventa il database mirror e passa allo stato di ripristino prima che la sessione venga sospesa. Il database mirror non sarà ripristinato a meno che non venga ripreso il mirroring.
Tuttavia, il database di recupero non è accessibile; pertanto, non è possibile esaminarlo per valutare quali dati andrebbero persi se si dovesse riprendere il mirroring. Pertanto, la decisione su se riprendere o rimuovere il mirroring dipende dal fatto che si sia disposti ad accettare qualsiasi perdita di dati.
Se la perdita di dati non è accettabile, è consigliabile rimuovere il mirroring per recuperarli.
La rimozione del mirroring consente all'amministratore del database di recuperare il database principale originale e di tentare di recuperare i dati che sarebbero stati persi. Tuttavia, quando il database mirror precedente viene online, i partner precedenti serviranno database divergenti con lo stesso nome. L'amministratore del database deve rendere uno dei database inaccessibili ai client per evitare ulteriori differenze del database e per evitare problemi di failover del client.
Se la perdita di dati sarebbe accettabile, è possibile riprendere il mirroring.
La ripresa del mirroring determina il rollback del nuovo database mirror come primo passaggio per la sincronizzazione del database. Se i record di log erano in attesa nella coda di invio al momento dell'errore, le transazioni corrispondenti saranno perse, anche se sono state confermate.
Il server principale originale non è stato riconnesso
Se è possibile impedire temporaneamente al server principale originale di riconnettersi tramite la rete al nuovo server principale, è possibile esaminare il database principale originale per valutare quali dati andrebbero persi se il mirroring fosse stato ripreso.
Se la potenziale perdita di dati è accettabile
Consentire al server principale originale di riconnettersi al partner. La riconnessione causa la sospensione del mirroring. Per procedere con il mirroring, è sufficiente riprendere la sessione. Il server principale precedente assume il ruolo mirror. Il nuovo server mirror elimina il fork di recupero originale, perdendo tutte le transazioni che non sono mai state inviate o ricevute dal server mirror precedente.
Se la perdita di dati è inaccettabile
Se il database principale originale contiene dati critici che andrebbero persi se è stata ripresa la sessione, è possibile conservare i dati nel server principale originale rimuovendo il mirroring. Si consiglia di tentare di eseguire il backup della parte finale del log principale a questo punto. È quindi possibile aggiornare l'entità corrente (il database mirror precedente) esportando i dati da salvare dal database principale originale e importandoli nel database principale corrente. È consigliabile eseguire un backup completo del database aggiornato il più rapidamente possibile.
Per ristabilire il mirroring con il database aggiornato come database principale iniziale, usare questo backup (e almeno un backup del log successivo) per creare un nuovo database mirror. È necessario applicare ogni backup del log eseguito dopo la rimozione del mirroring. È pertanto consigliabile ritardare i backup aggiuntivi del log del database principale fino all'avvio della nuova sessione di mirroring.
Attività correlate per la gestione di un failover forzato
Per forzare il servizio
Per riprendere il mirroring del database
Per creare un nuovo database mirror
Preparazione di un database mirror per il mirroring (SQL Server)
Per avviare il mirroring del database
Vedere anche
Stimare l'interruzione del servizio durante il cambio di ruolo (mirroring del database)
Possibili errori durante il mirroring del database
Connettere i client a una sessione di mirroring del database (SQL Server)
Testimone del Mirroring del Database
Ripristini di database completi (modello di recupero completo)
Modalità operative di mirroring del database
Stati di mirroring (SQL Server)