Failover e modalità di failover (gruppi di disponibilità AlwaysOn)Failover and Failover Modes (Always On Availability Groups)

In questo argomento si applica a: SìSQL ServernonDatabase SQL di AzurenonAzure SQL Data Warehouse non Parallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Nel contesto di un gruppo di disponibilità, il ruolo primario e il ruolo secondario delle repliche di disponibilità sono generalmente intercambiabili in un processo noto come failover.Within the context of an availability group, the primary role and secondary role of availability replicas are typically interchangeable in a process known as failover. Sono disponibili tre tipi di failover: failover automatico (senza perdita di dati), failover manuale pianificato (senza perdita di dati) e failover manuale forzato (con possibile perdita di dati), in genere chiamato failover forzato.Three forms of failover exist: automatic failover (without data loss), planned manual failover (without data loss), and forced manual failover (with possible data loss), typically called forced failover. Con il failover automatico e il failover manuale pianificato vengono conservati tutti i dati.Automatic and planned manual failover preserve all your data. Per un gruppo di disponibilità il failover si verifica a livello di replica di disponibilità.An availability group fails over at the availability-replica level. In pratica, il failover di un gruppo di disponibilità viene eseguito in una delle relative repliche secondarie, la destinazione di failovercorrente.That is, an availability group fails over to one of its secondary replicas (the current failover target).

Nota

Gli errori a livello di database, ad esempio un database ritenuto sospetto in seguito alla perdita di un file di dati, all'eliminazione di un database o al danneggiamento di un log delle transazioni, non causano il failover di un gruppo di disponibilità.Issues at the database level, such as a database becoming suspect due to the loss of a data file, deletion of a database, or corruption of a transaction log, do not cause an availability group to failover.

Durante il failover, la destinazione del failover subentra al ruolo primario, recupera i database e li porta online come nuovi database primari.During the failover, the failover target takes over the primary role, recovers its databases, and brings them online as the new primary databases. La replica primaria precedente, se disponibile, assume il ruolo secondario e i relativi database diventano database secondari.The former primary replica, when available, switches to the secondary role, and its databases become secondary databases. Potenzialmente, questi ruoli possono essere scambiati vicendevolmente o destinati a una destinazione del failover differente, in seguito a più errori o per scopi amministrativi.Potentially, these roles can switch back and forth (or to a different failover target) in response to multiple failures or for administrative purposes.

Le forme di failover supportate da una replica di disponibilità sono specificate dalla proprietà della modalità di failover .The form(s) of failover that a given availability replica supports is specified by the failover mode property. Per una replica di disponibilità specificata le modalità di failover possibili dipendono dalla modalità di disponibilità della replica, come segue:For a given availability replica, the possible failover modes depends on the availability mode of the replica, as follows:

  • Lerepliche con commit sincrono supportano due impostazioni: automatica e manuale.Synchronous-commit replicas support two settings—automatic or manual. L'impostazione automatica supporta sia il failover automatico sia quello manuale.The "automatic" setting supports both automatic failover and manual failover. Per impedire la perdita di dati, il failover automatico e il failover pianificato richiedono che la destinazione del failover sia una replica secondaria con commit sincrono con uno stato di sincronizzazione integro ad indicare che ogni database secondario sulla destinazione del failover è sincronizzato con il database primario corrispondente.To prevent data loss, automatic failover and planned failover require that the failover target be a synchronous-commit secondary replica with a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database). Quando una replica secondaria non soddisfa entrambe queste condizioni, supporta solo il failover forzato.Whenever a secondary replica does not meet both of these conditions, it supports only forced failover. Si noti che il failover forzato è anche supportato da una replica il cui ruolo si trova nello stato RESOLVING.Note that forced failover is also supported a replicas whose role is in the RESOLVING state.

  • Lerepliche con commit asincrono supportano solo la modalità di failover manuale.Asynchronous-commit replicas support only the manual failover mode. Inoltre, poiché non sono mai sincronizzate, supportano solo il failover forzato.Moreover, because they are never synchronized, they support only forced failover.

Nota

Dopo un failover, le applicazioni client che devono accedere ai database primari devono connettersi alla nuova replica primaria.After a failover, client applications that need to access the primary databases must connect to the new primary replica. Inoltre, se la nuova replica secondaria è configurata per consentire l'accesso in sola lettura, le applicazioni client in sola lettura possono connettersi ad essa.Also, if the new secondary replica is configured to allow read-only access, read-only client applications can connect to it. Per informazioni sulla connessione dei client a un gruppo di disponibilità, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).For information about how clients connect to an availability group, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Sezioni dell'argomento:Sections in This Topic:

Termini e definizioniTerms and Definitions

Failover automaticoAutomatic failover
Failover che si verifica automaticamente alla perdita della replica primaria.A failover that occurs automatically on the loss of the primary replica. Il failover automatico è supportato solo quando la replica primaria corrente e una replica secondaria sono entrambe configurate con la modalità di failover impostata su AUTOMATIC e la replica secondaria è attualmente sincronizzata.Automatic failover is supported only when the current primary and one secondary replica are both configured with failover mode set to AUTOMATIC and the secondary replica currently synchronized. Se la modalità di failover della replica primaria o di quella secondaria è MANUAL, il failover automatico non è supportato.If the failover mode of either the primary or secondary replica is MANUAL, automatic failover cannot occur.

Failover manuale pianificato (senza perdita di dati)Planned manual failover (without data loss)
Il failover manuale pianificato o failover manualeè un failover avviato da un amministratore del database, in genere per scopi amministrativi.Planned manual failover, or manual failover, is a failover that is initiated by a database administrator, typically, for administrative purposes. Un failover manuale pianificato è supportato solo se la replica primaria e la replica secondaria sono entrambe configurate per la modalità commit sincrono e la replica secondaria è attualmente sincronizzata (nello stato SYNCHRONIZED).A planned manual failover is supported only if both the primary replica and secondary replica are configured for synchronous-commit mode and the secondary replica is currently synchronized (in the SYNCHRONIZED state). Quando la replica secondaria di destinazione è sincronizzata, il failover manuale (senza perdita di dati) è possibile anche se la replica primaria è stata arrestata in modo anomalo perché i database secondari sono pronti per il failover.When the target secondary replica is synchronized, manual failover (without data loss) is possible even if the primary replica has crashed because the secondary databases are ready for failover. Un amministratore di database avvia manualmente un failover manuale.A database administrator manually initiates a manual failover.

Failover forzato (con possibile perdita di dati)Forced failover (with possible data loss)
Failover che può essere avviato da un amministratore del database quando nessuna replica secondaria è sincronizzata (SYNCHRONIZED) con la replica primaria o la replica primaria non è in esecuzione e nessuna replica secondaria è pronta per il failover.A failover that can be initiated by a database administrator when no secondary replica is SYNCHRONIZED with the primary replica or the primary replica is not running and no secondary replica is failover ready. Il failover forzato implica il rischio della perdita di dati ed è rigorosamente consigliato per il ripristino di emergenza.Forced failover risks possible data loss and is recommended strictly for disaster recovery. Il failover forzato è anche noto come failover manuale forzato, in quanto può essere avviato solo manualmente.Forced failover is also known as forced manual failover because it can only be initiated manually. Si tratta dell'unica forma di failover supportata nella modalità di disponibilità commit asincrono.This is the only form of failover supported by in asynchronous-commit availability mode.

Failover automatico impostato
In un determinato gruppo di disponibilità, coppia di repliche di disponibilità, inclusa la replica primaria corrente, configurata per la modalità commit sincrono con failover automatico.Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. An failover automatico impostatoautomatic failover setdiventa effettivo solo se la replica secondaria si trova attualmente nello stato SINCRONIZZATO con la replica primaria.An failover automatico impostatoautomatic failover settakes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

Failover con commit sincrono impostatoSynchronous-commit failover set
In un determinato gruppo di disponibilità, set di due o tre repliche di disponibilità, inclusa la replica primaria corrente, configurato per la modalità commit sincrono, se presente.Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. Un failover con commit sincrono impostatosynchronous-commit failover setdiventa effettivo solo se le repliche secondarie sono configurate per la modalità di failover manuale e almeno una replica secondaria si trova attualmente nello stato SINCRONIZZATO con la replica primaria.A failover con commit sincrono impostatosynchronous-commit failover settakes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

Failover intero impostatoEntire failover set
In un determinato gruppo di disponibilità, il set di tutte le repliche di disponibilità il cui stato operativo è attualmente ONLINE, indipendentemente dalle modalità di disponibilità e di failover.Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. Un failover intero impostatoentire failover setdiventa rilevante quando nessuna replica secondaria si trova attualmente nello stato SINCRONIZZATO con la replica primaria.The failover intero impostatoentire failover setbecomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

Panoramica del failoverOverview of Failover

Nella tabella seguente sono riportate le forme di failover supportate nelle diverse modalità di disponibilità e di failover.The following table summarizes which forms of failover are supported under different availability and failover modes. Per ogni associazione, la modalità di disponibilità e la modalità di failover effettive vengono determinate dall'intersezione delle modalità della replica primaria in aggiunta alle modalità di una o più repliche secondarie.For each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of the primary replica plus the modes of one or more secondary replicas.

Modalità commit asincronoAsynchronous-commit mode Modalità commit sincrono con modalità di failover manualeSynchronous-commit mode with manual-failover mode Modalità commit sincrono con modalità di failover automaticoSynchronous-commit mode with automatic-failover mode
Failover automaticoAutomatic failover NoNo NoNo Yes
Failover manuale pianificatoPlanned manual failover NoNo Yes Yes
failover forzatoForced failover Yes Yes \Yes****

\Se si esegue un comando di failover forzato su una replica secondaria sincronizzata, la replica secondaria si comporta come con un failover manuale.****If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a manual failover.

Il periodo di tempo di non disponibilità del database durante un failover dipende dal tipo di failover e da ciò che lo ha causato.The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.

Importante

Per supportare le connessioni client dopo il failover, a eccezione dei database indipendenti, è necessario ricreare manualmente sul nuovo database primario gli account di accesso e i processi definiti sui database primari precedenti.To support client connections after failover, except for contained databases, logins and jobs defined on any of the former primary databases must be manually recreated on the new primary database. Per altre informazioni, vedere Gestione di account di accesso e processi per i database di un gruppo di disponibilità (SQL Server).For more information, see Management of Logins and Jobs for the Databases of an Availability Group (SQL Server).

Set di failoverFailover Sets

Le forme di failover possibili per un gruppo di disponibilità specificato possono essere comprese in termini di set di failover.The forms of failover that are possible for a given availability group can be understood in terms of failover sets. Un set di failover è composto dalla replica primaria e dalle repliche secondarie che supportano una forma specificata di failover, come riportato di seguito.A failover set consists of the primary replica and secondary replicas that support a given form of failover, as follows:

  • Failover automatico impostato (facoltativo): in un determinato gruppo di disponibilità, coppia di repliche di disponibilità, inclusa la replica primaria corrente, configurata per la modalità commit sincrono con failover automatico, se presente. Failover automatico impostato (optional): Within a given availability group, a pair of availability replicas (including the current primary replica) that are configured for synchronous-commit mode with automatic failover, if any. Un failover automatico impostato diventa effettivo solo se la replica secondaria si trova attualmente nello stato SYNCHRONIZED con la replica primaria.An automatic failover set takes effect only if the secondary replica is currently SYNCHRONIZED with the primary replica.

  • Failover con commit sincrono impostatoSynchronous-commit failover set (facoltativo): in un determinato gruppo di disponibilità, set di due o tre repliche di disponibilità, inclusa la replica primaria corrente, configurato per la modalità commit sincrono, se presente. Failover con commit sincrono impostatoSynchronous-commit failover set (optional): Within a given availability group, a set of two or three availability replicas (including the current primary replica) that are configured for synchronous-commit mode, if any. Un failover con commit sincrono impostato diventa effettivo solo se le repliche secondarie sono configurate per la modalità di failover manuale e almeno una replica secondaria si trova nello stato SYNCHRONIZED con la replica primaria.A synchronous-commit failover set takes effect only if the secondary replicas are configured for manual failover mode and at least one secondary replica is currently SYNCHRONIZED with the primary replica.

  • Failover intero impostatoEntire failover set : in un determinato gruppo di disponibilità, il set di tutte le repliche di disponibilità il cui stato operativo è attualmente ONLINE, indipendentemente dalle modalità di disponibilità e di failover. Failover intero impostatoEntire failover set : Within a given availability group, the set of all availability replicas whose operational state is currently ONLINE, regardless of availability mode and of failover mode. L'intero set di failover diventa rilevante quando nessuna replica secondaria si trova attualmente nello stato SYNCHRONIZED con la replica primaria.The entire failover set becomes relevant when no secondary replica is currently SYNCHRONIZED with the primary replica.

    Quando si configura una replica di disponibilità come commit sincrono con failover automatico, la replica di disponibilità diventa parte del failover automatico impostatoautomatic failover set.When you configure an availability replica as synchronous commit with automatic failover, the availability replica becomes part of the failover automatico impostatoautomatic failover set. Il fatto che un set diventi effettivo o meno dipende tuttavia dal database primario corrente.However whether the set takes effect depends the current primary. Le forme di failover effettivamente possibili in un determinato momento dipendono dai set di failover attualmente effettivi.The forms of failover that are actually possible at a given time depends on what failover sets are currently in effect.

    Si consideri ad esempio un gruppo di disponibilità con quattro repliche di disponibilità:For example, consider an availability group that has four availability replicas, as follows:

ReplicaReplica Impostazioni delle modalità di disponibilità e di failoverAvailability Mode and Failover Mode Settings
UnA Commit sincrono con failover automaticoSynchronous commit with automatic failover
BB Commit sincrono con failover automaticoSynchronous commit with automatic failover
CC Commit sincrono solo con failover manuale pianificatoSynchronous commit with planned manual failover only
DD Commit asincrono (solo con failover forzato)Asynchronous commit (with only forced failover)

Il comportamento di failover di ogni replica secondaria dipende dalla replica di disponibilità che è attualmente la replica primaria.The failover behavior for each secondary replica depends on which availability replica is currently the primary replica. Fondamentalmente, per una determinata replica secondaria, il comportamento di failover è il caso peggiore data la replica primaria corrente.Basically, for a given secondary replica, the failover behavior is the worst case given the current primary replica. Nell'illustrazione seguente viene descritto come il comportamento del failover di repliche secondarie varia a seconda della replica primaria corrente e se è configurato per la modalità con commit asincrono (solo con failover forzato) o la modalità con commit sincrono (con o senza failover automatico).The following figure illustrates how the failover behavior of secondary replicas varies depending on the current primary replica, and whether it is configured for asynchronous-commit mode (with only forced failover) or synchronous-commit mode (with or without automatic failover).

Effetto del failover sulla configurazione della replica primariaHow primary replica configuration affects failover

Automatic FailoverAutomatic Failover

In seguito a un failover automatico, una replica secondaria qualificata assume automaticamente il ruolo primario quando la replica primaria non è più disponibile.An automatic failover causes a qualified secondary replica to automatically transition to the primary role after the primary replica becomes unavailable. Il failover automatico è particolarmente appropriato quando il nodo WSFC che ospita la replica primaria è locale rispetto al nodo che ospita la replica secondaria.Automatic failover is best suited when the WSFC node that hosts the primary replica is local to the node that hosts the secondary replica. Ciò dipende dal fatto che la sincronizzazione dei dati funziona meglio con una latenza del messaggio bassa tra i computer e le connessioni client possono rimanere locali.This is because data synchronization works best with low message latency between computers and because client connections can remain local.

Contenuto della sezioneIn This Section:

Condizioni necessarie per un failover automaticoConditions Required for an Automatic Failover

Il failover automatico si verifica solo se sussistono le condizioni seguenti:Automatic failover occurs only under the following conditions:

  • Presenza di un set di failover automatico.An automatic failover set exists. Questo set è composto da una replica primaria e da una secondaria (la destinazione del failover automatico) entrambe configurate per la modalità con commit sincrono e impostate su AUTOMATIC per il failover.This set consists of a primary replica and a secondary replica (the automatic failover target) that are both configured for synchronous-commit mode and set to AUTOMATIC failover. Se la replica primaria è impostata su MANUAL per il failover, il failover automatico non è supportato, anche se una replica secondaria è impostata su AUTOMATIC per il failover.If the primary replica is set to MANUAL failover, automatic failover cannot occur, even if a secondary replica is set to AUTOMATIC failover.

    Per altre informazioni, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn).For more information, see Availability Modes (Always On Availability Groups).

  • La destinazione del failover automatico deve avere uno stato di sincronizzazione integro ad indicare che ogni database secondario sulla destinazione del failover è sincronizzato con il database primario corrispondente.The automatic failover target has a healthy synchronization state (this indicates that every secondary database on the failover target is synchronized with its corresponding primary database).

    Suggerimento

    Gruppi di disponibilità AlwaysOn esegue il monitoraggio dell'integrità di entrambe le repliche in un set di failover automatico.Always On Availability Groups monitors the health of both replicas in an automatic failover set. In caso di errore di una delle repliche, lo stato di integrità del gruppo di disponibilità è impostato su CRITICAL.If either replica fails, the availability group's health state is set to CRITICAL. In caso di errore della replica secondaria, il failover automatico non è possibile dal momento che la relativa destinazione non è disponibile.If the secondary replica fails, automatic failover is not possible because the automatic failover target is unavailable. In caso di errore della replica primaria, verrà eseguito il failover del gruppo di disponibilità sulla replica secondaria.If the primary replica fails, the availability group will fail over to the secondary replica. Fino a quando la replica primaria precedente non torna online, non sarà disponibile alcuna destinazione di failover automatico.Until the former primary replica comes online, no automatic failover target exists. In entrambi i casi, per garantire la disponibilità in caso di un errore sequenziale, è consigliabile configurare una replica secondaria diversa come destinazione del failover automatico.In either case, to ensure availability in the unlikely case of a sequential failure, we recommend that you configure a different secondary replica as the automatic failover target.

    Per altre informazioni, vedere Utilizzare i criteri AlwaysOn per visualizzare l'integrità di un gruppo di disponibilità (SQL Server) e Modificare la modalità di failover di una replica di disponibilità (SQL Server).For more information, see Use Always On Policies to View the Health of an Availability Group (SQL Server) and Change the Failover Mode of an Availability Replica (SQL Server).

  • Il cluster WSFC (Windows Server Failover Clustering) dispone del quorum.The Windows Server Failover Clustering (WSFC) cluster has quorum. Per altre informazioni, vedere Modalità quorum WSFC e configurazione del voto (SQL Server).For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

  • La replica primaria non è più disponibile e i livelli delle condizioni di failover definiti dai criteri di failover flessibili sono stati soddisfatti.The primary replica has become unavailable, and the failover-condition levels defined by your the flexible failover policy have been met. Per informazioni sui livelli di condizione del failover, vedere Criteri di failover flessibili per failover automatico di un gruppo di disponibilità (SQL Server).For information about failover-condition levels, see Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server).

Funzionamento del failover automaticoHow Automatic Failover Works

Un failover automatico dà inizio alla sequenza di azioni seguente:An automatic failover initiates the following sequence of actions:

  1. Se l'istanza del server che ospita la replica primaria corrente è ancora in esecuzione, lo stato dei database primari diventa DISCONNECTED e tutti i client vengono disconnessi.If the server instance that is hosting the current primary replica is still running, it changes the state of the primary databases to DISCONNECTED and disconnects all clients.

  2. Se alcuni record del log sono in attesa in code di recupero sulla replica secondaria di destinazione, la replica secondaria applica i rimanenti record del log per completare il rollforward dei database secondari.If any log records are waiting in recovery queues on the target secondary replica, the secondary replica applies the remaining log records to finish rolling forward the secondary databases.

    Nota

    La quantità di tempo necessaria per applicare il log a un determinato database dipende dalla velocità del sistema, dal carico di lavoro recente e dal numero di record del log presenti nella coda di recupero.The amount of time required to apply the log to a given database depends on the speed of the system, the recent work load, and the amount of log in the recovery queue.

  3. Le replica secondaria precedente assume il ruolo primario.The former secondary replica transitions to the primary role. I relativi database diventano i database primari.Its databases become the primary databases. La nuova replica primaria esegue il più rapidamente possibile il rollback di eventuali transazioni di cui non è ancora stato eseguito il commit (fase di rollback del recupero).The new primary replica rolls back any uncommitted transactions (the undo phase of recovery) as quickly as possible. I blocchi isolano queste transazioni in modo che il rollback venga eseguito in background mentre i client utilizzano il database.Locks isolate these uncommitted transactions, allowing roll back to occur in the background while clients use the database. Questo processo non prevede il rollback delle transazioni di cui è già stato eseguito il commit.This process does not roll back any committed transactions.

    Un database secondario finché non viene connesso viene brevemente contrassegnato come NOT_SYNCHRONIZED.Until a given secondary database is connected, it is briefly marked as NOT_SYNCHRONIZED. Prima dell'avvio del recupero di rollback, i database secondari si possono connettere ai nuovi database primari e rapidamente passare allo stato SYNCHRONIZED.Before the rollback recovery starts, secondary databases can connect to the new primary databases and quickly transition to the SYNCHRONIZED state. La situazione migliore generalmente è per una terza replica con commit sincrono che rimane nel ruolo secondario dopo il failover.The best case is usually for a third synchronous-commit replica that remains in the secondary role after the failover.

  4. Al riavvio, l'istanza del server che ospita la replica primaria precedente riconosce che il ruolo primario è stato assunto da un'altra replica di disponibilità.Later, when the server instance that is hosting the former primary replica restarts, it recognizes that another availability replica now owns the primary role. La replica primaria precedente passa quindi al ruolo secondario e i relativi database diventano database secondari.The former primary replica transitions to the secondary role, and its databases become secondary databases. La nuova replica secondaria si connette alla replica primaria corrente e intercetta il più rapidamente possibile il relativo database fino ai database primari correnti.The new secondary replica connects to the current primary replica and catches its database up to the current primary databases as quickly as possible. Non appena la nuova replica secondaria completa la risincronizzazione dei relativi database, il failover è nuovamente possibile nella direzione inversa.As soon as the new secondary replica has resynchronized its databases, failover is again possible, in the reverse direction.

Per configurare il failover automaticoTo Configure Automatic Failover

Una replica di disponibilità può essere configurata per il supporto del failover automatico in qualsiasi momento.An availability replica can be configured to support automatic failover at any point.

To configure automatic failoverTo configure automatic failover

  1. Assicurarsi che la replica secondaria sia configurata per l'utilizzo della modalità di disponibilità commit sincrono.Ensure that the secondary replica is configured to use the synchronous-commit availability mode. Per altre informazioni, vedere Modificare la modalità di disponibilità di una replica di disponibilità (SQL Server).For more information, see Change the Availability Mode of an Availability Replica (SQL Server).

  2. Impostare la modalità di failover su automatico.Set the failover mode to automatic. Per altre informazioni, vedere Modificare la modalità di failover di una replica di disponibilità (SQL Server).For more information, see Change the Failover Mode of an Availability Replica (SQL Server).

  3. Facoltativamente, modificare i criteri di failover flessibili del gruppo di disponibilità per specificare gli ordinamenti di errori che possono fare in modo che si verifichi un failover automatico.Optionally, change the flexible failover policy of the availability group to specify the sorts of failures that can cause an automatic failover to occur. Per altre informazioni, vedere Configurare i criteri di failover flessibili per controllare le condizioni per il failover automatico (Gruppi di disponibilità AlwaysOn) e Criteri di failover per istanze del cluster di failover.For more information, see Configure the Flexible Failover Policy to Control Conditions for Automatic Failover (Always On Availability Groups) and Failover Policy for Failover Cluster Instances.

Failover manuale pianificato (senza perdita di dati)Planned Manual Failover (Without Data Loss)

Il failover manuale comporta il passaggio al ruolo primario di una replica secondaria sincronizzata dopo che un amministratore di database esegue un comando di failover manuale sull'istanza del server che ospita la replica secondaria di destinazione.A manual failover causes a synchronized secondary replica to transition to the primary role after a database administrator issues a manual-failover command on the server instance that hosts the target secondary replica. Per supportare il failover manuale, la replica secondaria e la replica primaria corrente devono essere entrambe configurate per la modalità commit sincrono, se presente.To support manual failover, the secondary replica and the current primary replica must both be configured for synchronous-commit mode, if any. Di ogni database secondario sulla replica di disponibilità deve essere creato un join al gruppo di disponibilità e sincronizzato con il database primario corrispondente, vale a dire la replica secondaria deve essere sincronizzata.Every secondary database on the availability replica must be joined to the availability group and synchronized with its corresponding primary database (that is, the secondary replica must be synchronized). In questo modo si assicura che ogni transazione sottoposta a commit sul database primario precedente lo sia anche sul nuovo database primario.This guarantees that every transaction that was committed on a former primary database has also been committed on the new primary database. I nuovi database primari risulteranno pertanto identici ai database primari precedenti.Therefore, the new primary databases are identical to the old primary databases.

Nella figura seguente vengono illustrate le fasi di un failover pianificato:The following figure illustrates the stages of a planned failover:

  1. Prima del failover, la replica primaria è ospitata dall'istanza del server in Node01.Before the failover, the primary replica is hosted by the server instance on Node01.

  2. Un amministratore di database avvia un failover pianificato.A database administrator initiates a planned failover. La destinazione del failover è la replica di disponibilità ospitata dall'istanza del server in Node02.The failover target is the availability replica hosted by the server instance on Node02.

  3. La destinazione del failover (in Node02) diventa la nuova replica primaria.The failover target (on Node02) becomes the new primary replica. Poiché questo è un failover pianificato, la prima replica primaria passa al ruolo secondario durante il failover e porta immediatamente i database online come database secondari.Because this is a planned failover, the former primary replica switches to the secondary role during the failover and brings its databases online as secondary databases immediately.

    Illustrazione di un failover manuale pianificatoIllustation of a planned manual failover

    Contenuto della sezioneIn This Section:

Condizioni necessarie per un failover manualeConditions Required for a Manual Failover

Per supportare un failover manuale, la replica primaria corrente deve essere impostata sulla modalità commit sincrono e una replica secondaria deve essere:To support a manual failover, the current primary replica must be set to synchronous-commit mode and a secondary replica must be:

  • Configurata per la modalità commit sincrono.Configured for synchronous-commit mode.

  • Attualmente sincronizzata con la replica primaria.Currently synchronized with the primary replica.

    Per eseguire manualmente il failover su un gruppo di disponibilità, è necessario connettersi alla replica secondaria che deve diventare la nuova replica primaria.To manually fail over an availability group, you must be connected to the secondary replica that is to become the new primary replica.

Funzionamento del failover manuale pianificatoHow a Planned Manual Failover Works

Il failover manuale pianificato, che deve essere avviato sulla replica secondaria di destinazione, dà inizio alla sequenza di azioni seguente:A planned manual failover, which must be initiated on the target secondary replica, initiates the following sequence of actions:

  1. Per assicurarsi che nessuna nuova transazione utente si verifichi sui database primari originali, il cluster WSFC invia una richiesta alla replica primaria per passare alla modalità offline.To ensure that no new user transactions occur on the original primary databases, the WSFC cluster sends a request to the primary replica to go offline.

  2. Se alcuni log sono in attesa nella coda di recupero di un database secondario qualsiasi, la replica secondaria completa il rollforward di quel database secondario.If any log is waiting in the recovery queue of any secondary database, the secondary replica finishes rolling forward that secondary database. La quantità di tempo necessaria dipende dalla velocità del sistema, dal carico di lavoro recente e dal numero di record del log nella coda di recupero.The amount of time required depends on the speed of the system, the recent workload, and the amount of log in the recovery queue. Per conoscere le dimensioni correnti della coda di recupero, usare il contatore delle prestazioni Coda di recupero .To learn the current size of the recovery queue, use the Recovery Queue performance counter. Per altre informazioni, vedere SQL Server, replica di database.For more information, see SQL Server, Database Replica.

    Nota

    Il tempo di failover può essere regolato limitando le dimensioni della coda di recupero.The failover time can be regulated by limiting the size of the recovery queue. Questa operazione, tuttavia, può causare un rallentamento della replica primaria a vantaggio della replica secondaria.However, this can cause the primary replica to slow down to allow the secondary replica to keep up.

  3. La replica secondaria diventa la nuova replica primaria e la replica primaria precedente diventa la nuova replica secondaria.The secondary replica becomes the new primary replica, and the former primary replica becomes the new secondary replica.

  4. La nuova replica primaria esegue il rollback di eventuali transazioni di cui non è stato eseguito il commit e porta online i database come database primari. Tutti i database secondari vengono brevemente contrassegnati come NOT_SYNCHRONIZED finché non vengono connessi e risincronizzati con i nuovi database primari.The new primary replica rolls back any uncommitted transactions and brings its databases online as the primary databases.All secondary databases are briefly marked as NOT SYNCHRONIZED until they connect and resynchronize to the new primary databases. Questo processo non prevede il rollback delle transazioni di cui è già stato eseguito il commit.This process does not roll back any committed transactions.

  5. Quando la replica primaria precedente viene riportata online, assume il ruolo secondario e il database primario diventa il database secondario.When the former primary replica comes back online, it takes on the secondary role, and the former primary database becomes the secondary database. La nuova replica secondaria risincronizza rapidamente i nuovi database secondari con i database primari corrispondenti.The new secondary replica quickly resynchronizes the new secondary databases with the corresponding primary databases.

    Nota

    Non appena la nuova replica secondaria completa la risincronizzazione dei database, il failover è nuovamente possibile nella direzione inversa.As soon as the new secondary replica has resynchronized the databases, failover is again possible, but in the reverse direction.

    Dopo il failover, è necessario riconnettere i client al database primario corrente.After failover, clients must reconnect to the current primary database. Per altre informazioni, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server).For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

Mantenimento della disponibilità durante gli aggiornamentiMaintaining Availability During Upgrades

L'amministratore di database per i gruppi di disponibilità può utilizzare i failover manuali per gestire la disponibilità dei database durante aggiornamenti hardware o software.The database administrator for your availability groups can use manual failovers to maintain database availability when you upgrade hardware or software. Per utilizzare un gruppo di disponibilità per aggiornamenti software, l'istanza del server e/o il nodo computer che ospita la replica secondaria di destinazione deve avere già ricevuto gli aggiornamenti.To use an availability group for software upgrades, the server instance and/or computer node that hosts the target secondary replica must have already received the upgrades. Per altre informazioni, vedere Aggiornamento delle istanze di replica dei gruppi di disponibilità AlwaysOn.For more information, see Upgrading Always On Availability Group Replica Instances.

Failover forzato (con possibile perdita di dati)Forced Failover (with Possible Data Loss)

Il failover forzato di un gruppo di disponibilità (con possibile perdita di dati) è un metodo di ripristino di emergenza che consente di usare una replica secondaria come server warm standby. Dal momento che il failover forzato implica il rischio di possibili perdite di dati, è consigliabile usarlo con cautela e quando strettamente necessario.Forcing failover of an availability group (with possible data loss) is a disaster recovery method that allows you to use a secondary replica as a warm standby server.Because forcing failover risks possible data loss, it should be used cautiously and sparingly. È consigliabile forzare il failover solo se è necessario ripristinare immediatamente il servizio sui database di disponibilità e si è disposti a rischiare la perdita di dati.We recommend forcing failover only if you must restore service to your availability databases immediately and are willing to risk losing data. 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 Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server).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 Perform a Forced Manual Failover of an Availability Group (SQL Server).

Avviso

Il failover forzato richiede che il cluster WSFC disponga di quorum.Forcing failover requires that the WSFC cluster have quorum. Per informazioni sulla configurazione e la forzatura del quorum, vedere WSFC (Windows Server Failover Clustering) con SQL Server.For information about configuring quorum and forcing quorum, see Windows Server Failover Clustering (WSFC) with SQL Server.

Contenuto della sezioneIn This Section:

Funzionamento del failover forzatoHow Forced Failover Works

Tramite il failover forzato viene avviata una transizione del ruolo primario a una replica di destinazione il cui ruolo si trova nello stato SECONDARY o RESOLVING.Forcing failover initiates a transition of the primary role to a target replica whose role is in the SECONDARY or RESOLVING state. La destinazione del failover diventa la nuova replica primaria e tramite essa le copie dei database diventano immediatamente disponibili ai client.The failover target becomes the new primary replica and immediately serves its copies of the databases to clients. Quando la replica primaria precedente diventa disponibile, assume il ruolo secondario e i relativi database diventano database secondari.When the former primary replica becomes available, it will transition to the secondary role and its databases will become secondary databases.

Tutti i database secondari (compresi i database primari precedenti, una volta diventati disponibili) si trovano nello stato SUSPENDED.All secondary databases (including the former primary databases, when they become available) are SUSPENDED. A seconda dello stato della sincronizzazione dei dati precedente di un database secondario sospeso, potrebbe essere adatto per recuperare i dati mancanti di cui è stato eseguito il commit per il database primario.Depending on the previous data synchronization state of a suspended secondary database, it might be suitable for salvaging missing committed data for that primary database. Su una replica secondaria configurata per l'accesso in sola lettura, è possibile eseguire query sui database secondari per individuare manualmente i dati mancanti.On a secondary replica that is configured for read-only access, you can query the secondary databases to manually discover missing data. È quindi possibile eseguire istruzioni Transact-SQLTransact-SQL per apportare le modifiche necessarie sui nuovi database primari.Then you can issue Transact-SQLTransact-SQL statements on the new primary databases to make any necessary changes.

Rischi correlati al failover forzatoRisks of Forcing Failover

È fondamentale comprendere che il failover forzato può causare la perdita di dati.It is essential to understand that forcing failover can cause data loss. La perdita di dati è possibile in quanto tramite la replica di destinazione non è possibile comunicare con la replica primaria e pertanto non è possibile garantire che i database siano sincronizzati.Data loss is possible because the target replica cannot communicate with the primary replica and, therefore, cannot guarantee that the databases are synchronized. Il failover forzato comporta l'avvio di un nuovo fork di recupero.Forcing failover starts a new recovery fork. Poiché i database primari originali e i database secondari si trovano su fork di recupero diversi, ognuno di essi contiene dati che l'altro database non contiene: ogni database primario originale contiene tutte le modifiche non inviate al database secondario precedente dalla sua coda di invio (log non inviato). I database secondari precedenti contengono tutte le modifiche apportate dopo il failover forzato.Because the original primary databases and secondary databases are on different recovery forks, each of them now contains data that the other database does not contain: each original primary database contains whatever changes were not yet sent from its send queue to the former secondary database (the unsent log); the former secondary databases contain whatever changes occur after failover was forced.

Se il failover viene forzato a causa di un errore della replica primaria, la potenziale perdita di dati dipende dal fatto che uno o più log delle transazioni non siano stati inviati alla replica secondaria prima dell'errore.If failover is forced because the primary replica has failed, potential data loss is depends on whether any transaction logs had not been sent to the secondary replica before the failure. Nella modalità commit asincrono, la presenza di log non inviati accumulati è sempre una possibilità.Under the asynchronous-commit mode, accumulated unsent log is always a possibility. Nella modalità commit sincrono, questo è possibile solo fino a quando i database secondari non diventano sincronizzati.Under synchronous-commit mode, this is possible only until the secondary databases becomes synchronized.

Nella tabella seguente è riepilogata la possibilità di perdita di dati per un particolare database sulla replica a cui viene applicato un failover forzato.The following table summarizes the possibility of data loss for a particular database on the replica to which you force failover.

Modalità di disponibilità della replica secondariaAvailability mode of Secondary Replica Il database è sincronizzato?Is database synchronized? È possibile che si verifichi una perdita dei dati?Is data loss possible?
Synchronous-commitSynchronous-commit Yes NoNo
Synchronous-commitSynchronous-commit NoNo Yes
Asynchronous-commitAsynchronous-commit NoNo Yes

I database secondari registrano solo due fork di recupero, pertanto se si eseguono più failover forzati, qualsiasi database secondario che abbia dato inizio alla sincronizzazione dati con il failover forzato precedente non potrà essere ripreso.Secondary databases track only two recovery forks, so if you perform multiple forced failovers, any secondary database that did start data synchronization with the previous force failover might not be able to resume. In questo caso, i database secondari che non possono essere ripresi dovranno essere rimossi dal gruppo di disponibilità, ripristinati fino al momento corretto e nuovamente aggiunti al gruppo di disponibilità.If this occurs, any secondary databases that cannot be resumed will need to be removed from the availability group, restored to the correct point in time, and rejoined to the availability group. Un ripristino non funziona tra più fork di recupero, pertanto, assicurarsi di eseguire un backup del log dopo avere eseguito più failover forzati.A restore will not work across multiple recovery forks, therefore, be sure to perform a log backup after performing more than one forced failover.

Motivi per cui è necessario il failover forzato dopo aver forzato il quorumWhy Forced Failover is Required After Forcing Quorum

Dopo aver forzato il quorum sul cluster WSFC (quorum forzato), sarà necessario effettuare un failover forzato (con possibile perdita di dati) su ogni gruppo di disponibilità.After quorum is forced on the WSFC cluster (forced quorum) you need to perform a forced failover (with possible data loss) on each availability group. Il failover forzato è necessario poiché lo stato effettivo dei valori del cluster WSFC potrebbe essere andato perso.The forced failover is required because the real state of the WSFC cluster values might have been lost. Dopo un quorum forzato è necessario evitare i failover normali poiché una replica secondaria non sincronizzata potrebbe essere visualizzata come sincronizzata nel cluster WSFC riconfigurato.Preventing normal failovers after a forced quorum is required because of the possibility than an unsynchronized secondary replica would appear to be synchronized on the reconfigured WSFC cluster.

Ad esempio, si consideri un cluster WSFC in cui un gruppo di disponibilità è ospitato in tre nodi: nel nodo A è ospitata la replica primaria, mentre nei nodi B e C è ospitata una replica secondaria.For example, consider a WSFC cluster that hosts an availability group on three nodes: Node A hosts the primary replica and Node B and Node C each hosts a secondary replica. Il nodo C viene disconnesso dal cluster WSFC mentre la replica secondaria locale è sincronizzata (SYNCHRONIZED).Node C gets disconnected from the WSFC cluster while the local secondary replica is SYNCHRONIZED. Tuttavia, nei nodi A e B viene mantenuto un quorum integro e il gruppo di disponibilità rimane online.But Node A and Node B retain a healthy quorum and the availability group remains online. Nel nodo A gli aggiornamenti continuano ad essere accettati dalla replica primaria, mentre nel nodo B prosegue la sincronizzazione della replica secondaria con quella primaria.On Node A, the primary replica continues to accept updates, and on Node B, the secondary replica continues to synchronize with the primary replica. La replica secondaria nel nodo C diventa non sincronizzata e viene persa la sincronizzazione con la replica primaria.The secondary replica on Node C becomes unsynchronized and falls increasingly behind the primary replica. Tuttavia, poiché il nodo C è disconnesso, la replica rimane, in modo non corretto, nello stato SYNCHRONIZED.However, because Node C is disconnected, the replica remains, incorrectly, in the SYNCHRONIZED state.

Se il quorum viene perso e, successivamente, viene forzato nel nodo A, lo stato di sincronizzazione del gruppo di disponibilità nel cluster WSFC deve essere corretto, con la replica secondaria nel nodo C visualizzata come UNSYNCHRONIZED.If quorum is lost and is then forced on Node A, the synchronization state of the availability group on the WSFC cluster should be correct—with the secondary replica on Node C shown as UNSYNCHRONIZED. Tuttavia, se il quorum viene forzato nel nodo C, la sincronizzazione del gruppo di disponibilità non sarà corretta.However, if quorum is forced on Node C, the synchronization of the availability group will be incorrect. Nel cluster verrà ripristinato lo stato di sincronizzazione attivo quando il nodo C era disconnesso, con la replica secondaria nel nodo C visualizzata erroneamente come SYNCHRONIZED.The synchronization state on the cluster will have reverted back to when Node C was disconnected—with the secondary replica on Node C incorrectly shown as SYNCHRONIZED. Poiché tramite i failover manuali pianificati viene garantita la sicurezza dei dati, una volta forzato il quorum non è consentito riportare un gruppo di disponibilità online.Since planned manual failovers guarantee the safety of the data, they are disallowed for bring an availability group back online after quorum is forced.

Come tenere traccia della potenziale perdita di datiTracking Potential Data Loss

Quando nel cluster WSFC è disponibile un quorum integro, è possibile stimare il potenziale rischio corrente di perdita di dati nei database.When the WSFC cluster has a healthy quorum, you can estimate the current potential for data loss on databases. Per una replica secondaria specifica, il potenziale rischio corrente di perdita di dati dipende dal ritardo dei database secondari locali rispetto ai database primari corrispondenti.For a given secondary replica, the current potential for data loss depends on how far the local secondary databases are lagging behind the corresponding primary databases. Poiché la quantità di ritardo varia nel tempo, è consigliabile tenere traccia periodicamente della perdita di dati potenziale per i database secondari non sincronizzati.Because the amount of lag varies over time, we recommend that you periodically track potential data loss for your unsynchronized secondary databases. Ai fini del rilevamento del ritardo è necessario eseguire il confronto tra LSN ultimo commit e Ora ultimo commit per ogni database primario e i relativi database secondari, come riportato di seguito:Tracking lag involves comparing the Last Commit LSN and Last Commit Time for each primary database and its secondary databases, as follows:

  1. Connettersi alla replica primaria.Connect to the primary replica.

  2. Eseguire una query nelle colonne last_commit_lsn (LSN dell'ultima transazione sottoposta a commit) e last_commit_time (ora dell'ultimo commit) della DMV sys.dm_hadr_database_replica_states .Query the last_commit_lsn (LSN of the last committed transaction) and last_commit_time (time of the last commit) columns of the sys.dm_hadr_database_replica_states dynamic management view.

  3. Confrontare i valori restituiti per ogni database primario e tutti i relativi database secondari.Compare the values returned for each primary database and each of its secondary databases. La differenza tra gli LSN ultimo commit indica la quantità di ritardo.The difference between their Last Commit LSNs indicate the amount of lag.

  4. È possibile attivare un avviso quando la quantità di ritardo in un database o set di database supera il ritardo massimo desiderato per un periodo di tempo specificato.You can trigger an alert when the amount of lag on a database or set of databases exceeds your desired maximum lag for a given period of time. Ad esempio, la query può essere eseguita da un processo che viene eseguito ogni minuto in ciascun database primario.For example, the query can be run by a job that executes every minute on each primary database. Se la differenza tra last_commit_time di un database primario e uno dei relativi database secondari ha superato l'obiettivo del punto di recupero (RPO, Recovery Point Objective), ad esempio 5 minuti, dall'ultima esecuzione del processo, quest'ultimo può generare un avviso.If the difference between the last_commit_time of a primary database and any of its secondary databases has exceeded the recovery point objective (RPO) (for example, 5 minutes) since the last time the job executed, the job can raise an alert.

Importante

Quando nel cluster WSFC manca il quorum o quest'ultimo è stato forzato, last_commit_lsn e last_commit_time sono NULL.When the WSFC cluster lacks quorum or quorum has been forced, last_commit_lsn and last_commit_time are NULL. Per informazioni su come evitare la perdita di dati dopo aver forzato un quorum, vedere "Metodi possibili per evitare la perdita di dati dopo aver forzato il quorum" in Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server).For information about how you might be able to avoid data loss after you forced quorum, see "Potential Ways to Avoid Data Loss After Quorum is Forced" in Perform a Forced Manual Failover of an Availability Group (SQL Server).

Gestione della potenziale perdita di datiManaging the Potential Data Loss

Dopo aver forzato il failover, tutti i database secondari vengono sospesi.After failover is forced, 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 la replica primaria precedente diventa disponibile, supponendo che i relativi database non siano danneggiati, è possibile tentare di gestire la potenziale perdita di dati.Once the former primary replica is available, assuming that its databases are undamaged, you can attempt to manage the potential data loss. L'approccio disponibile per la gestione della potenziale perdita di dati dipende dal fatto che la replica primaria originale sia connessa o meno alla nuova replica primaria.The available approach for managing potential data loss depends on whether the original primary replica has connected to the new primary replica. Supponendo che la replica primaria originale possa accedere alla nuova istanza primaria, la riconnessione avviene in modo automatico e trasparente.Assuming that the original primary replica can access the new primary instance, reconnecting occurs automatically and transparently.

La replica primaria originale è stata riconnessaThe Original Primary Replica Has Reconnected

In genere, dopo un errore, al riavvio la replica primaria originale si riconnette rapidamente al proprio partner.Typically, after a failure, when the original primary replica restarts it quickly reconnects to its partner. Alla riconnessione, la replica primaria originale diventa la replica secondaria.On reconnecting, the original primary replica becomes the secondary replica. I relativi database diventano i database secondari e vengono impostati sullo stato SUSPENDED.Its databases becomes the secondary databases and enter the SUSPENDED state. Per i nuovi database secondari non verrà eseguito il rollback a meno che non vengano ripresi.The new secondary databases will not be not rolled back unless you resume them.

I database sospesi, tuttavia, sono inaccessibili, pertanto non è possibile verificarli per capire quali dati andrebbero persi in caso di ripresa di un determinato database.However, the suspended databases are inaccessible, so you cannot inspect them to evaluate what data would be lost if you were to resume a given database. Pertanto, la decisione relativa alla ripresa o alla rimozione di un database secondario dipende dal fatto che si sia disposti o meno ad accettare eventuali perdite di dati:Therefore, the decision on whether to resume or remove a secondary database depends on whether you are willing to accept any data loss, as follows:

  • Se la perdita di dati non è accettabile, rimuovere i database dal gruppo di disponibilità per recuperarli.If losing any data would be unacceptable, you should remove the databases from the availability group to salvage them.

    L'amministratore di database potrà recuperare i database primari precedenti e tentare di recuperare i dati che sarebbero andati persi.The database administrator can now recover the former primary databases and attempt to recover the data that would have been lost. Tuttavia, quando un database primario precedente viene portato online, è diverso dal database primario corrente, pertanto l'amministratore di database deve rendere inaccessibile ai client il database rimosso o il database primario corrente in modo da evitare ulteriori divergenze tra i database e impedire problemi di failover al livello dei client.However, when a former primary database comes online, it is divergent from the current primary database, so the database administrator needs to make either the removed database or the current primary database inaccessible to clients to avoid further divergence of the databases and to prevent client-failover issues.

  • Se la perdita di dati fosse accettabile, è possibile riprendere i database secondari.If losing data would be acceptable to your business goals, you can resume the secondary databases.

    Se si riprende un nuovo database secondario, il rollback diventa il primo passaggio della sincronizzazione del database.Resuming a new secondary database causes it to be rolled back as the first step in synchronizing the 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.If any log records were waiting in the send queue at the time of failure, the corresponding transactions are lost, even if they were committed.

La replica primaria originale non è stata riconnessaThe Original Primary Replica Has Not Reconnected

Se è possibile impedire temporaneamente alla replica primaria originale di riconnettersi in rete alla nuova replica primaria, è possibile esaminare i database primari originali per capire quali dati andrebbero persi se venissero ripresi.If you can temporarily prevent the original primary replica from reconnecting over the network to the new primary replica, you can inspect the original primary databases to evaluate what data would be lost if they were resumed.

  • Contesti in cui la perdita di dati è accettabileIf the potential data loss is acceptable

    Consentire alla replica primaria originale di riconnettersi alla nuova replica primaria.Allow the original primary replica to reconnect to the new primary replica. La riconnessione comporta la sospensione dei nuovi database secondari.Reconnecting causes the new secondary databases to be suspended. Per avviare la sincronizzazione dati su un database, riprenderlo.To start data synchronization on a database, simply resume it. La nuova replica secondaria elimina il fork di recupero originale per quel database, perdendo eventuali transazioni mai inviate o ricevute dalla replica secondaria precedente.The new secondary replica drops the original recovery fork for that database, losing any transactions that were never sent to or received by the former secondary replica.

  • Contesti in cui la perdita di dati non è ammissibileIf the data loss is unacceptable

    Se il database primario originale contiene dati critici che andrebbero persi in caso di ripresa del database sospeso, è possibile conservare i dati sul database primario originale rimuovendolo dal gruppo di disponibilità.If the original primary database contains critical data that would be lost if you resumed the suspended database, you can preserve the data on the original primary database by removing it from the availability group. In seguito a questa operazione il database viene impostato sullo stato RESTORING.This causes the database to enter the RESTORING state. A questo punto, è consigliabile tentare di eseguire il backup della parte finale del log del database rimosso.At this point, we recommend that you attempt to back up the tail of the removed database's log. È quindi possibile aggiornare il database primario corrente (il database secondario precedente) esportando i dati che si desidera recuperare dal database primario originale e importandoli nel database primario corrente.Then, you can update the current primary (the former secondary database) by exporting the data you want to salvage from the original primary database and importing it into the current primary database. È consigliabile eseguire un backup completo del database primario aggiornato il più rapidamente possibile.We recommend taking a full database backup of the updated primary database as quickly as possible.

    Nell'istanza del server che ospita la nuova replica secondaria, è possibile eliminare il database secondario sospeso e creare un nuovo database secondario ripristinando questo backup (e almeno un backup del log successivo) utilizzando RESTORE WITH NORECOVERY.Then, on the server instance that hosts the new secondary replica, you can delete the suspended secondary database and create a new secondary database by restoring this backup (and least one subsequent log backup) using RESTORE WITH NORECOVERY. È consigliabile rimandare backup del log aggiuntivi dei database primari correnti finché non vengono ripresi i database secondari corrispondenti.We recommend delaying additional log backups of the current primary databases until the corresponding secondary databases are resumed.

Avviso

Il troncamento del log delle transazioni viene ritardato nel database primario mentre i relativi database secondari sono 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.

Attività correlateRelated Tasks

Per configurare il comportamento del failoverTo configure failover behavior

Contenuto correlatoRelated Content

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)
WSFC (Windows Server Failover Clustering) con SQL Server Windows Server Failover Clustering (WSFC) with SQL Server
Transazioni tra database non supportate per il mirroring del database o i gruppi di disponibilità AlwaysOn (SQL Server) Cross-Database Transactions and Distributed Transactions for Always On Availability Groups and Database Mirroring (SQL Server)
Criteri di failover per istanze del cluster di failover Failover Policy for Failover Cluster Instances
Criteri di failover flessibili per failover automatico di un gruppo di disponibilità (SQL Server)Flexible Failover Policy for Automatic Failover of an Availability Group (SQL Server)