Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server)

In questo argomento viene illustrato come eseguire un failover forzato (con possibile perdita di dati) in un gruppo di disponibilità AlwaysOn tramite SQL Server Management Studio, Transact-SQL o PowerShell in SQL Server 2012. Un failover forzato rappresenta un tipo di failover manuale che deve essere utilizzato esclusivamente per il ripristino di emergenza, se non è possibile eseguire un failover manuale pianificato. Se si forza il failover in una replica secondaria non sincronizzata, è possibile che vengano persi alcuni dati. È pertanto consigliabile forzare il failover solo se è necessario ripristinare immediatamente il servizio nel gruppo di disponibilità e si è disposti a rischiare la perdita di dati.

Dopo un failover forzato, la destinazione a cui è stato eseguito il failover del gruppo di disponibilità diventa la nuova replica primaria. I database secondari nelle repliche secondarie rimanenti vengono sospesi e dovranno essere ripresi manualmente. Quando la replica primaria precedente diventa disponibile, passa al ruolo secondario. In questo modo i database primari precedenti diventano database secondari e passano allo stato SUSPENDED. Prima di riprendere uno specifico database secondario, è possibile recuperare i dati perduti. Si tenga tuttavia presente che il troncamento del log delle transazioni viene ritardato in uno specifico database primario, mentre gli eventuali database secondari vengono sospesi.

Importante
La sincronizzazione dei dati con il database primario non viene eseguita fino a quando non viene ripreso il database secondario. Per informazioni sulla ripresa di un database secondario, vedere Attività essenziali dopo un failover forzato più avanti in questo articolo.

È necessario eseguire un failover forzato nelle situazioni di emergenza indicate di seguito.

• Dopo aver forzato il quorum del cluster WSFC (quorum forzato), sarà necessario forzare il failover di ogni gruppo di disponibilità (con possibile perdita di dati). Il failover forzato è necessario poiché lo stato effettivo dei valori del cluster WSFC potrebbe essere andato perso. È tuttavia possibile evitare la perdita di dati, se si riesce a forzare il failover nell'istanza del server che ospitava la replica primaria prima di forzare il quorum o in una replica secondaria sincronizzata prima di forzare il quorum. Per ulteriori informazioni, vedere Metodi possibili per evitare la perdita di dati dopo aver forzato il quorum più avanti in questo argomento.

  Importante
  Se il quorum viene recuperato naturalmente, senza bisogno di forzarlo, le repliche di disponibilità verranno sottoposte al normale processo di recupero. Se la replica primaria non sarà comunque disponibile dopo aver recuperato il quorum, è possibile eseguire un failover manuale pianificato in una replica secondaria sincronizzata.

  Per informazioni su come forzare il quorum, vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server). Per informazioni sui motivi per cui è necessario il failover forzato dopo aver forzato il quorum, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

• Se la replica primaria non sarà più disponibile dopo che il cluster WSFC avrà conseguito un quorum integro, è possibile forzare il failover (con possibile perdita di dati) in qualsiasi replica con ruolo in stato SECONDARY o RESOLVING. Se possibile, forzare il failover in una replica secondaria con commit sincrono sincronizzata quando la replica primaria è andata persa.

  Suggerimento
  Quando il cluster WSFC consegue un quorum integro, se si esegue un comando di failover forzato in una replica secondaria sincronizzata, la replica eseguirà in realtà un failover manuale pianificato.

[!NOTA]

Per ulteriori informazioni sui prerequisiti e alcuni consigli per forzare il failover oppure per consultare uno scenario di esempio in cui viene utilizzato un failover forzato per eseguire il recupero da un errore irreversibile, vedere Scenario di esempio: Utilizzo di un failover forzato per eseguire il recupero da un errore irreversibile più avanti in questo argomento.

• Prima di iniziare:  

  Limitazioni e restrizioni

  Prerequisiti

  Indicazioni

  Metodi possibili per evitare la perdita di dati dopo aver forzato il quorum

  Sicurezza

• Per forzare il failover (con possibile perdita di dati) tramite:  

  SQL Server Management Studio

  Transact-SQL

  PowerShell

• Completamento:  Attività essenziali dopo un failover forzato

• Scenario di esempio:  Utilizzo di un failover forzato per il recupero da un errore irreversibile

• Attività correlate

• Contenuto correlato

Prima di iniziare

Limitazioni e restrizioni

• L'unico caso in cui non è possibile eseguire un failover forzato si verifica quando il cluster WSFC (Windows Server Failover Clustering) non dispone del quorum.

• È possibile che si verifichi una perdita di dati durante il failover forzato di un gruppo di disponibilità. Inoltre, se la replica primaria è in esecuzione quando si inizia un failover forzato, è possibile che i client siano ancora connessi ai database primari precedenti. Pertanto, è consigliabile forzare il failover solo se la replica primaria non è più in esecuzione e si è disposti a rischiare la perdita di dati per ripristinare l'accesso ai database nel gruppo di disponibilità.

• Quando un database secondario si trova nello stato REVERTING o INITIALIZING, il failover forzato non consente l'avvio del database come database primario. Se il database è nello stato INTIAILIZGING, sarà necessario applicare i record del log mancanti da un backup del database o ripristinare completamente il database da zero. Se il database era nello stato REVERTING, sarà necessario ripristinare completamente il database dai backup.

• Un comando di failover viene eseguito non appena la destinazione di failover avrà accettato il comando. Tuttavia, il recupero del database si verifica in modo asincrono dopo che il gruppo di disponibilità ha completato il failover.

• La coerenza tra i database all'interno del gruppo di disponibilità non viene mantenuta nel failover.

  [!NOTA]

  Le transazioni tra database e quelle distribuite non sono supportate da Gruppi di disponibilità AlwaysOn. Per ulteriori informazioni, vedere Transazioni tra database non supportate per il mirroring del database o i gruppi di disponibilità AlwaysOn (SQL Server).

Prerequisiti

• Il cluster WSFC dispone del quorum. Se il cluster non dispone del quorum, vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).

• È necessario connettersi a un'istanza del server che ospita una replica con ruolo in stato SECONDARY o RESOLVING.

Indicazioni

• Non forzare il failover mentre la replica primaria è ancora in esecuzione.

• Se possibile, forzare il failover solo in una destinazione di failover con database secondari in stato NOT SYNCHRONIZED, SYNCHRONIZED o SYNCHRONIZING. Per informazioni sulle implicazioni del failover forzato quando un database secondario è nello stato INTIAILIZGING o REVERTING, vedere Limitazioni e restrizioni, più indietro in questo argomento.

• In genere la latenza di un determinato database secondario, rispetto al database primario, dovrebbe essere simile nelle diverse repliche secondarie con commit asincrono. Tuttavia, in caso di failover forzato, la perdita di dati può costituire un problema significativo. È pertanto consigliabile determinare la latenza relativa delle copie dei database nelle diverse repliche secondarie. Per determinare quale copia di un database secondario specifico presenta la latenza minima, confrontare i relativi LSN di fine log. Un LSN di fine log più elevato indica una minore latenza.

  Suggerimento

  Per confrontare gli LSN di fine log, connettersi in sequenza a ogni replica secondaria online ed eseguire una query tramite sys.dm_hadr_database_replica_states per la ricerca del valore end_of_log_lsn di ogni database secondario. Confrontare quindi gli LSN di fine log delle diverse copie di ogni database. Si noti che diversi database potrebbero presentare i relativi LSN più elevati in diverse repliche secondarie. In tal caso, la destinazione del failover più appropriata dipenderà dall'importanza relativa che si attribuisce ai dati nei diversi database, ovvero per quale di questi database si preferirebbe ridurre al minimo una possibile perdita di dati.

• Se i client sono in grado di connettersi alla replica primaria originale, un failover forzato incorre nel rischio di "split-brain" del comportamento. Prima di forzare il failover, è consigliabile impedire ai client di accedere alla replica primaria originale. In caso contrario, dopo il failover forzato, i database primari originali e i database primari correnti possono essere aggiornati in modo indipendente gli uni dagli altri.

Metodi possibili per evitare la perdita di dati dopo aver forzato il quorum

In alcune condizioni di errore dopo che il quorum è andato perso, è possibile evitare la perdita di dati nei modi indicati di seguito.

• Se la replica primaria originale torna online

  Se il quorum viene perso e la forzatura del quorum WSFC implica il ripristino del nodo del cluster che ospita la replica primaria di un gruppo di disponibilità, è possibile evitare la perdita di dati per questo gruppo di disponibilità. Connettersi alla replica primaria ed eseguire un failover forzato (FAILOVER_ALLOW_DATA_LOSS). In questo modo la replica primaria torna online. Non si verifica alcuna perdita di dati, in quanto viene eseguito il failover forzato nella replica primaria originale.

• Se una replica secondaria sincronizzata con commit sincrono torna online

  Se il quorum viene perso e la forzatura del quorum WSFC implica il ripristino del nodo del cluster che ospita una replica secondaria di un gruppo di disponibilità, è possibile evitare la perdita di dati per questo gruppo di disponibilità. Se il nodo ripristinato era attivo nel momento in cui il quorum è andato perso, è possibile determinare se si potrebbe verificare la perdita di dati in un database specifico eseguendo una query sulla colonna is_failover_ready della vista a gestione dinamica (DMV) sys.dm_hadr_database_replica_cluster_states. Ad esempio, per un'istanza denominata sql108w2k8r22, eseguire la query seguente:

  SELECT * FROM sys.dm_hadr_database_replica_cluster_states
     WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas 
        WHERE replica_server_name ='sql108w2k8r22')
  

  Attenzione

  Se il nodo ripristinato non era attivo nel momento in cui il quorum è andato perso, is_failover_ready potrebbe non riflettere l'effettivo stato del cluster quando la replica primaria è passata offline. Pertanto, il valore is_failover_ready è utile solo se il nodo dell'host era attivo nel momento in cui si è verificato l'errore. Per ulteriori informazioni, vedere "Motivi per cui è necessario il failover forzato dopo aver forzato il quorum" in Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

  Se is_failover_ready è uguale a 1, il database viene contrassegnato come sincronizzato nel cluster ed è pronto per il failover. Se is_failover_ready è uguale a 1 in ogni database di una determinata replica secondaria, è possibile eseguire un failover forzato (FORCE_FAILOVER_ALLOW_DATA_LOSS) senza perdita di dati nella replica secondaria. La replica secondaria sincronizzata torna online nel ruolo primario, ovvero come nuova replica primaria, con tutti i dati intatti.

  Se is_failover_ready è uguale a 0, il database non viene contrassegnato come sincronizzato nel cluster e non è pronto per un failover manuale pianificato. Se si forza il failover nella replica secondaria host, i dati verranno persi nel database.

  [!NOTA]

  Se si forza il failover in una replica secondaria, la quantità di dati che andranno perduti dipenderà dalla distanza della destinazione di failover rispetto alla replica primaria. Purtroppo, quando il cluster WSFC non dispone del quorum o il quorum è stato forzato, non è possibile valutare la quantità di dati che potrebbero andare perduti. Si noti, tuttavia, che una volta che il cluster WSFC avrà recuperato un quorum integro, sarà possibile iniziare a tenere traccia della potenziale perdita di dati. Per ulteriori informazioni, vedere "Come tenere traccia della potenziale perdita di dati" in Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

Sicurezza

Autorizzazioni

È richiesta l'autorizzazione ALTER AVAILABILITY GROUP per il gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER.

[Torna all'inizio]

Utilizzo di SQL Server Management Studio

Per forzare il failover (con possibile perdita di dati)

1. In Esplora oggetti connettersi a un'istanza del server che ospita una replica con stato SECONDARY o RESOLVING nel gruppo di disponibilità di cui è necessario eseguire il failover ed espandere l'albero di server.

2. Espandere il nodo Disponibilità elevata AlwaysOn e il nodo Gruppi di disponibilità.

3. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità di cui eseguire il failover e selezionare il comando Failover.

4. Verrà avviata la Creazione guidata Gruppo di disponibilità di failover. Per ulteriori informazioni, vedere Utilizzare la Procedura guidata Failover del gruppo di disponibilità (SQL Server Management Studio).

5. Dopo avere forzato il failover di un gruppo di disponibilità, completare i necessari passaggi di completamento. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.

[Inizio pagina]

Utilizzo di Transact-SQL

Per forzare il failover (con possibile perdita di dati)

1. Connettersi a un'istanza del server che ospita una replica con ruolo in stato SECONDARY o RESOLVING nel gruppo di disponibilità di cui è necessario eseguire il failover.

2. Utilizzare l'istruzione ALTER AVAILABILITY GROUP, come indicato di seguito:

   'ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   dove group_name è il nome del gruppo di disponibilità.

   Nell'esempio seguente viene eseguito il failover forzato del gruppo di disponibilità AccountsAG alla replica secondaria locale.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Dopo avere forzato il failover di un gruppo di disponibilità, completare i necessari passaggi di completamento. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.

[Inizio pagina]

Utilizzo di PowerShell

Per forzare il failover (con possibile perdita di dati)

1. Modificare la directory (cd) in un'istanza del server che ospita una replica con ruolo in stato SECONDARY o RESOLVING nel gruppo di disponibilità di cui è necessario eseguire il failover.

2. Utilizzare il cmdlet Switch-SqlAvailabilityGroup con il parametro AllowDataLoss in uno dei formati seguenti:

   • -AllowDataLoss

     Per impostazione predefinita, con il parametro -AllowDataLoss tramite Switch-SqlAvailabilityGroup viene segnalato che il failover forzato può comportare la perdita di transazioni di cui non è stato eseguito il commit e viene richiesta la conferma. Per continuare, immettere Y; per annullare l'operazione, immettere N.

     Nell'esempio seguente viene eseguito un failover forzato (con possibile perdita di dati) del gruppo di disponibilità MyAg alla replica secondaria nell'istanza del server denominata SecondaryServer\InstanceName. Verrà richiesto di confermare questa operazione.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss -Force

     Per iniziare un failover forzato senza conferma, specificare i parametri -AllowDataLoss e -Force. Ciò si rivela utile per includere il comando in uno script ed eseguirlo senza l'interazione dell'utente. Utilizzare tuttavia l'opzione -Force con cautela, perché un failover forzato può causare la perdita di dati dai database che fanno parte del gruppo di disponibilità.

     Nell'esempio seguente viene eseguito un failover forzato (con possibile perdita di dati) del gruppo di disponibilità MyAg all'istanza del server denominata SecondaryServer\InstanceName. Con l'opzione -Force viene eliminata la conferma di questa operazione.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   [!NOTA]

   Per visualizzare la sintassi di un cmdlet, utilizzare il cmdlet Get-Help nell'ambiente PowerShell di SQL Server. Per ulteriori informazioni, vedere Visualizzazione della Guida di SQL Server PowerShell.

3. Dopo avere forzato il failover di un gruppo di disponibilità, completare i necessari passaggi di completamento. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.

Per impostare e utilizzare il provider PowerShell per SQL Server

• Provider PowerShell per SQL Server

[Inizio pagina]

Completamento: Attività essenziali dopo un failover forzato

1. Dopo un failover forzato, la replica secondaria a cui è stato eseguito il failover diventa la nuova replica primaria. Tuttavia, per rendere accessibile ai client tale replica di disponibilità, potrebbe essere necessario riconfigurare il quorum WSFC o modificare la configurazione della modalità di disponibilità del gruppo di disponibilità, nel modo seguente:

   • Se è stato eseguito il failover al di fuori del failover automatico impostato: modificare i voti quorum dei nodi WSFC per riflettere la nuova configurazione del gruppo di disponibilità. Se il nodo WSFC che ospita la replica secondaria di destinazione non dispone di un voto quorum WSFC, potrebbe essere necessario forzare il quorum WSFC.

     [!NOTA]

     Un failover automatico impostato è disponibile solo se due repliche di disponibilità (inclusa la replica primaria precedente) è configurata per la modalità commit sincrono con failover automatico.

     Per modificare i voti quorum

     • Visualizzare le impostazioni NodeWeight per il quorum del cluster

     • Configurare le impostazioni NodeWeight per il quorum del cluster

     • Forzare l'avvio di un cluster WSFC senza un quorum

   • Se è stato eseguito il failover al di fuori del failover con commit sincrono impostato: si consiglia di modificare la modalità di disponibilità e failover sulla nuova replica primaria e sulle repliche secondarie rimanenti per riflettere la configurazione desiderata del failover con commit sincrono e automatico.

     [!NOTA]

     Un failover con commit sincrono impostato esiste solo se la replica primaria corrente viene configurata per la modalità con commit sincrono.

     Per modificare la modalità di disponibilità e failover

     • Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server)

     • Modificare la modalità di failover di una replica di disponibilità (SQL Server)

2. Dopo un failover forzato tutti i database secondari sono sospesi, compresi i database primari precedenti. Ciò avviene dopo che la replica primaria precedente torna online e viene ora individuata come replica secondaria. È necessario riprendere manualmente ogni database sospeso singolarmente in ogni replica secondaria.

   Quando un database secondario viene ripreso, inizia la sincronizzazione dei dati con il database primario corrispondente. Il database secondario esegue il rollback di qualsiasi record di log di cui non è mai stato eseguito il commit sul nuovo database primario. Se pertanto si desidera evitare possibili perdite di dati nei database primari dopo il failover, è consigliabile tentare di creare uno snapshot di database nei database sospesi in uno dei database secondari con commit sincrono.

   Importante
   Il troncamento del log delle transazioni viene ritardato nel database primario, mentre gli eventuali database secondari vengono sospesi. Inoltre, l'integrità di sincronizzazione di una replica secondaria con commit sincrono non potrà passare allo stato HEALTHY finché un database locale qualsiasi rimane sospeso.

   Per creare uno snapshot del database

   • Creare uno snapshot del database (Transact-SQL)

   Per riprendere un database di disponibilità

   • Riprendere un database di disponibilità (SQL Server)

   Attenzione

   Dopo la ripresa di tutti i database secondari, prima di tentare nuovamente il failover del gruppo, attendere che ogni database secondario nella destinazione del failover successivo entri nello stato SYNCHRONIZING. Se un database non è ancora nello stato SYNCHRONIZING, non potrà essere portato online come database primario e ristabilire la sincronizzazione dei dati per il database potrebbe richiedere il ripristino dei log delle transazioni, il ripristino di un backup di database completo o il failover alla replica primaria precedente.

3. Se una replica di disponibilità non riuscita non viene restituita alla replica di disponibilità o viene restituita con un ritardo tale da non consentire di ritardare il troncamento del log delle transazioni sul nuovo database primario, è opportuno considerare di rimuovere la replica non riuscita dal gruppo di disponibilità per evitare di incorrere nell'esaurimento dello spazio disponibile sul disco per i file di log.

   Per rimuovere una replica secondaria

   • Rimuovere una replica secondaria da un gruppo di disponibilità (SQL Server)

4. Se si segue un failover forzato con uno o più failover forzati aggiuntivi, eseguire un backup del log dopo ogni failover forzato aggiuntivo nella serie. Per informazioni sul relativo motivo, vedere "Rischi correlati al failover forzato" nella sezione "Failover manuale forzato (con possibile perdita di dati)" di Failover e modalità di failover (gruppi di disponibilità AlwaysOn).

   Per eseguire un backup del log

   • Backup di un log delle transazioni (SQL Server)

[Inizio pagina]

Scenario di esempio: Utilizzo di un failover forzato per il recupero da un errore irreversibile

In caso di errore della replica primaria e qualora non sia disponibile una replica secondaria sincronizzata, il failover forzato del gruppo di disponibilità potrebbe costituire una risposta appropriata. Un failover forzato può risultare appropriato: (1) se si prevede che la replica primaria rimanga offline più a lungo di quanto sia consentito dal contratto di servizio (SLA, Service Level Agreement) e (2) se si è disposti a rischiare una possibile perdita di dati per rendere rapidamente disponibili i database primari. Se si stabilisce che un gruppo di disponibilità richiede un failover forzato, l'effettivo failover forzato sarà solo uno dei passaggi di un processo che comprende diversi passaggi.

Per illustrare i passaggi necessari per utilizzare un failover forzato per il recupero da un errore irreversibile, in questo argomento viene presentato un possibile scenario di ripristino di emergenza. Nello scenario di esempio si considera un gruppo di disponibilità la cui topologia originale consiste in un data center principale che ospita tre repliche di disponibilità con commit sincrono, inclusa la replica primaria, e un data center remoto che ospita due repliche secondarie con commit asincrono. Nella figura seguente viene illustrata la topologia originale di questo gruppo di disponibilità di esempio. Il gruppo di disponibilità è ospitato da un cluster WSFC su più subnet con tre nodi nel data center principale (Nodo 01, Nodo 02 e Nodo 03) e due nodi nel data center remoto (Nodo 04 e Nodo 05).

Si verifica un arresto imprevisto del data center principale. Le tre repliche di disponibilità passano alla modalità offline e i relativi database diventano non disponibili. Nella figura seguente viene illustrato l'impatto di questo errore sulla topologia del gruppo di disponibilità.

L'amministratore del database (DBA) determina che la migliore risposta possibile consiste nel forzare il failover del gruppo di disponibilità su una delle repliche secondarie remote con commit asincrono. In questo esempio viene illustrata la procedura tipica eseguita per forzare il failover del gruppo di disponibilità su una replica remota e per ripristinare infine la topologia originale del gruppo di disponibilità.

La risposta all'errore presentata in questo esempio è costituita da due fasi:

• Risposta all'errore irreversibile del data center principale

• Ripristino della topologia originale del gruppo di disponibilità

Risposta all'errore irreversibile del data center principale

Nella figura seguente viene illustrata la serie di azioni eseguite nel data center remoto in risposta a un errore irreversibile nel data center principale.

I passaggi riportati nella figura indicano quanto segue:

[Inizio pagina]

Ripristino della topologia originale del gruppo di disponibilità

Nella figura seguente viene illustrata la serie di azioni eseguite per ripristinare la topologia originale del gruppo di disponibilità dopo che il data center principale sarà ritornato online e che sarà stata ristabilita la comunicazione dei nodi WSFC con il cluster WSFC.

Importante

Se il quorum del cluster WSFC è stato forzato, al riavvio dei nodi offline potrebbe essere formato un nuovo quorum in presenza di entrambe le seguenti condizioni: (a) tra i nodi del quorum forzato non è disponibile connettività di rete e (b) i nodi riavviati sono la maggioranza dei nodi del cluster. Questo porterebbe a una condizione "split brain" in cui il gruppo di disponibilità disporrebbe di due repliche primarie indipendenti, una in ogni data center. Prima di forzare il quorum per la creazione di un quorum di minoranza, vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).

I passaggi riportati nella figura indicano quanto segue:

	Passaggio	Collegamenti
1.	I nodi nel data center principale ritornano online e ristabiliscono la comunicazione con il cluster WSFC. Le relative repliche di disponibilità vengono riportate online come repliche secondarie con database sospesi e il DBA dovrà presto riprendere manualmente ogni database.	Riprendere un database di disponibilità (SQL Server) Suggerimento Se si desidera evitare possibili perdite di dati nei database primari dopo il failover, è consigliabile tentare di creare uno snapshot di database sui database sospesi in uno dei database secondari con commit sincrono. Si tenga presente che il troncamento del log delle transazioni viene ritardato sul database primario, mentre gli eventuali database secondari vengono sospesi. Inoltre, l'integrità di sincronizzazione della replica secondaria con commit sincrono non potrà passare allo stato HEALTHY finché un database locale qualsiasi rimane sospeso.
2.	Una volta ripresi i database, il DBA modifica la nuova replica primaria impostandola temporaneamente sulla modalità con commit sincrono. Questa operazione comporta due passaggi: Modificare una replica di disponibilità offline impostandola sulla modalità con commit asincrono. Modificare la nuova replica primaria impostandola sulla modalità con commit sincrono. [!NOTA] Questo passaggio consente ai database secondari con commit sincrono ripresi di passare allo stato SYNCHRONIZED.	Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server)
3.	Una volta che la replica secondaria con commit sincrono nel Nodo 03 (la replica primaria originale) passa allo stato di sincronizzazione HEALTHY, il DBA esegue un failover manuale pianificato su tale replica, affinché diventi di nuovo la replica primaria. La replica in Nodo 04 tornerà a essere una replica secondaria.	sys.dm_hadr_database_replica_states (Transact-SQL) Utilizzare i criteri AlwaysOn per visualizzare l'integrità di un gruppo di disponibilità (SQL Server) Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)
4.	Il DBA si connette alla nuova replica primaria ed effettua le seguenti operazioni: Modifica la replica primaria precedente, nel data center remoto, riportandola in modalità commit asincrono. Modifica la replica secondaria con commit asincrono nel data center principale riportandola in modalità commit sincrono.	Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server)

[Inizio pagina]

Attività correlate

Per modificare i voti quorum

• Visualizzare le impostazioni NodeWeight per il quorum del cluster

• Configurare le impostazioni NodeWeight per il quorum del cluster

• Forzare l'avvio di un cluster WSFC senza un quorum

Failover manuale pianificato:

• Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)

• Utilizzare la Procedura guidata Failover del gruppo di disponibilità (SQL Server Management Studio)

Per risolvere i problemi:

• Risolvere i problemi relativi alla configurazione di Gruppi di disponibilità AlwaysOn (SQL Server)

• Risolvere i problemi relativi a una operazione di aggiunta file non riuscita (Gruppi di disponibilità AlwaysOn)

[Inizio pagina]

Contenuto correlato

• **Blog: **

  Pagina relativa ai blog del team di SQL Server AlwaysOn in cui è disponibile il blog del team ufficiale di SQL Server AlwaysOn

  Pagina relativa ai blog del Servizio Supporto Tecnico Clienti per gli ingegneri di SQL Server

• **White paper: **

  Pagina relativa alla guida alle soluzioni AlwaysOn di Microsoft SQL Server per la disponibilità elevata e il ripristino di emergenza

  Pagina relativa ai white paper Microsoft per SQL Server 2012

  Pagina relativa ai white paper del team di consulenza clienti di SQL Server

[Torna all'inizio]

Vedere anche

Concetti

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)

Modalità di disponibilità (gruppi di disponibilità AlwaysOn)

Failover e modalità di failover (gruppi di disponibilità AlwaysOn)

Informazioni sull'accesso alla connessione client per le repliche di disponibilità (SQL Server)

Monitoraggio di Gruppi di disponibilità (SQL Server)

WSFC (Windows Server Failover Clustering) con SQL Server