Articolo
03/31/2012

Servizio forzato (con possibile perdita di dati)

Il mirroring del database include l'utilizzo forzato del servizio (con possibile perdita di dati) come metodo di recupero di emergenza per consentire l'utilizzo di un server mirror come server di standby a caldo (warm standby). Il servizio forzato è possibile solo se il server principale è disconnesso dal server mirror in una sessione di mirroring. Dato che l'utilizzo forzato del servizio determina il rischio di possibili perdite di dati, è consigliabile utilizzarlo con cautela e quando strettamente necessario.

Il supporto per l'utilizzo forzato del servizio dipende dalla modalità operativa e dallo stato della sessione, come segue:

In genere, la modalità a prestazioni elevate supporta l'utilizzo forzato del servizio ogniqualvolta il server principale è disconnesso. Sebbene non sia necessario, è tuttavia possibile che un server di controllo del mirroring sia presente per una sessione in modalità a prestazioni elevate. In questo caso, l'utilizzo forzato del servizio richiede che il server mirror e il server di controllo del mirroring siano connessi tra loro.
La modalità a protezione elevata senza failover automatico supporta l'utilizzo forzato del servizio ogniqualvolta il server principale è disconnesso.
La modalità a protezione elevata con failover automatico supporta l'utilizzo forzato del servizio ogniqualvolta il server mirror e il server di controllo del mirroring sono connessi tra loro e nessuno dei due è connesso al server principale, a condizione che sul server mirror non sia in corso il rollback del database mirror al momento dell'ultima connessione al server principale.

È consigliabile forzare il servizio solo se è necessario ripristinare immediatamente il servizio sul database e si è disposti a rischiare la perdita di dati. L'utilizzo forzato del servizio ha un effetto analogo alla rimozione del mirroring, ad eccezione del fatto che semplifica la risincronizzazione dei database quando il mirroring viene ripreso, con rischio di possibile perdita di dati. L'utilizzo forzato del servizio avvia una transizione uniforme del ruolo principale al database mirror. Il server mirror assume il ruolo di server principale e rende immediatamente disponibile la propria copia del database ai client. Il nuovo database principale viene eseguito senza un mirror, ovvero senza mirroring.

Importante
Se il server principale è stato semplicemente disconnesso dalla sessione di mirroring del database ed è ancora in esecuzione, è possibile che alcuni client continuino ad accedere al database principale originale. Dopo aver forzato il servizio, è importante impedire ai client l'accesso al server principale originale. In caso contrario, dopo l'utilizzo forzato del servizio, è possibile che il database principale originale e il database principale corrente vengano aggiornati in modo indipendente l'uno dall'altro.

Se il server principale è stato semplicemente disconnesso dalla sessione di mirroring del database ed è ancora in esecuzione, è possibile che alcuni client continuino ad accedere al database principale originale. Dopo aver forzato il servizio, è importante impedire ai client l'accesso al server principale originale. In caso contrario, dopo l'utilizzo forzato del servizio, è possibile che il database principale originale e il database principale corrente vengano aggiornati in modo indipendente l'uno dall'altro.

Caso tipico di utilizzo forzato del servizio

Nella figura seguente viene illustrato un caso tipico di utilizzo forzato del servizio (con possibile perdita di dati).

Forzatura del servizio con possibile perdita di dati

Come illustrato 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 è disponibile ai client, l'amministratore del database forza il servizio, con possibilità di perdita di dati, su Partner_B. Partner_B diventa il server principale e viene eseguito con il database esposto, ovvero senza mirroring. A questo punto, i client possono riconnettersi a Partner_B.

Quando Partner_A diventa disponibile, riconnette il nuovo server principale, si riconnette alla sessione e assume il ruolo di mirror. La sessione di mirroring viene sospesa immediatamente, senza sincronizzazione del 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 salvare 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 di server mirror ed esegue il rollback del database principale originale dal momento dell'ultima transazione sincronizzata eseguita correttamente. Eventuali transazioni con commit che non siano state scritte sul disco del server mirror prima dell'utilizzo forzato del servizio vengono perdute. Partner_A esegue quindi il rollforward del nuovo database mirror applicando eventuali modifiche apportate al nuovo database principale dal momento in cui il server mirror precedente è diventato il nuovo server principale.

Nota

Sebbene la modalità a prestazioni elevate non ne richieda la presenza, se un server di controllo del mirroring è configurato, è possibile forzare il servizio solo se il server di controllo del mirroring è attualmente connesso al server mirror.

Rischi correlati all'utilizzo forzato del servizio

È fondamentale comprendere che l'utilizzo forzato del servizio può causare la perdita di dati. La perdita di dati è possibile in quanto il server mirror non è in grado di comunicare con il server principale e pertanto non può garantire che i due database siano sincronizzati. L'utilizzo forzato del servizio comporta l'avvio di un nuovo fork di recupero. Poiché il database principale originale e il database mirror si trovano su fork di recupero diversi, ogni database includerà i dati che l'altro database non include. Il database principale originale include tutte le modifiche non inviate al database mirror precedente dalla sua coda di invio (il log non inviato). Il database mirror precedente include tutte le modifiche apportate dopo che il servizio è stato forzato.

Nota

Per ulteriori informazioni sui fork di recupero, vedere Percorsi di recupero.

Se il servizio viene forzato a causa di un errore del server principale, la potenziale perdita di dati dipende dal fatto che uno o più log delle transazioni non siano stati inviati al server mirror prima dell'errore. In modalità a protezione elevata, questo è possibile solo finché il database mirror viene sincronizzato. In modalità a prestazioni elevate, è sempre possibile la presenza di log non inviato accumulato.

Le implicazioni dell'utilizzo forzato del servizio dipendono in parte dal fatto che la sessione disponga o meno di un server di controllo del mirroring:

In sua assenza, è possibile forzare il servizio se i partner vengono disconnessi, ad esempio, perché la relativa connessione di rete si interrompe. Se il server principale originale è ancora in esecuzione, entrambi i partner sono proprietari del ruolo principale. I client che si connettono al nuovo server principale avranno accesso alla versione corrente del database, mentre i client che si connettono al server principale originale avranno accesso al database principale originale. Questa situazione aumenta il rischio di perdita di dati. Se ai partner è consentita la riconnessione, il server principale originale assume il ruolo di mirror e modifica lo stato del proprio database impostandolo su "recupero in corso," prima della sospensione del mirroring. Se la sessione viene ripresa, le transazioni sul database principale originale i cui log si trovavano nella coda di invio al momento della disconnessione più recente vanno perdute. Vanno inoltre perdute eventuali transazioni verificatesi dopo l'utilizzo forzato del servizio.
In presenza di un server di controllo del mirroring, se il server mirror viene disconnesso dal server principale e dal server di controllo del mirroring, finché questi ultimi rimangono connessi tra loro, il server principale è in esecuzione senza mirroring. Se il server principale viene quindi disconnesso dal server di controllo del mirroring, smette di interagire con il database. Se successivamente il server mirror si riconnette al server di controllo del mirroring, diventa possibile l'utilizzo forzato del servizio. Se il servizio viene forzato, tutte le modifiche apportate mentre il server principale originale era in esecuzione senza mirroring verranno perdute, se il server principale originale viene riconnesso.

Per ulteriori informazioni, vedere "Gestione della potenziale perdita di dati" di seguito in questo argomento.

Gestione della potenziale perdita di dati

Dopo l'utilizzo forzato del servizio, quando il server principale precedente è disponibile e supponendo che il relativo database non sia danneggiato, è possibile tentare di gestire la potenziale perdita di dati. La tecnica disponibile per la gestione della potenziale perdita di dati dipende dal fatto che il server principale originale sia stato riconnesso al relativo partner e si sia ricollegato alla sessione di mirroring. Supponendo che il server principale originale possa accedere alla nuova istanza principale, la riconnessione avviene in modo automatico e trasparente.

Il server principale originale si è riconnesso

In genere, dopo un errore, al riavvio, il server principale originale si riconnette rapidamente al proprio partner. Alla riconnessione, il server principale originale diventa il server mirror. Il relativo database diventa il database mirror e assume lo stato di recupero prima che la sessione venga sospesa. Per il database mirror non verrà eseguito il rollback a meno che non venga ripreso il mirroring.

Il database in fase di recupero è tuttavia inaccessibile, pertanto non è possibile verificarlo per valutare i dati che andrebbero perduti in caso di ripresa del mirroring. Pertanto, la decisione relativa alla ripresa o alla rimozione del mirroring dipende dal fatto che sia accettabile o meno l'eventuale perdita di dati.

Se la perdita di dati non è accettabile, rimuovere il mirroring per salvare i dati.

La rimozione del mirroring consentirà all'amministratore del database di recuperare il database principale originale e di tentare di recuperare i dati a rischio di perdita. Tuttavia, quando il database mirror precedente torna online, i partner precedenti interagiranno con database divergenti con lo stesso nome. L'amministratore del database deve rendere uno dei database inaccessibile ai client per evitare ulteriori divergenze del database e per impedire problemi di failover dei client.
Se la perdita di dati è accettabile, è possibile riprendere il mirroring.

La ripresa del mirroring determina il rollback del nuovo database mirror come primo passaggio della sincronizzazione del database. Se nella coda di invio erano in attesa record di log al momento dell'errore, le transazioni corrispondenti vengono perdute, anche se con commit.

Il server principale originale non si è riconnesso

Se è possibile impedire temporaneamente la riconnessione sulla rete del server principale originale al nuovo server principale, è possibile esaminare il server principale originale per valutare quali dati andrebbero perduti in caso di ripresa del mirroring.

Contesti in cui la perdita di dati è accettabile

Consentire la riconnessione al partner del server principale originale. La riconnessione determina la sospensione del mirroring. Per procedere con il mirroring, riprendere la sessione. Il server principale precedente assume il ruolo di mirror. Il nuovo server mirror elimina il fork di recupero originale, perdendo eventuali transazioni non inviate o ricevute dal server mirror precedente.
Contesti in cui la perdita di dati non è ammissibile

Se il database principale originale contiene dati critici che andrebbero persi in caso di ripresa della sessione, è possibile preservare tali dati sul server principale originale rimuovendo il mirroring. In tal caso è opportuno tentare di eseguire il backup della parte finale del log del server principale in questo punto. Successivamente, è possibile aggiornare il database principale corrente (il precedente database mirror) esportando i dati da salvaguardare dal database principale originale e importandoli nel database principale corrente. È consigliabile eseguire un backup completo del database aggiornato il più rapidamente possibile.

Per riattivare il mirroring utilizzando il database aggiornato quale database principale iniziale, utilizzare questo backup (e almeno un backup del log successivo) per creare un nuovo database mirror. È necessario applicare qualsiasi backup del log eseguito dopo la rimozione del mirroring. È pertanto consigliabile rimandare ulteriori backup del log del database principale fino all'avvio della nuova sessione di mirroring.