Failover manuale

che disconnette i client dal database e inverte i ruoli dei partner. Solo la modalità a sicurezza elevata supporta il failover manuale.

[!NOTA]

In questo argomento si presuppone che l'utente conosca la modalità a sicurezza elevata. Per ulteriori informazioni, vedere Mirroring sincrono del database (modalità a sicurezza elevata).

Mantenimento della disponibilità durante gli aggiornamenti

L'amministratore del database può utilizzare il failover manuale per aggiornare l'hardware o il software senza ridurre la disponibilità. Per eseguire aggiornamenti del software mediante il mirroring del database, è necessario che il server mirror e/o il sistema ricevano precedentemente gli aggiornamenti.

[!NOTA]

Il mirroring del database dovrebbe consentire l'esecuzione di un aggiornamento in sequenza. Questo non è tuttavia garantito poiché le modifiche future non sono ancora note. Per ulteriori informazioni, vedere Procedura: Ridurre al minimo il tempo di inattività per i database con mirroring quando si aggiornano le istanze del server.

Nella figura seguente è illustrato un esempio di utilizzo del failover manuale per mantenere la disponibilità del database mentre si aggiorna un'istanza del server di database. Al termine dell'aggiornamento, un amministratore può eseguire facoltativamente il failover all'istanza del server originale. Questa operazione è utile se l'amministratore desidera interrompere la sessione di mirroring e utilizzare il server mirror in un'altra posizione. In questo modo, è possibile utilizzare ripetutamente una singola istanza del server per aggiornare una serie di istanze del server di database.

Failover manuale pianificato

Condizioni necessarie per un failover manuale

Per il failover manuale, è necessario che il livello di protezione delle transazioni sia impostato su FULL (ovvero in modalità a protezione elevata). Se i partner sono connessi e il database è già sincronizzato, è supportato il failover manuale.

Funzionamento del failover manuale

Il failover manuale inizia la sequenza di azioni seguente:

  1. Il server principale disconnette i client dal database principale, invia la parte finale del log al server mirror e, in vista del passaggio al ruolo di server mirror, imposta lo stato di mirroring su SYNCHRONIZING.

  2. Il server mirror registra il numero di sequenza del file di log (LSN) relativo all'ultimo record del log ricevuto dal server principale come LSN di failover.

    [!NOTA]

    Per visualizzare questo LSN, selezionare la colonna mirroring_failover_lsn da sys.database_mirroring (Transact-SQL).

  3. Se un log è in attesa della coda di rollforward, il server mirror termina il rollforward del database mirror. La quantità di tempo necessaria varia in base alla velocità del sistema, al carico di lavoro recente e alle dimensioni del log nella coda di rollforward. Per la modalità operativa sincrona, è possibile regolare il tempo di failover limitando le dimensioni della coda di rollforward. Tale operazione, tuttavia, può causare un rallentamento del server principale a vantaggio della velocità del server mirror.

    [!NOTA]

    Per visualizzare le dimensioni correnti della coda di rollforward, utilizzare il contatore delle prestazioni Coda di rollforward nell'oggetto prestazioni del mirroring del database. Per ulteriori informazioni, vedere Monitoraggio del mirroring del database.

  4. Il server mirror diventa il nuovo server principale, mentre il server principale precedente diventa il nuovo server mirror.

  5. Il nuovo server principale esegue il rollback delle eventuali transazioni di cui non è stato eseguito il commit e porta in linea la copia interna del database come database principale.

  6. Il server principale precedente assume il ruolo di server mirror e il database principale precedente diventa il database mirror. Il nuovo server mirror risincronizza rapidamente il nuovo database mirror con il nuovo database principale.

    [!NOTA]

    Non appena il nuovo server mirror ha risincronizzato i database, è possibile eseguire di nuovo il failover ma nella direzione inversa.

Dopo il failover, è necessario riconnettere i client al database principale corrente. Per ulteriori informazioni, vedere Connessione di client a un database con mirroring.