Modalità di disponibilità (gruppi di disponibilità AlwaysOn)Availability Modes (Always On Availability Groups)

QUESTO ARGOMENTO SI APPLICA A:sìSQL Server (a partire dalla versione 2016)noDatabase SQL di AzurenoAzure SQL Data WarehousenoParallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

In Gruppi di disponibilità Always OnAlways On availability groupsla modalità di disponibilità è una proprietà della replica tramite cui viene determinato se una replica di disponibilità specificata può essere eseguita in modalità con commit sincrono.In Gruppi di disponibilità Always OnAlways On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. La modalità di disponibilità per ogni replica di disponibilità deve essere configurata per la modalità con commit sincrono o per quella con commit asincrono.For each availability replica, the availability mode must be configured for either synchronous-commit mode or asynchronous-commit mode. Se la replica primaria è configurata per la modalità con commit asincrono, non attende che una replica secondaria scriva su disco dei record del log delle transazioni in entrata per finalizzare il log.If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). Se una replica secondaria specificata viene configurata per la modalità con commit asincrono, tramite la replica primaria non viene attesa la finalizzazione del log da parte della replica secondaria.If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. Se la replica primaria e una replica secondaria specifica vengono entrambe configurate per la modalità con commit sincrono, la replica primaria attende la conferma della finalizzazione del log da parte della replica secondaria, a meno che la replica secondaria non sia in grado di eseguire il ping alla replica primaria entro il periodo di timeout della sessionedella replica primaria.If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary's session-timeout period).

Nota

Se il periodo di timeout della sessione della replica primaria viene superato da una replica secondaria, la replica primaria passa temporaneamente in modalità con commit asincrono per questa replica secondaria.If primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. Quando la replica secondaria si riconnette alla replica primaria, viene ripristinata la modalità con commit sincrono.When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Contenuto dell'argomento:In this Topic:

Modalità di disponibilità supportate Supported Availability Modes

Gruppi di disponibilità Always OnAlways On availability groups supporta due modalità di disponibilità: modalità con commit asincrono e modalità con commit sincrono, come indicato di seguito: supports two availability modes—asynchronous-commit mode and synchronous-commit mode, as follows:

  • Lamodalità con commit asincrono è una soluzione di ripristino di emergenza che offre risultati ottimali quando le repliche di disponibilità sono distribuite a distanze considerevoli.Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. Se tutte le repliche secondarie vengono eseguite in modalità con commit asincrono, con la replica primaria non si attende che il log venga finalizzato dalle repliche secondarie.If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. Bensì, subito dopo la scrittura del record del log nel file di log locale, tramite la replica primaria viene inviata la conferma della transazione al client.Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. La replica primaria viene eseguita con una latenza della transazione minima a fronte di una replica secondaria configurata in modalità con commit asincrono.The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. Se la replica primaria corrente è configurata in modalità di disponibilità commit asincrono, eseguirà il commit asincrono delle transazioni per tutte le repliche secondarie indipendentemente dalle singole impostazioni della modalità di disponibilità.If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.

    Per altre informazioni, vedere Modalità di disponibilità con commit asincronopiù avanti in questo argomento.For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • Con lamodalità con commit sincrono si privilegia la disponibilità elevata rispetto alle prestazioni, aumentando tuttavia la latenza delle transazioni.Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. In modalità con commit sincrono, l'invio della conferma della transazione al client da parte delle transazioni avviene solo dopo la finalizzazione del log su disco da parte della replica secondaria.Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. Quando inizia la sincronizzazione dei dati in un database secondario, viene avviata l'applicazione dei record del log in entrata dal database primario corrispondente da parte della replica secondaria.When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. Non appena è terminata la finalizzazione di tutti i record del log, lo stato del database secondario diventa SYNCHRONIZED.As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. Successivamente, ogni nuova transazione viene finalizzata dalla replica secondaria prima che il record del log venga scritto nel file di log locale.Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. Una volta che tutti i database secondari di una determinata replica secondaria sono sincronizzati, la modalità con commit sincrono supporta il failover manuale e, facoltativamente, quello automatico.When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    Per altre informazioni, vedere Modalità di disponibilità con commit sincronopiù avanti in questo argomento.For more information, see Synchronous-Commit Availability Mode, later in this topic.

    Nell'illustrazione seguente viene mostrato un gruppo di disponibilità con cinque repliche di disponibilità.The following illustration shows an availability group with five availability replicas. La replica primaria e una secondaria sono configurate per la modalità con commit sincrono con failover automatico.The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Un'altra replica secondaria è configurata per la modalità con commit sincrono con solo failover manuale pianificato e due repliche secondarie sono configurate per la modalità con commit asincrono, che supporta solo il failover manuale forzato, in genere denominato failover forzato.Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

    Disponibilità e modalità di failover delle replicheAvailability and failover modes of replicas

    Il comportamento di sincronizzazione e failover tra due repliche di disponibilità dipende dalla modalità di disponibilità di entrambe le repliche.The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. Ad esempio, affinché si verifichi il commit sincrono, sia la replica primaria corrente sia la replica secondaria in questione devono essere configurate per il commit sincrono.For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. Analogamente, affinché il failover venga eseguito automaticamente, entrambe le repliche devono essere configurate per il failover automatico.Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Il comportamento per lo scenario di distribuzione illustrato sopra può pertanto essere riepilogato nella tabella seguente in cui viene esaminato il comportamento con ogni potenziale replica primaria:Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

Replica primaria correnteCurrent Primary Replica Destinazioni di failover automaticoAutomatic Failover Targets Comportamento in modalità con commit sincrono conSynchronous-Commit Mode Behavior With Comportamento in modalità con commit asincrono conAsynchronous-Commit Mode Behavior With Failover automatico possibileAutomatic failover possible
0101 0202 02 e 0302 and 03 0404 Yes
0202 0101 01 e 0301 and 03 0404 Yes
0303 01 e 0201 and 02 0404 NoNo
0404 01, 02 e 0301, 02, and 03 NoNo

In genere il nodo 04 come replica con commit asincrono viene distribuito in un sito per il ripristino di emergenza.Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. Il fatto che i nodi 01, 02 e 03 rimangano nella modalità con commit asincrono dopo il failover al nodo 04 contribuisce ad evitare possibili cali delle prestazioni nel gruppo di disponibilità dovute all'elevata latenza di rete tra i due siti.The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability Mode Asynchronous-Commit Availability Mode

Nella modalità con commit asincronola replica secondaria non viene mai sincronizzata con la replica primaria.Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Anche se un determinato database secondario potrebbe essere aggiornato in base al database primario corrispondente, è possibile che un qualsiasi database secondario presenti un ritardo in qualsiasi momento.Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. La modalità con commit asincrono può essere utile in uno scenario di ripristino di emergenza in cui la distanza tra replica primaria e replica secondaria è significativa e in cui si desidera evitare che piccoli errori abbiano un impatto sulla replica primaria oppure in situazioni in cui le prestazioni sono più importanti della protezione dei dati sincronizzati.Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in or situations where performance is more important than synchronized data protection. Poiché inoltre la replica primaria non attende acknowledgement dalla replica secondaria, problemi nella replica secondaria non hanno mai un impatto sulla replica primaria.Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

Tramite una replica secondaria con commit asincrono viene effettuato il tentativo di rimanere aggiornata con i record del log ricevuti dalla replica primaria.An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. I database secondari con commit asincrono, tuttavia, rimangono sempre non sincronizzati ed è probabile che presentino un certo ritardo rispetto ai database primari corrispondenti.But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. In genere, il gap tra un database secondario con commit asincrono e il database primario corrispondente è limitato,Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. ma può diventare significativo in caso di overload del server in cui è ospitata la replica secondaria o se la rete è lenta.But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

L'unica forma di failover supportata dalla modalità con commit asincrono è il failover forzato (con possibile perdita di dati).The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Il failover forzato deve essere usato come ultima risorsa solo per le situazioni in cui la replica primaria corrente non sarà disponibile per un lungo periodo di tempo e la disponibilità immediata dei database primari risulti prioritaria rispetto al rischio di una possibile perdita di dati. La destinazione del failover deve essere una replica il cui stato del ruolo deve essere SECONDARY o RESOLVING.Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. La destinazione del failover assume il ruolo primario e le relative copie dei database diventano il database primario.The failover target transitions to the primary role, and its copies of the databases become the primary database. Tutti i database secondari rimanenti, insieme ai database primari precedenti, non appena diventano disponibili, vengono sospesi finché non vengono ripresi singolarmente manualmente.Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. Nella modalità con commit asincrono tutti i log delle transazioni non ancora inviati dalla replica primaria originale alla replica secondaria precedente vanno persi.Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. Ciò significa che in alcuni o in tutti i nuovi database primari potrebbero mancare alcune transazioni di cui è stato eseguito il commit di recente.This means that some or all of the new primary databases might be lacking recently committed transactions. Per altre informazioni sul funzionamento del failover forzato e sulle procedure consigliate per il relativo uso, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability Mode Synchronous-Commit Availability Mode

In modalità di disponibilità con commit sincrono (modalità con commit sincrono), dopo la creazione di un join a un gruppo di disponibilità, un database secondario viene aggiornato rispetto al database primario corrispondente e viene impostato sullo stato SYNCHRONIZED.Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. Il database secondario rimane SYNCHRONIZED finché la sincronizzazione dei dati continua.The secondary database remains SYNCHRONIZED as long as data synchronization continues. In questo modo, si assicura che ogni transazione sottoposta a commit in un database primario lo sia anche nel database secondario corrispondente.This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. Una volta che tutti i database secondari in una determinata replica secondaria sono sincronizzati, lo stato di integrità della sincronizzazione della replica secondaria nel suo complesso è HEALTHY.When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

Contenuto della sezioneIn This Section:

Fattori che causano l'interruzione della sincronizzazione dei dati Factors That Disrupt Data Synchronization

Una volta che tutti i relativi database sono sincronizzati, una replica secondaria viene impostata sullo stato HEALTHY.Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. La replica secondaria sincronizzata rimane integra finché non si verifica uno degli eventi seguenti:The synchronized secondary replica will remain healthy unless one of the following occurs:

  • Un ritardo o un problema della rete o del computer comporta il timeout della sessione tra la replica secondaria e quella primaria.A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    Nota

    Per informazioni sulla proprietà relativa al periodo di timeout delle sessioni delle repliche di disponibilità, vedere Panoramica di gruppi di disponibilità AlwaysOn (SQL Server).For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • Si sospende un database secondario nella replica secondaria.You suspend a secondary database on the secondary replica. La replica secondaria non è più sincronizzata e il relativo stato di integrità della sincronizzazione viene contrassegnato come NOT_HEALTHY.The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. La replica secondaria non può diventare di nuovo integra finché il database secondario sospeso non verrà ripreso e risincronizzato o rimosso dal gruppo di disponibilità.the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • Si aggiunge un database primario al gruppo di disponibilità.You add a primary database the availability group. Le repliche secondarie precedentemente sincronizzate vengono impostate sullo stato di integrità della sincronizzazione NOT_HEALTHY.Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. Con questo stato viene indicato che almeno un database si trova nello stato NOT SYNCHRONIZING.This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. Una determinata replica secondaria non può essere integra finché un database secondario corrispondente non viene preparato nella replica, non ne viene creato un join al gruppo di disponibilità e non diventa sincronizzato con il nuovo database primario.A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.

  • Si modifica la replica primaria o secondaria in modalità di disponibilità con commit asincrono.You change the primary replica or the secondary replica to asynchronous-commit availability mode. Dopo essere stata impostata sulla modalità con commit asincrono, la replica secondaria rimarrà nello stato di integrità della sincronizzazione HEALTHY finché la sincronizzazione dei dati continua.After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. Tuttavia, se viene impostata sulla modalità con commit asincrono solo la replica primaria, la replica secondaria con commit sincrono verrà impostata sullo stato di integrità della sincronizzazione PARTIALLY_HEALTHY.However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. Con questo stato viene indicato che almeno un database si trova nello stato SYNCHRONIZING, ma nessuno dei database si trova nello stato SYNCHRONIZING.This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.

  • Si modifica una qualsiasi replica secondaria impostando la modalità di disponibilità con commit sincrono.You change any secondary replica to synchronous-commit availability mode. In questo modo, lo stato di integrità della sincronizzazione della replica secondaria diventa PARTIALLY_HEALTHYThis causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. finché tutti i relativi database sono nello stato SYNCHRONIZED.until all of its databases are in the SYNCHRONIZED synchronization state.

Suggerimento

Per visualizzare l'integrità della sincronizzazione di un gruppo di disponibilità, di una replica di disponibilità o di un database di disponibilità, eseguire una query sulla colonna synchronization_health o synchronization_health_desc di sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_stateso sys.dm_hadr_database_replica_statesrispettivamente.To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

Funzionamento della sincronizzazione in una replica secondaria How Synchronization Works on a Secondary Replica

In modalità con commit sincrono, dopo che una replica secondaria è stata unita in join al gruppo di disponibilità ed è stata stabilita una sessione con la replica primaria, la replica secondaria scrive i record del log in entrata su disco (finalizza il log) e invia un messaggio di conferma alla replica primaria.Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. Una volta che il log finalizzato nel database secondario viene aggiornato rispetto alla fine del log nel database primario, lo stato del database secondario viene impostato su SYNCHRONIZED.Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. Il tempo necessario per la sincronizzazione dipende essenzialmente dal ritardo del database secondario rispetto al database primario al momento dell'avvio della sessione (misurato in base al numero di record del log ricevuti inizialmente dalla replica primaria), dal carico di lavoro nel database primario e dalla velocità del computer dell'istanza del server che ospita la replica secondaria.The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

Il funzionamento sincrono viene mantenuto nel modo seguente:Synchronous operation is maintained in the following manner:

  1. Durante la ricezione di una transazione da un client, tramite la replica primaria viene scritto il log per la transazione nel relativo log e, contemporaneamente, viene inviato il record del log alle repliche secondarie.On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.

  2. Una volta che un record del log viene scritto nel log delle transazioni del database primario, la transazione può essere annullata solo se in questa fase si verifica un failover su un database secondario che non ha ricevuto il log.Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. Tramite la replica primaria si attende la conferma dalla replica secondaria con commit sincrono.The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. Mediante la replica secondaria viene finalizzato il log e restituito un acknowledgement alla replica primaria.The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. Quando si riceve la conferma dalla replica secondaria, tramite la replica primaria viene completata l'elaborazione del commit e viene inviato un messaggio di conferma al client.On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    Nota

    Se si verifica il timeout di una replica secondaria con commit sincrono senza conferma della finalizzazione del log, la replica secondaria viene contrassegnata con errore da quella primaria.If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. Lo stato di connessione della replica secondaria viene impostato su DISCONNECTED e non viene più attesa la conferma della replica secondaria da parte di quella primaria.The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. Questo comportamento assicura che una replica secondaria con commit sincrono in cui si sono verificati errori non impedisca la finalizzazione del log delle transazioni nella replica primaria.This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

    Con la modalità con commit sincrono è possibile proteggere i dati richiedendone la sincronizzazione tra due posizioni, ma con un aumento della latenza delle transazioni.Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

Modalità con commit sincrono con solo failover manuale Synchronous-Commit Mode with Only Manual Failover

Se queste repliche sono connesse e il database è sincronizzato, il failover manuale è supportato.When these replicas are connected and the database is synchronized, manual failover is supported. Se la replica secondaria diventa inattiva, la replica primaria non viene influenzata.If the secondary replica goes down, the primary replica is unaffected. La replica primaria viene eseguita con esposizione se non è presente alcuna replica con stato SYNCHRONIZED, cioè non vengono inviati dati a una qualsiasi replica secondaria.The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). In caso di perdita della replica primaria, le repliche secondarie vengono impostate sullo stato RESOLVING, ma il proprietario del database può forzare un failover sulla replica secondaria (con possibile perdita di dati).If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). Per altre informazioni, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For more information, see Failover and Failover Modes (Always On Availability Groups).

Modalità commit sincrono con failover automatico Synchronous-Commit Mode with Automatic Failover

Con il failover automatico si garantisce disponibilità elevata assicurando che il database diventi di nuovo disponibile rapidamente dopo la perdita della replica primaria.Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. Per configurare un gruppo di disponibilità per il failover automatico, è necessario impostare la replica primaria corrente e almeno una replica secondaria sulla modalità con commit sincrono con failover automatico.To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. Si possono avere fino a tre repliche di failover automatico.You can have up to three automatic failover replicas.

Inoltre, affinché un failover automatico sia possibile in un momento specifico, questa replica secondaria deve essere sincronizzata con la replica primaria (cioè tutti i database secondari sono sincronizzati) e per il cluster WSFC (Windows Server Failover Clustering) deve essere disponibile un quorum.Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. Se la replica primaria non è disponibile in presenza di tali condizioni, si verifica il failover automatico.If the primary replica becomes unavailable under these conditions, automatic failover occurs. La replica secondaria assume il ruolo di replica primaria e il relativo database diventa il database primario.The secondary replica switches to the role of primary, and it offers its database as the primary database. Per altre informazioni, vedere la sezione "Failover automatico" dell'argomento Failover e modalità di failover (gruppi di disponibilità AlwaysOn).For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

Nota

Per informazioni sul quorum WSFC e Gruppi di disponibilità Always OnAlways On availability groups, vedere Modalità quorum WSFC e configurazione del voto (SQL Server).For information about WSFC quorum and Gruppi di disponibilità Always OnAlways On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Per modificare la modalità di disponibilità e failoverTo change the availability mode and failover mode

Vedere ancheSee Also

Panoramica di gruppi di disponibilità AlwaysOn (SQL Server) Overview of Always On Availability Groups (SQL Server)
Failover e modalità di failover (gruppi di disponibilità AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Windows Server Failover Clustering (WSFC) con SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server