Partager via

Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server)

Cette rubrique présente les concepts des groupes de disponibilité Always On qui sont centraux pour la configuration et la gestion d’un ou plusieurs groupes de disponibilité dans SQL Server 2014. Pour obtenir un résumé des avantages offerts par les groupes de disponibilité et une vue d’ensemble de la terminologie des groupes de disponibilité Always On, consultez Groupes de disponibilité AlwaysOn (SQL Server).

Un groupe de disponibilité prend en charge un environnement de basculement pour un ensemble discret de bases de données utilisateur, appelées bases de données de disponibilité, qui basculent de concert. Un groupe de disponibilité prend en charge un ensemble de bases de données primaires et un à huit ensembles de bases de données secondaires correspondantes. Les bases de données secondaires ne sont pas des sauvegardes. Continuez à sauvegarder vos bases de données et leurs journaux de transactions régulièrement.

Conseil / Astuce

Vous pouvez créer n'importe quel type de sauvegarde d'une base de données primaire. Vous pouvez également créer des sauvegardes de journaux et des sauvegardes complètes de copie uniquement des bases de données secondaires. Pour plus d'informations, consultez Secondaires actifs : Sauvegarde sur les réplicas secondaires (Groupes de disponibilité AlwaysOn).

Chaque ensemble de bases de données de disponibilité est hébergé par un réplica de disponibilité. Il existe deux types de répliques de haute disponibilité : un réplica principal unique. qui héberge les bases de données principales, et un à huit réplicas secondaires, chacun héberge un ensemble de bases de données secondaires et sert de cibles de basculement potentielles pour le groupe de disponibilité. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Un réplica de disponibilité fournit une redondance uniquement au niveau de la base de données pour l’ensemble de bases de données d’un groupe de disponibilité. Les basculements ne sont pas causés par des problèmes de base de données tels qu’une base de données devenant suspecte en raison d’une perte d’un fichier de données ou d’une altération d’un journal des transactions.

Le réplica principal rend les bases de données primaires disponibles pour les connexions en lecture-écriture à partir des clients. En outre, dans un processus appelé synchronisation de données, qui se produit au niveau de la base de données. Le réplica principal envoie les enregistrements du journal des transactions de chaque base de données primaire à chaque base de données secondaire. Chaque réplica secondaire met en cache les enregistrements du journal des transactions (renforce le journal) puis les applique à sa base de données secondaire correspondante. La synchronisation des données se produit entre la base de données primaire et chaque base de données secondaire connectée, indépendamment des autres bases de données. Par conséquent, une base de données secondaire peut être interrompue ou échouer sans affecter d'autres bases de données secondaires, et une base de données primaire peut être annulée ou échouer sans affecter d'autres bases de données primaires.

Éventuellement, vous pouvez configurer un ou plusieurs réplicas secondaires pour prendre en charge l'accès en lecture seule aux bases de données secondaires, et vous pouvez configurer tout réplica secondaire pour permettre des sauvegardes sur des bases de données secondaires.

Le déploiement de groupes de disponibilité Always On nécessite un cluster WSFC (Windows Server Failover Clustering). Chaque réplica de disponibilité d’un groupe de disponibilité donné doit résider sur un nœud différent du même cluster WSFC. La seule exception survient lors de la migration vers un autre cluster WSFC : un groupe de disponibilité peut temporairement chevaucher deux clusters.

Un groupe de ressources WSFC est créé pour chaque groupe de disponibilité que vous créez. Le cluster WSFC surveille ce groupe de ressources pour évaluer l’intégrité du réplica principal. Le quorum pour les groupes de disponibilité Always On est déterminé par tous les nœuds du cluster WSFC, indépendamment du fait qu'un nœud donné héberge ou non des réplicas de disponibilité. Contrairement à la mise en miroir de bases de données, il n’existe aucun rôle témoin dans les groupes de disponibilité Always On.

Remarque

Pour plus d’informations sur la relation des composants SQL Server AlwaysOn au cluster WSFC, consultez le clustering de basculement Windows Server (WSFC) avec SQL Server.

L'illustration suivante montre un groupe de disponibilité qui contient un réplica principal et quatre réplicas secondaires. Jusqu’à huit réplicas secondaires sont pris en charge, y compris un réplica principal et deux réplicas secondaires de validation synchrone.

Groupe de disponibilité avec cinq répliques Groupe de

Bases de données de disponibilité

Pour ajouter une base de données à un groupe de disponibilité, la base de données doit être une base de données en ligne en lecture-écriture qui existe sur l'instance de serveur qui héberge le réplica principal. Lorsque vous ajoutez une base de données, elle joint le groupe de disponibilité comme base de données primaire, tout en restant disponible aux clients. Il n'existe aucune base de données secondaire correspondante jusqu'à ce que les sauvegardes de la nouvelle base de données primaire soient restaurées dans l'instance de serveur qui héberge le réplica secondaire (avec RESTORE WITH NORECOVERY). La nouvelle base de données secondaire est dans l’état RESTORING jusqu’à ce qu’elle soit jointe au groupe de disponibilité. Pour plus d’informations, consultez Démarrer le déplacement des données sur une base de données secondaire AlwaysOn (SQL Server).

Une jointure place la base de données secondaire dans l'état ONLINE et démarre la synchronisation des données avec la base de données primaire correspondante. Lasynchronisation des données correspond au processus selon lequel les modifications apportées à une base de données primaire sont reproduites sur une base de données secondaire. La synchronisation des données implique l'envoi par la base de données primaire d'enregistrements de journal des transactions à la base de données secondaire.

Important

Une base de données de disponibilité est parfois appelée réplica de base de données dans Transact-SQL, PowerShell et les noms SMO (SQL Server Management Objects). Par exemple, le terme « réplica de base de données » est utilisé dans les noms des vues de gestion dynamique AlwaysOn qui retournent des informations sur les bases de données de disponibilité : sys.dm_hadr_database_replica_states et sys.dm_hadr_database_replica_cluster_states. Toutefois, dans la documentation en ligne de SQL Server, le terme « réplica » fait généralement référence aux réplicas de disponibilité. Par exemple, les termes « réplica principal » et « réplica secondaire » font toujours référence aux réplicas de disponibilité.

Réplicas de disponibilité

Chaque groupe de disponibilité définit un ensemble de deux partenaires de basculement ou plus, appelés réplicas de disponibilité. Lesréplicas de disponibilité sont des composants du groupe de disponibilité. Chaque réplica de disponibilité héberge une copie des bases de données de disponibilité dans le groupe de disponibilité. Pour un groupe de disponibilité donné, les réplicas de disponibilité doivent être hébergés par des instances distinctes de SQL Server qui résident sur différents nœuds d'un cluster WSFC. Chacune de ces instances de serveur doit être activée pour AlwaysOn.

Une instance donnée ne peut héberger qu'un seul réplica de disponibilité par groupe de disponibilité. Toutefois, chaque instance peut être utilisée pour de nombreux groupes de disponibilité. Une instance donnée peut être une instance autonome ou une instance de cluster de basculement SQL Server (FCI). Si vous avez besoin d'une redondance au niveau serveur, utilisez des instances de cluster de basculement.

Chaque réplica de disponibilité se voit attribuer un rôle initial, soit le rôle principal, soit le rôle secondaire, qui est hérité par les bases de données de disponibilité de ce réplica. Le rôle d'un réplica donné détermine s'il héberge les bases de données en lecture-écriture ou les bases de données en lecture seule. Un réplica, appelé réplica principal, se voit attribuer le rôle principal et héberge les bases de données en lecture-écriture, qui sont appelées bases de données primaires. Au moins un autre réplica, appelé réplica secondaire, se voit attribuer le rôle secondaire. Un réplica secondaire héberge les bases de données en lecture seule, appelées bases de données secondaires.

Remarque

Lorsque le rôle d'un réplica de disponibilité est indéterminé, comme lors d'un basculement, ses bases de données sont temporairement dans un état NOT SYNCHRONIZING. Leur rôle est défini sur RESOLVING jusqu'à ce que le rôle du réplica de disponibilité soit résolu. Si un réplica de disponibilité est résolu en rôle principal, ses bases de données deviennent les bases de données primaires. Si un réplica de disponibilité est résolu en rôle secondaire, ses bases de données deviennent les bases de données secondaires.

Modes de disponibilité

Le mode de disponibilité est une propriété de chaque réplica de disponibilité. Le mode de disponibilité détermine si le réplica principal attend de valider les transactions sur une base de données jusqu'à ce qu'un réplica secondaire donné ait écrit les enregistrements du journal des transactions sur le disque, durcissant ainsi le journal. Les groupes de disponibilité Always On prennent en charge deux modes de disponibilité en mode de validation asynchrone et en mode de validation synchrone.

  • Mode de validation asynchrone

    Un réplica de disponibilité qui utilise ce mode de disponibilité est appeléréplica de validation asynchrone. En mode de validation asynchrone, le réplica principal valide les transactions sans attendre d'accusé de réception confirmant qu'un réplica secondaire avec validation asynchrone a renforcé le journal. Le mode de validation asynchrone réduit la latence de transaction sur les bases de données secondaires, mais leur permet d'être antérieures aux bases de données primaires, ce qui rend possible la perte de données.

  • Mode de validation synchrone

    Un réplica de disponibilité qui utilise ce mode de disponibilité est appelé réplica avec validation synchrone. En mode de validation synchrone, avant de valider des transactions, un réplica principal avec validation synchrone attend qu'un réplica secondaire avec validation synchrone confirme qu'il a terminé le renforcement du journal. Le mode de validation synchrone garantit qu'une fois qu'une base de données secondaire particulière est synchronisée avec la base de données primaire, les transactions validées sont entièrement protégées. Cette protection se fait au prix d'une latence accrue des transactions.

Pour plus d’informations, consultez Modes de disponibilité (groupes de disponibilité AlwaysOn).

Types de basculement

Dans le contexte d'une session entre le réplica principal et un réplica secondaire, les rôles principal et secondaire sont potentiellement interchangeables dans un processus appelé basculement. Pendant un basculement, le réplica secondaire cible passe au rôle principal, devenant le nouveau réplica principal. Le nouveau réplica principal met ses bases de données en ligne comme bases de données primaires, et les applications clientes peuvent se connecter à ces dernières. Lorsque le réplica principal précédent est disponible, il prend le rôle secondaire, en devenant un réplica secondaire. Les bases de données primaires précédentes deviennent les bases de données secondaires et la synchronisation des données reprend.

Il existe trois types de basculement : automatique, manuel et forcé (avec perte de données possible). La ou les formes de basculement prises en charge par un réplica secondaire dépendent de son mode de disponibilité, et en mode de validation synchrone, du mode de basculement sur le réplica principal et le réplica secondaire cible, comme suit.

  • Le mode de validation synchrone prend en charge deux formes de basculement : le basculement manuel planifié et le basculement automatique, si la réplique secondaire cible est actuellement synchronisée avec l’avt1. La prise en charge de ces formes de basculement dépend du paramètre de la propriété de mode de basculement sur les serveurs partenaires de basculement. Si le mode de basculement est défini sur « manuel » sur le réplica principal ou secondaire, seul le basculement manuel est pris en charge pour ce réplica secondaire. Si le mode de basculement est défini sur « automatique » dans les réplicas principal et secondaire, les basculements manuel et automatique sont pris en charge sur ce réplica secondaire.

    • Basculement manuel planifié (sans perte de données)

      Un basculement manuel se produit après qu'un administrateur de base de données a émis une commande de basculement et provoqué la transition d'un réplica secondaire synchronisé vers le rôle principal (avec protection garantie des données) et la transition du réplica principal vers le rôle secondaire. Un basculement manuel nécessite qu'à la fois le réplica principal et le réplica secondaire cible s'exécutent en mode de validation synchrone, le réplica secondaire devant déjà être synchronisé.

    • Basculement automatique (sans perte de données)

      Un basculement automatique se produit en réponse à un échec qui provoque la transition d'un réplica secondaire synchronisé vers le rôle principal (avec protection garantie des données). Lorsque le réplica principal précédent devient disponible, il adopte le rôle secondaire. Le basculement automatique nécessite que la réplique principale et la réplique secondaire cible s’exécutent en mode de validation synchrone avec le mode de basculement défini sur « Automatique ». En outre, le réplica secondaire doit déjà être synchronisé, disposer du quorum WSFC et respecter les conditions spécifiées par la stratégie de basculement flexible du groupe de disponibilité.

      Important

      Les instances de cluster de basculement (FCI) SQL Server ne prennent pas en charge le basculement automatique par les groupes de disponibilité. Par conséquent, tout réplica de disponibilité hébergé par une instance de cluster de basculement ne peut être configuré que pour un basculement manuel.

    Remarque

    Notez que si vous envoyez une commande de basculement forcé sur un réplica secondaire synchronisé, ce réplica se comportera comme lors d'un basculement manuel planifié.

  • En mode de validation asynchrone, la seule forme de basculement est le basculement manuel forcé (avec perte de données possible), généralement appelé basculement forcé. Le basculement forcé est considéré comme une forme de basculement manuel, car il ne peut être initié que manuellement. Le basculement forcé est une option de récupération d'urgence. Il s’agit de la seule forme de basculement possible lorsque le réplica secondaire cible n’est pas synchronisé avec le réplica principal.

Pour plus d’informations, consultez Les modes de basculement et de basculement (groupes de disponibilité AlwaysOn).

Connexions clientes

Vous pouvez fournir la connectivité client au réplica principal d'un groupe de disponibilité donné en créant un écouteur de groupe de disponibilité. Un écouteur de groupe de disponibilité fournit un ensemble de ressources joint à un groupe de disponibilité donné pour diriger les connexions clientes vers le réplica de disponibilité approprié.

Un écouteur de groupe de disponibilité est associé à un nom DNS unique qui sert de nom de réseau virtuel (VNN), une ou plusieurs adresses IP virtuelles (VIP) et un numéro de port TCP. Pour plus d’informations, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server).

Conseil / Astuce

Si un groupe de disponibilité possède seulement deux réplicas de disponibilité et n’est pas configuré pour autoriser l’accès en lecture au réplica secondaire, les clients peuvent se connecter au réplica principal à l’aide d’une chaîne de connexion de mise en miroir de bases de données. Cette approche peut être utile temporairement après la migration d’une base de données de la mise en miroir de bases de données vers des groupes de disponibilité Always On. Avant d’ajouter des réplicas secondaires supplémentaires, vous devez créer un écouteur pour le groupe de disponibilité et mettre à jour vos applications pour utiliser le nom réseau de l’écouteur.

Répliques secondaires actives

Les groupes de disponibilité Always On prennent en charge les réplicas secondaires actifs. Les fonctions secondaires actives prennent en charge les opérations suivantes :

  • Exécution d'opérations de sauvegarde sur des réplicas secondaires

    Les réplicas secondaires prennent en charge l’exécution de sauvegardes de journal et de sauvegardes en copie seule d’une base de données complète, de fichiers ou de groupes de fichiers. Vous pouvez configurer le groupe de disponibilité pour spécifier une préférence concernant l'emplacement où les sauvegardes doivent être effectuées. Il est important de comprendre que la préférence n’est pas appliquée par SQL Server, de sorte qu’elle n’a aucun impact sur les sauvegardes ad hoc. L'interprétation de cette préférence dépend de la logique éventuelle que vous intégrez dans un script dans vos tâches de sauvegarde pour chacune des bases de données d'un groupe de disponibilité donné. Pour un réplica de disponibilité particulier, vous pouvez spécifier la priorité d'exécution des sauvegardes sur ce réplica par rapport aux autres réplicas dans le même groupe de disponibilité. Pour plus d'informations, consultez Secondaires actifs : Sauvegarde sur les réplicas secondaires (Groupes de disponibilité AlwaysOn).

  • Accès en lecture seule à un ou plusieurs réplicas secondaires (réplicas secondaires lisibles)

    Toute réplique de disponibilité peut être configurée pour autoriser l’accès en lecture seule à ses bases de données locales lorsqu'elle remplit le rôle secondaire, bien que certaines opérations ne soient pas totalement prises en charge. En outre, si vous souhaitez empêcher l’exécution des charges de travail en lecture seule sur le réplica principal, vous pouvez configurer les réplicas pour autoriser uniquement l’accès en lecture-écriture lors de l’exécution sous le rôle principal. Pour plus d'informations, consultez secondaires actifs : réplicas secondaires lisibles (groupes de disponibilité AlwaysOn).

    Si un groupe de disponibilité a un écouteur de groupe de disponibilité et un ou plusieurs réplicas secondaires lisibles, SQL Server peut acheminer les demandes de connexion d’intention de lecture vers l’un d’entre eux (routage en lecture seule). Pour plus d’informations, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server).

période Session-Timeout

La période d'expiration de session est une propriété du réplica de disponibilité qui détermine le temps pendant lequel une connexion avec un autre réplica de disponibilité peut rester inactive avant qu'elle soit fermée. Les répliques principales et secondaires se vérifient mutuellement pour signaler qu’elles sont toujours actives. La réception d’un test ping à partir de l’autre réplique pendant le délai d'attente indique que la connexion est toujours ouverte et que les instances de serveur communiquent. À la réception d'un ping, un réplica de disponibilité réinitialise son compteur de période d'expiration de session sur cette connexion.

La période d'expiration de session évite que l'un ou l'autre réplica attendent indéfiniment de recevoir un ping de l'autre réplica. Si aucun ping n'est reçu de l'autre réplica au cours de la période d'expiration de session, le réplica expire. Sa connexion est fermée, et le réplica expiré passe à l'état DISCONNECTED. Même si un réplica déconnecté est configuré pour le mode de validation synchrone, les transactions n’attendront pas que ce réplica se reconnecte et resynchronise.

La période d'expiration de session par défaut pour chaque réplica de disponibilité est de 10 secondes. Cette valeur peut être configurée par l'utilisateur et ne peut être inférieure à 5 secondes. Généralement, le temps d'attente recommandé est de 10 secondes minimum. En définissant une valeur inférieure à 10 secondes, vous permettez qu'un système surchargé déclare à tort un échec.

Remarque

Dans le rôle de résolution, la période d’expiration de session ne s’applique pas, car le ping ne se produit pas.

Réparation de page automatique

Chaque réplica de disponibilité essaie d'effectuer une récupération automatiquement à partir de pages endommagées sur une base de données locale en résolvant certains types d'erreurs qui empêchent la lecture d'une page de données. Si un réplica secondaire ne peut pas lire une page, le réplica demande une nouvelle copie de la page à partir du réplica principal. Si la réplique principale ne peut pas lire une page, elle diffuse une demande pour une nouvelle copie à tous les réplicas secondaires et obtient la page du premier à répondre. Si cette demande aboutit, la page illisible est remplacée par la copie, ce qui permet généralement de résoudre l'erreur.

Pour plus d’informations, consultez La réparation automatique des pages (pour les groupes de disponibilité et la mise en miroir de bases de données)

Tâches associées

Contenu associé

Voir aussi

Modes de disponibilité (groupes de disponibilité AlwaysOn)Basculement et modes de basculement (groupes de disponibilité AlwaysOn)Vue d’ensemble des instructions de Transact-SQL pour les groupes de disponibilité AlwaysOn (SQL Server)Vue d’ensemble des applets de commande PowerShell pour les groupes de disponibilité AlwaysOn (SQL Server)Prise en charge de la haute disponibilité pour les bases de données OLTP In-MemoryPrérequis, restrictions et recommandations pour les groupes de disponibilité AlwaysOn (SQL Server)Création et configuration de groupes de disponibilité (SQL Server)Secondaires actifs : réplicas secondaires lisibles (groupes de disponibilité AlwaysOn)Secondaires actifs : sauvegarde sur réplicas secondaires (groupes de disponibilité AlwaysOn)Écouteurs de groupe de disponibilité, connectivité du client et basculement d’application (SQL Server)

  • Last updated on