Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server)Perform a Forced Manual Failover of an Availability Group (SQL Server)

Questo argomento illustra come eseguire un failover forzato (con possibile perdita di dati) in un gruppo di disponibilità AlwaysOn tramite SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQLo PowerShell in SQL Server 2017SQL Server 2017.This topic describes how to perform a forced failover (with possible data loss) on an Always On availability group by using SQL Server Management StudioSQL Server Management Studio, Transact-SQLTransact-SQL, or PowerShell in SQL Server 2017SQL Server 2017. 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 .A forced failover is a form of manual failover that is intended strictly for disaster recovery, when a planned manual failover is not possible. Se si forza il failover in una replica secondaria non sincronizzata, è possibile che vengano persi alcuni dati.If you force failover to an unsynchronized secondary replica, some data loss is possible. È 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.Therefore, we strongly recommend that you force failover only if you must restore service to the availability group immediately and you are willing to risk losing data.

Dopo un failover forzato, la destinazione a cui è stato eseguito il failover del gruppo di disponibilità diventa la nuova replica primaria.After a forced failover, the failover target to which the availability group was failed over becomes the new primary replica. I database secondari nelle repliche secondarie rimanenti vengono sospesi e dovranno essere ripresi manualmente.The secondary databases in the remaining secondary replicas are suspended and must be manually resumed. 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.When the former primary replica becomes available, it transitions to the secondary role, causing the former primary databases to become secondary databases and transition into the SUSPENDED state. Prima di riprendere uno specifico database secondario, è possibile che si riesca a recuperare i dati perduti.Before you resume a given secondary database, you might be able to recover lost data from it. Si tenga tuttavia presente che il troncamento del log delle transazioni viene ritardato in uno specifico database primario mentre i relativi database secondari sono sospesi.However, notice that transaction log truncation is delayed on a given primary database while any of its secondary databases is suspended.

Importante

La sincronizzazione dei dati con il database primario non verrà eseguita fino a quando non viene ripreso il database secondario.Data synchronization with the primary database will not occur until the secondary database is resumed. Per informazioni sulla ripresa di un database secondario, vedere Completamento: Attività essenziali dopo un failover forzato più avanti in questo articolo.For information about resuming a secondary database, see Follow Up: Essential Tasks After a Forced Failover later in this article.

È necessario eseguire un failover forzato nelle situazioni di emergenza indicate di seguito.Performing a forced failover is necessary in the following emergency situations:

  • Dopo aver forzato il quorum del cluster WSFC (forced quorum), sarà necessario forzare il failover di ogni gruppo di disponibilità (con possibile perdita di dati).After forcing quorum on the WSFC cluster (forced quorum), you need to force failover each availability group (with possible data loss). Il failover forzato è necessario poiché lo stato effettivo dei valori del cluster WSFC potrebbe essere andato perso.Forcing failover is required because the real state of the WSFC cluster values might have been lost. È 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.However, you can avoid data loss, if are able to force failover on the server instance that was hosting the replica that was the primary replica before you forced quorum or to a secondary replica that was synchronized before you forced quorum. Per ulteriori informazioni, vedere Metodi possibili per evitare la perdita di dati dopo aver forzato il quorumpiù avanti in questo argomento.For more information, see Potential Ways to Avoid Data Loss After Quorum is Forced, later in this topic.

    Importante

    Se il quorum viene recuperato naturalmente, senza bisogno di forzarlo, le repliche di disponibilità verranno sottoposte al normale processo di recupero.If quorum is regained by natural means instead of being forced, the availability replicas will go through normal recovery. Se la replica primaria non risulta ancora disponibile dopo aver recuperato il quorum, è possibile eseguire un failover manuale pianificato in una replica secondaria sincronizzata.If the primary replica is still unavailable after quorum is regained, you can perform a planned manual failover to a synchronized secondary replica.

    Per informazioni sulla forzatura del quorum, vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).For information about forcing quorum, see WSFC Disaster Recovery through Forced Quorum (SQL Server). Per informazioni sui motivi per cui il failover forzato è necessario dopo la forzatura del quorum, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For information about why forcing failover is required after forcing quorum, see Failover and Failover Modes (Always On Availability Groups).

  • Se la replica primaria non è più disponibile dopo che il cluster WSFC ha conseguito un quorum integro, è possibile forzare il failover (con possibile perdita di dati) in qualsiasi replica con ruolo in stato SECONDARY o RESOLVING.If the primary replica becomes unavailable when the WSFC cluster has a healthy quorum, you can force failover (with possible data loss), to any replica whose role is in the SECONDARY or RESOLVING state. Se possibile, forzare il failover in una replica secondaria con commit sincrono che era sincronizzata quando la replica primaria è andata persa.If possible, force failover to a synchronous-commit secondary replica that was synchronized when the primary replica was lost.

    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.When the WSFC cluster has a healthy quorum, if you issue a force failover command on a synchronized secondary replica, the replica actually performs a planned manual failover.

Nota

Per altre informazioni sui prerequisiti, consigli per il failover forzato e uno scenario di esempio che usa il failover forzato per il ripristino da un errore irreversibile, vedere Scenario di esempio: Utilizzo di un failover forzato per il ripristino da un errore irreversibile, più avanti in questo argomento.For more information about the prerequisites and recommendations for forcing failover and for an example scenario that uses a forced failover to recover from a catastrophic failure, see Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure, later in this topic.

Prima di iniziare Before You Begin

Limitazioni e restrizioni Limitations and Restrictions

  • 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.The only time that you cannot perform a forced failover is when Windows Server Failover Clustering (WSFC) cluster lacks quorum.

  • È possibile che si verifichi una perdita di dati durante il failover forzato di un gruppo di disponibilità.Data loss is possible during the forced failover of an availability group. Inoltre, se la replica primaria è in esecuzione quando si inizia un failover forzato, è possibile che i client siano ancora connessi ai database primari precedenti.In addition, if the primary replica is running when you initiate a forced failover, clients might still be connected to former primary databases. 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à.Therefore, we strongly recommend that you force failover only if the primary replica is no longer running and if you are willing to risk losing data in order to restore access to databases in the availability group.

  • Quando un database secondario si trova nello stato REVERTING o INITIALIZING, il failover forzato provocherebbe il mancato avvio del database come database primario.When a secondary database in the REVERTING or INITIALIZING state, forcing failover would cause the database to fail to start as a primary database. Se il database era nello stato INITIALIZING, sarà necessario applicare i record del log mancanti da un backup del database o ripristinare completamente il database.If the database was in the INTIAILIZGING state the you will need to apply the missing log records from a database backup or fully restore the database from scratch. Se il database era nello stato REVERTING, sarà necessario ripristinare completamente il database dai backup.If the database was in the REVERTING state you will need to fully restore the database from backups.

  • Un comando di failover viene eseguito non appena la destinazione di failover avrà accettato il comando.A failover command returns as soon as the failover target has accepted the command. Tuttavia, il recupero del database si verifica in modo asincrono dopo che il gruppo di disponibilità ha completato il failover.However, database recovery occurs asynchronously after the availability group has finished failing over.

  • La coerenza tra i database all'interno del gruppo di disponibilità potrebbe non essere mantenuta nel failover.Cross-database consistency across databases within the availability group might not be maintained on failover.

    Nota

    Il supporto delle transazioni distribuite e tra database varia in base alle versioni di SQL Server e del sistema operativo.Support for cross-database and distributed transactions vary by SQL Server and operating system versions. Per altre informazioni, vedere Transazioni tra database non supportate per il mirroring del database o i gruppi di disponibilità AlwaysOn (SQL Server).For more information, see Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server).

Prerequisiti Prerequisites

Indicazioni Recommendations

  • Non forzare il failover mentre la replica primaria è ancora in esecuzione.Do not force failover while the primary replica is still running.

  • Se possibile, forzare il failover solo in una destinazione di failover con database secondari in stato NOT SYNCHRONIZED, SYNCHRONIZED o SYNCHRONIZING.If possible, force failover only to a failover target whose secondary databases are either in the NOT SYNCHRONIZED, SYNCHRONIZED, or SYNCHRONIZING state. Per informazioni sulle implicazioni del failover forzato quando un database secondario è nello stato INITIALIZING o REVERTING, vedere Limitazioni e restrizioni, in precedenza in questo argomento.For information about the implications of forcing failover when a secondary database is in the INTIAILIZGING or REVERTING state, see Limitations and Restrictions, earlier in this topic.

  • In genere la latenza di un determinato database secondario, rispetto al database primario, dovrebbe essere simile nelle diverse repliche secondarie con commit asincrono.Typically, the latency of a given secondary database, relative to the primary database, should be similar on different asynchronous-commit secondary replicas. Tuttavia, in caso di failover forzato, la perdita di dati può costituire un problema significativo.However, when forcing failover, data loss can be a significant concern. È pertanto consigliabile determinare la latenza relativa delle copie dei database nelle diverse repliche secondarie.Therefore, consider taking time to determine the relative latency of the copies of the databases on different secondary replicas. Per determinare quale copia di un database secondario specifico presenta la latenza minima, confrontare i relativi LSN di fine log.To determine which copy of a given secondary database has the least latency, compare their end-of-log LSNs. Un LSN di fine log più elevato indica una minore latenza.A higher the end-of-log LSN indicates less latency.

    Suggerimento

    Per confrontare gli LSN di fine log, connettersi in sequenza a ogni replica secondaria online ed eseguire una query su sys.dm_hadr_database_replica_states per ottenere il valore end_of_log_lsn di ogni database secondario locale.To compare end-of-log LSNs, connect to each online secondary replica, in turn, and query sys.dm_hadr_database_replica_states for the end_of_log_lsn value of each local secondary database. Confrontare quindi gli LSN di fine log delle diverse copie di ogni database.Then, compare the end-of-log LSNs of the different copies of each database. Si noti che database diversi potrebbero presentare i relativi LSN più elevati in repliche secondarie diverse.Note that different databases might have their highest LSNs on different secondary replicas. In tal caso, la destinazione del failover più appropriata dipenderà dall'importanza relativa che si attribuisce ai dati nei diversi database,In this case, the most appropriate failover target depends on the relative importance that you place on the data in the different databases. ovvero per quale di questi database si preferirebbe ridurre al minimo una possibile perdita di dati.That is, for which of these databases would you most want to minimize possible data loss?

  • Se i client sono in grado di connettersi alla replica primaria originale, un failover forzato incorre nel rischio di comportamento split-brain.If clients are able to connect to the original primary, a forced failover incurs some risk of split brain behavior. Prima di forzare il failover, è consigliabile impedire ai client di accedere alla replica primaria originale.Before you force failover, we strongly recommend that you prevent clients from accessing the original primary replica. 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.Otherwise, after failover is forced, the original primary databases and the current primary databases could be updated independently of the other.

Metodi possibili per evitare la perdita di dati dopo aver forzato il quorum Potential Ways to Avoid Data Loss After Quorum is Forced

In alcune condizioni di errore dopo che il quorum è andato perso, è possibile evitare la perdita di dati nei modi indicati di seguito.Under some failure conditions after quorum is lost, you can avoid prevent data loss, as follows:

  • Se la replica primaria originale torna onlineIf the original primary replica comes 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à.If quorum is lost and forcing WSFC quorum restores the cluster node that hosts the primary replica of an availability group, you can prevent data loss for this availability group. Connettersi alla replica primaria ed eseguire un failover forzato (FAILOVER_ALLOW_DATA_LOSS).Connect to the primary replica and perform a forced failover (FAILOVER_ALLOW_DATA_LOSS). In questo modo la replica primaria torna online.This brings the primary replica back online. Non si verifica alcuna perdita di dati, in quanto viene eseguito il failover forzato nella replica primaria originale.Because you perform the forced failover to the original primary replica, there is no data loss.

  • Se una replica secondaria sincronizzata con commit sincrono torna onlineIf a synchronized synchronous-commit secondary replica comes online

    Se il quorum viene perso e la forzatura del quorum WSFC implica il ripristino del nodo del cluster che ospita una replica secondaria sincronizzata di un gruppo di disponibilità, è possibile evitare la perdita di dati per questo gruppo di disponibilità.If quorum is lost and forcing WSFC quorum restores a cluster node that hosts a synchronized secondary replica for an availability group, you should be able to prevent data loss for this availability group. Se il nodo ripristinato era attivo nel momento in cui il quorum è andato perso, è possibile determinare se può verificarsi una 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 .If the restored node was up at the time that quorum was lost, you can determine whether data loss could occur on a given database by querying the is_failover_ready column of the sys.dm_hadr_database_replica_cluster_states dynamic management view. Ad esempio, per un'istanza del server denominata sql108w2k8r22, eseguire la query qui indicata:For example, for a server instance named sql108w2k8r22, issue the following query:

    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 nel momento in cui la replica primaria è passata offline.If the restored node was not up at the time quorum was lost, is_failover_ready may not reflect the cluster's actual state at the time the primary replica went offline. Quindi il valore is_failover_ready è utile solo se il nodo dell'host era attivo nel momento in cui si è verificato l'errore.Therefore, the is_failover_ready value is only good if the host node at the time of the failure. Per altre informazioni, vedere "Motivi per cui è necessario il failover forzato dopo aver forzato il quorum" in Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For more information, see "Why Forced Failover is Required After Forcing Quorum" in Failover and Failover Modes (Always On Availability Groups).

    Se is_failover_ready è uguale a 1, il database viene contrassegnato come sincronizzato nel cluster ed è pronto per il failover.If is_failover_ready = 1, the database is marked as synchronized in the cluster and is ready for a 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.If is_failover_ready = 1 on every database on a given secondary replica, you can perform a forced failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) without data loss on this secondary replica. La replica secondaria sincronizzata torna online nel ruolo primario, ovvero come nuova replica primaria, con tutti i dati intatti.The synchronized secondary replica comes online in the primary role, that is, as the new primary replica, with all the data intact.

    Se is_failover_ready è uguale a 0, il database non viene contrassegnato come sincronizzato nel cluster e non è pronto per un failover manuale pianificato.If is_failover_ready = 0, the database is not marked as synchronized in the cluster and is not ready for a planned manual failover. Se si forza il failover nella replica secondaria host, i dati verranno persi nel database.If you force failover to the host secondary replica, data will be lost on this database.

    Nota

    Se si forza il failover in una replica secondaria, la quantità di dati che andranno perduti dipenderà dal ritardo della destinazione di failover rispetto alla replica primaria.When you force failover to a secondary replica, the amount of data loss will depend on how far the failover target is lagging behind the primary replica. 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.Unfortunately, when the WSFC cluster lacks quorum or quorum has been forced, you cannot assess the amount of potential data loss. 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.Note, however, that once the WSFC cluster regains a healthy quorum, you could begin to track potential data loss. Per altre informazioni, vedere "Come tenere traccia della potenziale perdita di dati" in Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For more information, see "Tracking Potential Data Loss" in Failover and Failover Modes (Always On Availability Groups).

Sicurezza Security

Autorizzazioni Permissions

È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER.Requires ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.

Utilizzo di SQL Server Management Studio Using SQL Server Management Studio

Per forzare il failover (con possibile perdita di dati)To force failover (with possible data loss)

  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 del server.In Object Explorer, connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that needs to be failed over, and expand the server tree.

  2. Espandere il nodo Disponibilità elevata AlwaysOn e il nodo Gruppi di disponibilità .Expand the Always On High Availability node and the Availability Groups node.

  3. Fare clic con il pulsante destro del mouse sul gruppo di disponibilità di cui eseguire il failover e selezionare il comando Failover .Right-click the availability group to be failed over, and select the Failover command.

  4. Verrà avviata la Creazione guidata Gruppo di disponibilità di failover.This launches the Failover Availability Group Wizard. Per ulteriori informazioni, vedere Utilizzare la Procedura guidata Failover del gruppo di disponibilità (SQL Server Management Studio).For more information, see Use the Fail Over Availability Group Wizard (SQL Server Management Studio).

  5. Dopo avere forzato il failover di un gruppo di disponibilità, completare i passaggi necessari.After forcing an availability group to fail over, complete the necessary follow-up steps. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

Utilizzo di Transact-SQL Using Transact-SQL

Per forzare il failover (con possibile perdita di dati)To force failover (with possible data loss)

  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.Connect to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that that needs to be failed over.

  2. Utilizzare l'istruzione ALTER AVAILABILITY GROUP , come indicato di seguito:Use the ALTER AVAILABILITY GROUP statement, as follows:

    ALTER AVAILABILITY GROUP nome_gruppo FORCE_FAILOVER_ALLOW_DATA_LOSSALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

    dove nome_gruppo è il nome del gruppo di disponibilità.where group_name is the name of the availability group.

    Nell'esempio seguente viene eseguito il failover forzato del gruppo di disponibilità AccountsAG alla replica secondaria locale.The following example forces the AccountsAG availability group to fail over to the local secondary replica.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
    
  3. Dopo avere forzato il failover di un gruppo di disponibilità, completare i passaggi necessari.After forcing an availability group to fail over, complete the necessary follow-up steps. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

Utilizzo di PowerShell Using PowerShell

Per forzare il failover (con possibile perdita di dati)To force failover (with possible data loss)

  1. Passare a una directory (cd) dell'istanza del server che ospita una replica con ruolo in stato SECONDARY o RESOLVING nel gruppo di disponibilità di cui è necessario eseguire il failover.Change directory (cd) to a server instance that hosts a replica whose role is in the SECONDARY or RESOLVING state in the availability group that that needs to be failed over.

  2. Usare il cmdlet Switch-SqlAvailabilityGroup con il parametro AllowDataLoss in uno dei formati seguenti:Use the Switch-SqlAvailabilityGroup cmdlet with the AllowDataLoss parameter in one of the following forms:

    • -AllowDataLoss-AllowDataLoss

      Per impostazione predefinita, se viene specificato il parametro -AllowDataLoss il cmdlet Switch-SqlAvailabilityGroup segnala che il failover forzato può comportare la perdita di transazioni di cui non è stato eseguito il commit e richiede la conferma dell'operazione.By default -AllowDataLoss parameter causes Switch-SqlAvailabilityGroup to prompt you to remind you that forcing failover might result in the loss of uncommitted transactions and to request confirmation. Per continuare, immettere Y. Per annullare l'operazione, immettere N.To continue, enter Y; to cancel the operation, enter N.

      Nell'esempio seguente viene eseguito un failover forzato (con possibile perdita di dati) del gruppo di disponibilità MyAg nella replica secondaria nell'istanza del server denominata SecondaryServer\InstanceName.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the secondary replica on the server instance named SecondaryServer\InstanceName. Verrà richiesto di confermare questa operazione.You will be prompted to confirm this operation.

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

      Per avviare un failover forzato senza conferma, specificare entrambi i parametri -AllowDataLoss e -Force .To initiate a forced failover without confirmation, specify both the -AllowDataLoss and -Force parameters. Ciò si rivela utile per includere il comando in uno script ed eseguirlo senza l'interazione dell'utente.This is useful if you want to include the command in a script and run it without user interaction. Usare l'opzione -Force con cautela, dal momento che un failover forzato può causare la perdita di dati dai database che fanno parte del gruppo di disponibilità.However, use the -Force option with caution, because a forced failover might result in the loss of data from databases participating the availability group.

      Nell'esempio seguente viene eseguito il failover forzato (con possibile perdita di dati) del gruppo di disponibilità MyAg nell'istanza del server denominata SecondaryServer\InstanceName.The following example performs a forced failover (with possible data loss) of the availability group MyAg to the server instance named SecondaryServer\InstanceName. L'opzione -Force elimina la richiesta di conferma dell'operazione.The -Force option suppresses confirmation of this operation.

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

    Nota

    Per visualizzare la sintassi di un cmdlet, usare il cmdlet Get-Help nell'ambiente PowerShell di SQL ServerSQL Server .To view the syntax of a cmdlet, use the Get-Help cmdlet in the SQL ServerSQL Server PowerShell environment. Per altre informazioni, vedere Get Help SQL Server PowerShell.For more information, see Get Help SQL Server PowerShell.

  3. Dopo avere forzato il failover di un gruppo di disponibilità, completare i passaggi necessari.After forcing an availability group to fail over, complete the necessary follow-up steps. Per ulteriori informazioni, vedere Completamento: Attività essenziali dopo un failover forzato, più avanti in questo argomento.For more information, see Follow Up: Essential Tasks After a Forced Failover, later in this topic.

    Per impostare e utilizzare il provider PowerShell per SQL ServerTo set up and use the SQL Server PowerShell provider

Completamento: Attività essenziali dopo un failover forzato Follow Up: Essential Tasks After a Forced Failover

  1. Dopo un failover forzato, la replica secondaria a cui è stato eseguito il failover diventa la nuova replica primaria.After a forced failover, the secondary replica to which you failed over becomes the new primary replica. 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:However, to make that availability replica accessible to clients, you might need to reconfigure the WSFC quorum or adjust the availability-mode configuration of the availability group, as follows:

  2. Dopo un failover forzato tutti i database secondari sono sospesi,After a forced failover, all secondary databases are suspended. compresi i database primari precedenti. Ciò avviene dopo che la replica primaria precedente torna online e viene ora individuata come replica secondaria.This includes the former primary databases, after the former primary replica comes back online and discovers that it is now a secondary replica. È necessario riprendere manualmente ogni database sospeso singolarmente in ogni replica secondaria.You must manually resume each suspended database individually on each secondary replica.

    Quando un database secondario viene ripreso, inizia la sincronizzazione dei dati con il database primario corrispondente.When a secondary database is resumed, it initiates data synchronization with the corresponding primary database. Il database secondario esegue il rollback di qualsiasi record di log di cui non è mai stato eseguito il commit sul nuovo database primario.The secondary database rolls back any log records that were never committed on the new primary database. 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.Therefore, if you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one of the synchronous-commit secondary databases.

    Importante

    Il troncamento del log delle transazioni viene ritardato nel database primario, mentre gli eventuali database secondari vengono sospesi.Transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. 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.Also the synchronization health of a synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.

    Per creare uno snapshot del databaseTo create a database snapshot

    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.After resuming all the secondary databases, before attempting to fail over the group again, wait for every secondary database on the next failover target to enter the SYNCHRONIZING state. 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.If any database is not yet SYNCHRONIZING, that database will be prevented from coming online as a primary database, and re-establishing data synchronization for the database might require restoring transaction logs, restoring a full database backup, or failing over back to the previous primary replica.

  3. Se una replica di disponibilità non riuscita non viene restituita alla replica di disponibilità o viene restituita con un ritardo tale che il troncamento del log delle transazioni sul nuovo database primario non può essere ritardato, valutare di rimuovere la replica non riuscita dal gruppo di disponibilità per evitare l'esaurimento dello spazio disponibile sul disco per i file di log.If an availability replica that failed will not be returning to the availability replica or will return too late for you to delay transaction log truncation on the new primary database, consider removing the failed replica from the availability group to avoid running out of disk space for your log files.

    Per rimuovere una replica secondariaTo remove a secondary replica

  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.If you follow a forced failover with one or more additional forced failovers, perform a log backup after each additional forced failover in the series. Per informazioni sul 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).For information about the reason for this, see "Risks of Forcing Failover" in the "Forced Manual Failover (with Possible Data Loss)" section of Failover and Failover Modes (Always On Availability Groups).

    Per eseguire un backup del logTo perform a log backup

Scenario di esempio: Utilizzo di un failover forzato per il ripristino da un errore irreversibile Example Scenario: Using a Forced Failover to Recover from a Catastrophic Failure

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.If the primary replica fails and no synchronized secondary replica is available, forcing the availability group to fail over might be an appropriate response. 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.The appropriateness of forcing a failover depends on: (1) whether you expect the primary replica to be offline for longer than your service level agreement (SLA) tolerates, and (2) whether you are willing to risk potential data loss in order to make primary databases available quickly. 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.If you decide that an availability group requires a forced failover, the actual forced failover is but one step of a multi-step process.

Per illustrare i passaggi necessari per utilizzare un failover forzato per il ripristino da un errore irreversibile, in questo argomento viene presentato un possibile scenario di ripristino di emergenza.To illustrate the steps that are required to use a forced failover to recover from a catastrophic failure, this topic presents one possible disaster recovery scenario. 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.The example scenario considers an availability group whose original topology consists of a main data center that hosts three synchronous-commit availability replicas, including the primary replica, and a remote data center that hosts two asynchronous-commit secondary replicas. Nella figura seguente viene illustrata la topologia originale di questo gruppo di disponibilità di esempio.The following figure illustrates the original topology of this example availability group. Il gruppo di disponibilità è ospitato da un cluster WSFC su più subnet con tre nodi nel data center principale (Nodo 01, Nodo 02e Nodo 03) e due nodi nel data center remoto (Nodo 04 e Nodo 05).The availability group is hosted by a multi-subnet WSFC cluster with three nodes in the main data center (Node 01, Node 02, and Node 03) and two nodes in a remote data center (Node 04 and Node 05).

Topologia originale del gruppo di disponibilitàOriginal topology of availability group

Si verifica un arresto imprevisto del data center principale.The main data center shuts down unexpectedly. Le tre repliche di disponibilità passano alla modalità offline e i relativi database diventano non disponibili.Its three availability replicas to go offline, and their databases become unavailable. Nella figura seguente viene illustrato l'impatto di questo errore sulla topologia del gruppo di disponibilità.The following figure illustrates the impact of this failure on the topology of the availability group.

Topologia dopo l'errore del data center principaleTopology after failure of main data center

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.The database administrator (DBA) determines that the best possible response is to force failover of the availability group to one of the remote, asynchronous-commit secondary replicas. 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à.This example illustrates the typical steps involved when you force failover of the availability group to a remote replica and, eventually, return the availability group to its original topology.

La risposta all'errore presentata in questo esempio è costituita da due fasi:The failure-response presented here consists of the following two phases:

Risposta all'errore irreversibile del data center principale Responding to the Catastrophic Failure of the Main Data Center

Nella figura seguente viene illustrata la serie di azioni eseguite nel data center remoto in risposta a un errore irreversibile nel data center principale.The following figure illustrates the series of actions performed at the remote data center in response a catastrophic failure at the main data center.

Passaggi per la risposta all'errore del data center principaleSteps for responding to failure of main data cente

I passaggi riportati nella figura indicano quanto segue:The steps in this figure indicate the following steps:

PassaggioStep AzioneAction CollegamentiLinks
1.1. Il DBA o l'amministratore di rete si accerta che il cluster WSFC disponga di un quorum integro.The DBA or network administrator ensures that the WSFC cluster has a healthy quorum. In questo esempio il quorum deve essere forzato.In this example, quorum needs to be forced. Modalità quorum WSFC e configurazione del voto (SQL Server)WSFC Quorum Modes and Voting Configuration (SQL Server)

Ripristino di emergenza WSFC tramite quorum forzato (SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)
2.2. Il DBA si connette all'istanza del server con la latenza minima (sul Node 04) ed esegue un failover manuale forzato.The DBA connects to the server instance with the least latency (on Node 04) and performs a forced manual failover. Con il failover forzato questa replica secondaria assume il ruolo primario e i database secondari nella replica secondaria rimanente (sul Node 05) vengono sospesi.The forced failover transitions this secondary replica to the primary role and suspends the secondary databases on the remaining secondary replica (on Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) (query sulla colonna end_of_log_lsn .sys.dm_hadr_database_replica_states (Transact-SQL) (Query the end_of_log_lsn column. Per altre informazioni, vedere Indicazionipiù indietro in questo argomento.For more information, see Recommendations, earlier in this topic.)
3.3. Il DBA riprende manualmente ogni database secondario nella replica secondaria rimanente.The DBA manually resumes each of the secondary databases on the remaining secondary replica. Riprendere un database di disponibilità (SQL Server)Resume an Availability Database (SQL Server)

Ripristino della topologia originale del gruppo di disponibilità Returning the Availability Group to its Original Topology

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.The following figure illustrates the series of actions that return the availability group to its original topology after the main data center comes back online and the WSFC nodes re-establish communication with the WSFC cluster.

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.If the WSFC cluster quorum has been forced, as the offline nodes restart they could form a new quorum if the following conditions both exist: (a) there is no network connectivity between any of the nodes in the forced-quorum set, and (b) the restarting nodes are the majority of the cluster nodes. Questo porterebbe a una condizione "split brain" in cui il gruppo di disponibilità disporrebbe di due repliche primarie indipendenti, una in ogni data center.This would result in a "split brain" condition in which the availability group would possess two independent primary replicas, one at each data center. Prima di forzare il quorum per creare un set di quorum di minoranza, vedere Ripristino di emergenza WSFC tramite quorum forzato (SQL Server).Before forcing quorum to create a minority quorum set, see WSFC Disaster Recovery through Forced Quorum (SQL Server).

Passaggi per il ripristino della topologia originale del gruppoSteps to return the group to its original topology

I passaggi riportati nella figura indicano quanto segue:The steps in this figure indicate the following steps:

PassaggioStep CollegamentiLinks
1.1. I nodi nel data center principale ritornano online e ristabiliscono la comunicazione con il cluster WSFC.The nodes in the main data center come back online and re-establish communication with the WSFC cluster. Le relative repliche di disponibilità vengono riportate online come repliche secondarie con database sospesi e il DBA dovrà presto riprendere manualmente ogni database.Their availability replicas come online as secondary replicas with suspended databases, and the DBA will need to manually resume each of these databases soon. Riprendere un database di disponibilità (SQL Server)Resume an Availability Database (SQL Server)

Suggerimento: per evitare possibili perdite di dati nei database primari dopo il failover, provare a creare uno snapshot del database sui database sospesi in uno dei database secondari con commit sincrono.Tip: If you are concerned about possible data loss on the post-failover primary databases, you should attempt to create a database snapshot on the suspended databases on one the synchronous-commit secondary database. Si tenga presente che il troncamento del log delle transazioni viene ritardato sul database primario mentre i relativi database secondari sono sospesi.Keep in mind that the transaction log truncation is delayed on a primary database while any of its secondary databases is suspended. Inoltre, l'integrità di sincronizzazione della replica secondaria con commit sincrono non potrà passare allo stato HEALTHY finché un database locale qualsiasi rimane sospeso.Also the synchronization health of the synchronous-commit secondary replica cannot transition to HEALTHY as long as any local database remains suspended.
2.2. Una volta ripresi i database, il DBA modifica la nuova replica primaria impostandola temporaneamente sulla modalità commit sincrono.Once the databases are resumed, the DBA changes the new primary replica to synchronous-commit mode temporarily. Questa operazione comporta due passaggi:This involves two steps:

1) Modificare una replica di disponibilità offline impostandola sulla modalità commit asincrono.1) Change one offline availability replica to asynchronous-commit mode.

2) Modificare la nuova replica primaria impostandola sulla modalità commit sincrono.2) Change the new primary replica to synchronous-commit mode. Nota: questo passaggio consente ai database secondari con commit sincrono ripresi di passare allo stato SYNCHRONIZED.Note: This step enables resumed synchronous-commit secondary databases to become SYNCHRONIZED.
Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)
3.3. Dopo che la replica secondaria con commit sincrono nel Node 03 (la replica primaria originale) è passata allo stato di sincronizzazione HEALTHY, il DBA esegue un failover manuale pianificato su tale replica, perché diventi di nuovo replica primaria.Once the synchronous-commit secondary replica on Node 03 (the original primary replica) enters the HEALTHY synchronization state, the DBA performs a planned manual failover to that replica, to make it the primary replica again. La replica nel Nodo 04 tornerà a essere una replica secondaria.The replica on Node 04 returns to being a secondary replica. sys.dm_hadr_database_replica_states (Transact-SQL)sys.dm_hadr_database_replica_states (Transact-SQL)

Utilizzare i criteri AlwaysOn per visualizzare l'integrità di un gruppo di disponibilità (SQL Server)Use Always On Policies to View the Health of an Availability Group (SQL Server)

Eseguire un failover manuale pianificato di un gruppo di disponibilità (SQL Server)Perform a Planned Manual Failover of an Availability Group (SQL Server)
4.4. Il DBA si connette alla nuova replica primaria ed effettua le seguenti operazioni:The DBA connects to the new primary replica and:

1) Modifica la replica primaria precedente nel data center remoto riportandola in modalità commit asincrono.1) Changes the former primary replica (in the remote center) back to asynchronous-commit mode.

2) Modifica la replica secondaria con commit asincrono nel data center principale riportandola in modalità commit sincrono.2) Changes the asynchronous-commit secondary replica in the main data center back to synchronous-commit mode.
Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server)Change the Availability Mode of an Availability Replica (SQL Server)

Per modificare i voti del quorumTo adjust quorum votes

Vedere ancheSee Also

Panoramica di gruppi di disponibilità AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Modalità di disponibilità (gruppi di disponibilità AlwaysOn) Availability Modes (Always On Availability Groups)
Failover e modalità di failover (gruppi di disponibilità AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Informazioni sull'accesso alla connessione client per le repliche di disponibilità (SQL Server) About Client Connection Access to Availability Replicas (SQL Server)
Monitoraggio di Gruppi di disponibilità (SQL Server) Monitoring of Availability Groups (SQL Server)
Windows Server Failover Clustering (WSFC) con SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server