Modes de disponibilité (Groupes de disponibilité Always On)Availability Modes (Always On Availability Groups)

Cette rubrique s’applique à : OuiSQL Serveraucunbase de données SQL AzureaucunAzure SQL Data Warehouse aucun Parallel Data WarehouseTHIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Dans Groupes de disponibilité Always OnAlways On availability groups, le mode de disponibilité est une propriété de réplica qui détermine si un réplica de disponibilité donné peut fonctionner en mode de validation synchrone.In Groupes de 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. Pour chaque réplica de disponibilité, le mode de disponibilité doit être configuré pour le mode de validation synchrone, pour le mode de validation asynchrone ou pour le mode de configuration uniquement.For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. Si le réplica principal est configuré pour le mode de validation asynchrone, il n’attend pas que le réplica secondaire écrive des enregistrements dans le journal des transactions entrantes sur le disque (pour renforcer le journal).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). Si un réplica secondaire donné est configuré en mode de validation asynchrone, le réplica principal n'attend pas que ce réplica secondaire renforce le journal.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. Si le réplica principal et un réplica secondaire donné sont configurés pour le mode de validation synchrone, le réplica principal attend que le réplica secondaire confirme qu’il a renforcé le journal (sauf si le réplica secondaire n’envoie pas de commande ping au réplica principal pendant la période d’expiration de sessiondu réplica principal).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).

Note

Si la période d'expiration de session du réplica principal est dépassée par un réplica secondaire, le réplica principal passe temporairement en mode de validation asynchrone pour ce réplica secondaire.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. Lorsque le réplica secondaire se reconnecte au réplica principal, ils reprennent le mode de validation synchrone.When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Dans cette rubrique :In this Topic:

Modes de disponibilité pris en chargeSupported Availability Modes

Groupes de disponibilité Always OnAlways On availability groups prend en charge deux modes de disponibilité : le mode avec validation asynchrone et le mode avec validation synchrone, comme suit : supports two availability modes—asynchronous-commit mode and synchronous-commit mode, as follows:

  • Lemode avec validation asynchrone est une solution de récupération d’urgence qui fonctionne bien quand les réplicas de disponibilité sont séparés par des distances considérables.Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. Si chaque réplica secondaire s'exécute en mode avec validation asynchrone, le réplica principal n'attend pas que les réplicas secondaires renforcent le journal.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. En revanche, immédiatement après l'écriture d'un enregistrement de journal dans le journal local, le réplica principal envoie une confirmation de transaction au client.Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. Le réplica principal s'exécute avec une latence de transaction minimale par rapport à un réplica secondaire configuré pour le mode avec validation asynchrone.The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. Si le serveur principal actuel est configuré pour le mode de disponibilité avec validation asynchrone, il valide les transactions de façon asynchrone pour tous les réplicas secondaires, indépendamment de leurs paramètres de mode de 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.

    Pour plus d’informations, consultez Mode de disponibilité avec validation asynchroneplus loin dans cette rubrique.For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • Lemode avec validation synchrone privilégie la haute disponibilité par rapport aux performances, mais au prix d’une latence accrue des transactions.Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. En mode avec validation synchrone, les transactions attendent que le réplica secondaire ait renforcé le journal sur le disque avant d'envoyer la confirmation de transaction au client.Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. Lorsque la synchronisation des données démarre sur une base de données secondaire, le réplica secondaire commence à appliquer les enregistrements de journal entrants à partir de la base de données primaire correspondante.When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. Dès que tous les enregistrements de journal sont renforcés, la base de données secondaire passe à l'état SYNCHRONIZED.As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. Ensuite, chaque nouvelle transaction est renforcée par le réplica secondaire avant que l'enregistrement du journal soit écrit dans le journal local.Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. Lorsque toutes les bases de données secondaires d'un réplica secondaire sont synchronisées, le mode avec validation synchrone prend en charge le basculement manuel et, éventuellement, le basculement automatique.When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    Pour plus d’informations, consultez Mode de disponibilité avec validation synchroneplus loin dans cette rubrique.For more information, see Synchronous-Commit Availability Mode, later in this topic.

  • Le mode de configuration uniquement s’applique aux groupes de disponibilité qui ne sont pas sur un cluster de basculement Windows Server.Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. Un réplica en mode de configuration uniquement ne contient pas de données utilisateur.A replica in configuration only mode does not contain user data. En mode de configuration uniquement, la base de données master du réplica stocke les métadonnées de configuration du groupe de disponibilité.In configuration only mode, the replica master database stores availability group configuration metadata. Pour plus d’informations, consultez Groupe de disponibilité avec réplica en mode de configuration uniquement.For more information see Availability group with configuration only replica.

    L'illustration suivante montre un groupe de disponibilité avec cinq réplicas de disponibilité.The following illustration shows an availability group with five availability replicas. Le réplica principal et un réplica secondaire sont configurés pour le mode avec validation synchrone et basculement automatique.The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Un autre réplica secondaire est configuré pour le mode avec validation synchrone pour un basculement manuel planifié uniquement, et deux réplicas secondaires sont configurés pour le mode avec validation asynchrone qui prend en charge uniquement le basculement manuel forcé (généralement appelé basculement forcé).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).

    Modes de disponibilité et de basculement des réplicasAvailability and failover modes of replicas

    Le comportement de synchronisation et de basculement entre deux réplicas de disponibilité dépend du mode de disponibilité des deux réplicas.The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. Par exemple, pour qu'une validation synchrone se produise, le réplica principal actuel et le réplica secondaire doivent tous deux être configurés pour la validation synchrone.For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. De même, pour qu'un basculement automatique se produise, les deux réplicas doivent être configurés pour le basculement automatique.Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Par conséquent, le comportement du scénario de déploiement illustré ci-dessus peut être résumé dans le tableau suivant, qui explore le comportement de chaque réplica principal potentiel :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:

Réplica principal actuelCurrent Primary Replica Cibles de basculement automatiqueAutomatic Failover Targets Mode avec validation synchrone etSynchronous-Commit Mode Behavior With Mode avec validation asynchrone etAsynchronous-Commit Mode Behavior With Basculement automatique possibleAutomatic failover possible
0101 0202 02 et 0302 and 03 0404 OuiYes
0202 0101 01 et 0301 and 03 0404 OuiYes
0303 01 et 0201 and 02 0404 NonNo
0404 01, 02 et 0301, 02, and 03 NonNo

En général, le nœud 04 (réplica avec validation asynchrone), est déployé dans un site de récupération d'urgence.Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. Le fait que les nœuds 01, 02 et 03 demeurent en mode de validation asynchrone après avoir basculé vers le nœud 04 empêche une dégradation des performances potentielle dans votre groupe de disponibilité en raison de temps de réponse du réseau élevé entre les deux sites.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 ModeAsynchronous-Commit Availability Mode

En mode avec validation asynchrone, le réplica secondaire n’est jamais synchronisé avec le réplica principal.Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Bien qu'une base de données secondaire donnée puisse rattraper la base de données principale correspondante, n'importe quelle base de données secondaire peut être en décalage à tout moment.Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. Le mode avec validation asynchrone peut être utile dans un scénario de récupération d'urgence, lorsque le réplica principal et le réplica secondaire sont séparés par une distance significative et lorsque vous ne souhaitez pas que de petites erreurs aient un impact sur le réplica principal, ou bien dans des situations où les performances sont plus importantes que la protection des données synchronisées.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. En outre, étant donné que le réplica principal n'attend pas les accusés de réception du réplica secondaire, les problèmes survenant sur ce réplica secondaire n'affectent jamais le réplica principal.Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

Un réplica secondaire avec validation asynchrone tente de suivre les enregistrements de journal reçus du réplica principal.An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. Cependant, en mode avec validation asynchrone, les bases de données secondaires ne sont jamais synchronisées et peuvent rester derrière les bases de données principales correspondantes.But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. Généralement, l'intervalle entre une base de données secondaire avec validation asynchrone et la base de données primaire correspondante est faible.Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. Mais l'intervalle peut devenir substantiel si le serveur qui héberge le réplica secondaire est surchargé ou si le réseau est lent.But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

La seule forme de basculement prise en charge par le mode avec validation asynchrone est le basculement forcé (avec perte de données possible).The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Le basculement forcé est un dernier recours adapté uniquement aux situations dans lesquelles le réplica principal reste indisponible pendant une période prolongée et la disponibilité immédiate des bases de données primaires est plus importante que le risque de perte de données. La cible de basculement doit être un réplica dont le rôle est dans l’état SECONDARY ou 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 cible de basculement passe dans le rôle principal et ses copies de bases de données deviennent la base de données primaire.The failover target transitions to the primary role, and its copies of the databases become the primary database. Toutes les bases de données secondaires restantes, avec les bases de données primaires précédentes, une fois qu'elles sont disponibles, sont interrompues jusqu'à ce que vous les repreniez manuellement et individuellement.Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. En mode de validation asynchrone, tous les journaux des transactions que le réplica principal d'origine n'avait pas envoyés à l'ancien réplica secondaire sont perdus.Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. Cela signifie que les transactions validées récemment peuvent manquer dans certaines ou toutes les nouvelles bases de données principales.This means that some or all of the new primary databases might be lacking recently committed transactions. Pour plus d’informations sur le basculement forcé et sur les bonnes pratiques pour son utilisation, consultez Basculement et modes de basculement (groupes de disponibilité Always On).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 ModeSynchronous-Commit Availability Mode

En mode de disponibilité avec validation synchrone (mode avec validation synchrone), quand on l’attache à un groupe de disponibilité, une base de données secondaire rattrape la base de données primaire correspondante et passe à l’état 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. La base de données secondaire reste à l'état SYNCHRONIZED tant que la synchronisation des données continue.The secondary database remains SYNCHRONIZED as long as data synchronization continues. Cela garantit que chaque transaction validée sur une base de données primaire donnée a également été validée sur la base de données secondaire correspondante.This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. Lorsque chaque base de données secondaire sur un réplica secondaire donné est synchronisée, l'état synchronization_health de l'ensemble du réplica secondaire est 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.

Dans cette section :In This Section:

Facteurs qui perturbent la synchronisation des donnéesFactors That Disrupt Data Synchronization

Une fois que toutes ses bases de données sont synchronisées, un réplica secondaire passe à l'état HEALTHY.Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. Le réplica secondaire synchronisé restera intègre sauf si l'un des événements suivants se produit :The synchronized secondary replica will remain healthy unless one of the following occurs:

  • Un délai de réseau ou d'ordinateur, ou un autre problème, entraîne l'expiration du délai d'attente de la session entre le réplica secondaire et le réplica principal.A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    Note

    Pour plus d’informations sur la propriété session-time des réplicas de disponibilité, consultez Vue d’ensemble des groupes de disponibilité Always On (SQL Server).For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • Vous suspendez une base de données secondaire sur le réplica secondaire.You suspend a secondary database on the secondary replica. Le réplica secondaire cesse d'être synchronisé et son état synchronization-health est marqué comme NOT_HEALTHY.The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. Le réplica secondaire ne peut pas redevenir intègre tant que la base de données secondaire suspendue n'est pas reprise et resynchronisée ou bien n'est pas supprimée du groupe de disponibilité.the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • Vous ajoutez une base de données primaire au groupe de disponibilité.You add a primary database the availability group. Les réplicas secondaires précédemment synchronisés passent à l'état synchronization-health NOT_HEALTHY.Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. Cet état indique qu'au moins une base de données est à l'état de synchronisation NOT SYNCHRONIZING.This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. Un réplica secondaire donné ne peut pas redevenir HEALTHY tant qu'une base de données secondaire correspondante n'a pas été préparée sur le réplica, associée au groupe de disponibilité et synchronisée avec la nouvelle base de données primaire.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.

  • Vous modifiez le réplica principal ou le réplica secondaire en mode de disponibilité avec validation asynchrone.You change the primary replica or the secondary replica to asynchronous-commit availability mode. Après le passage en mode avec validation asynchrone, le réplica secondaire reste à l'état synchronization-health HEALTHY tant que la synchronisation des données continue.After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. Toutefois, si seul le réplica principal est passé en mode avec validation asynchrone, le réplica secondaire avec validation synchrone passera à l'état synchronization-health 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. Cet état indique qu'au moins une base de données est à l'état de synchronisation SYNCHRONIZING, mais qu'aucune base de données est à l'état NOT 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.

  • Vous modifiez un réplica principal en mode de disponibilité avec validation synchrone.You change any secondary replica to synchronous-commit availability mode. Le réplica secondaire est par conséquent marqué comme étant à l'état synchronization-health PARTIALLY_HEALTHYThis causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. tant que toutes ses bases de données sont à l'état de synchronisation SYNCHRONIZED.until all of its databases are in the SYNCHRONIZED synchronization state.

Conseil

Pour afficher l’intégrité de synchronisation d’un groupe de disponibilité, d’un réplica de disponibilité ou d’une base de données de disponibilité, interrogez respectivement la colonne synchronization_health ou synchronization_health_desc column de sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_statesou sys.dm_hadr_database_replica_states.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.

Fonctionnement de la synchronisation sur un réplica secondaireHow Synchronization Works on a Secondary Replica

En mode avec validation synchrone, une fois qu’un réplica secondaire est attaché au groupe de disponibilité et a établi une session avec le réplica principal, il écrit les enregistrements de journal entrants sur le disque (renforcement du journal) et envoie un message de confirmation au réplica principal.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. Une fois que le journal renforcé sur la base de données secondaire a rattrapé la fin du journal de la base de données primaire, l'état de la base de données secondaire est défini sur 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. Le temps nécessaire à la synchronisation dépend essentiellement du décalage de la base de données secondaire par rapport à la base de données principale au début de la session (ce qui se mesure par le nombre d'enregistrements du journal initialement reçus du réplica principal), de la charge de travail sur la base de données principale et de la vitesse de l'ordinateur de l'instance de serveur qui héberge le réplica secondaire.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.

L'opération se déroule de la manière suivante :Synchronous operation is maintained in the following manner:

  1. À la réception d'une transaction d'un client, le réplica principal écrit le journal de la transaction dans le journal des transactions et envoie simultanément l'enregistrement du journal aux réplicas secondaires.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. Une fois qu'un enregistrement est écrit dans le journal des transactions de la base de données primaire, la transaction peut être annulée uniquement en cas de basculement à ce stade sur un secondaire qui n'a pas reçu l'enregistrement.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. Le réplica principal attend la confirmation du ou des réplicas secondaires avec validation synchrone.The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. Le réplica secondaire renforce le journal et retourne un accusé de réception au réplica principal.The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. Dès qu'il reçoit la confirmation du réplica secondaire, le réplica principal termine le traitement de la validation et envoie un message de confirmation au client.On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    Note

    Si un réplica secondaire avec validation synchrone expire sans avoir confirmé qu'il a renforcé le journal, le réplica principal marque ce réplica secondaire comme étant en échec.If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. L'état connecté du réplica secondaire passe à DISCONNECTED et le réplica principal cesse d'attendre la confirmation du réplica secondaire.The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. Ce comportement garantit qu'un réplica secondaire avec validation synchrone n'empêche pas le renforcement du journal des transactions sur le réplica principal.This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

    Le mode avec validation synchrone protège vos données en exigeant que celles-ci soient synchronisées entre deux emplacements, quitte à augmenter un peu la latence de la transaction.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.

Mode avec validation synchrone et basculement manuel uniquementSynchronous-Commit Mode with Only Manual Failover

Lorsque ces réplicas sont connectés et la base de données est synchronisés, le basculement manuel est pris en charge.When these replicas are connected and the database is synchronized, manual failover is supported. Si le réplica secondaire s'arrête, le réplica principal n'est pas affecté.If the secondary replica goes down, the primary replica is unaffected. Le réplica principal est exposé si aucun réplica SYNCHRONIZED n'existe (autrement dit, s'il n'envoie de données à aucun réplica secondaire).The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). Si le réplica principal est perdu, les réplicas secondaires passent à l'état RESOLVING, mais le propriétaire de la base de données peut forcer un basculement vers le réplica secondaire (avec perte de données possible).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). Pour plus d’informations, consultez Basculement et modes de basculement (groupes de disponibilité Always On).For more information, see Failover and Failover Modes (Always On Availability Groups).

Mode avec validation synchrone et basculement automatiqueSynchronous-Commit Mode with Automatic Failover

Le basculement automatique offre une haute disponibilité et garantit que la base de données redevient rapidement disponible après la perte du réplica principal.Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. Pour configurer le basculement automatique d’un groupe de disponibilité, vous devez définir le réplica principal actuel et au moins un réplica secondaire en mode de validation synchrone avec basculement automatique.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. Vous pouvez configurer jusqu’à trois réplicas de basculement automatique.You can have up to three automatic failover replicas.

En outre, pour qu'un basculement automatique soit possible à tout moment, ce réplica secondaire doit être synchronisé avec le réplica principal (autrement dit, toutes les bases de données secondaires doivent être synchronisées) et le cluster de basculement Windows Server (WSFC) doit avoir le 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. Si le réplica principal devient indisponible dans ces conditions, il y a basculement automatique.If the primary replica becomes unavailable under these conditions, automatic failover occurs. Le réplica secondaire bascule dans le rôle de principal et propose sa base de données comme base de données primaire.The secondary replica switches to the role of primary, and it offers its database as the primary database. Pour plus d’informations consultez la section « Basculement automatique » de la rubrique Basculement et modes de basculement (groupes de disponibilité Always On).For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

Note

Pour plus d’informations sur le quorum WSFC et Groupes de disponibilité Always OnAlways On availability groups, consultez Modes de quorum WSFC et configuration de vote (SQL Server).For information about WSFC quorum and Groupes de disponibilité Always OnAlways On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Tâches associéesRelated Tasks

Pour modifier le mode de disponibilité et de basculementTo change the availability mode and failover mode

Contenu connexeRelated Content

Voir aussiSee Also

Vue d’ensemble des groupes de disponibilité Always On (SQL Server) Overview of Always On Availability Groups (SQL Server)
Basculement et modes de basculement (Groupes de disponibilité AlwaysOn) Failover and Failover Modes (Always On Availability Groups)
Clustering de basculement Windows Server (WSFC) avec SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server