Partage via

Qu’est-ce qu’un groupe de disponibilité Always On ?

  • Article

S'applique à : SQL Server

Cet article présente les concepts des groupes de disponibilité Always On essentiels pour configurer et gérer un ou plusieurs groupes de disponibilité dans SQL Server. Pour l’édition Standard, passez en revue Groupes de disponibilité Always On de base pour une base de données unique.

La fonctionnalité Groupes de disponibilité Always On est une solution de haute disponibilité et de récupération d'urgence qui fournit une alternative au niveau de l'entreprise à la mise en miroir de bases de données. Les groupes de disponibilité Always On optimisent la disponibilité d’un ensemble de bases de données utilisateur pour une entreprise. 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 en lecture-écriture et un à huit ensembles de bases de données secondaires correspondantes. Éventuellement, les bases de données secondaires peuvent être rendues disponibles pour l'accès en lecture seule et/ou certaines opérations de sauvegarde.

Avec SQL Server activé par Azure Arc, vous pouvez afficher les groupes de disponibilité dans le portail Azure.

Vue d’ensemble

Un groupe de disponibilité prend en charge un environnement répliqué pour un ensemble discret de bases de données utilisateur, appelées bases de données de disponibilité. Vous pouvez créer un groupe de disponibilité pour avoir un haut niveau de disponibilité ou pour une échelle lecture. Un groupe de disponibilité avec un haut niveau de disponibilité est un groupe de bases de données qui basculent en même temps. Un groupe de disponibilité avec échelle lecture est un groupe de bases de données copiées dans d’autres instances de SQL Server pour une charge de travail en lecture seule. Un groupe de disponibilité prend en charge un ensemble de bases de données principales et de un à huit ensembles de bases de données secondaires correspondantes. Les bases de données secondaires ne sont pas des sauvegardes. Continuez à sauvegarder régulièrement vos bases de données et leurs journaux des transactions.

Conseil

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 Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité.

Chaque ensemble de bases de données de disponibilité est hébergé par un réplica de disponibilité. Il existe deux types de réplicas de disponibilité : un réplica principal qui héberge les bases de données primaires et un à huit réplicas secondaires qui hébergent un ensemble de bases de données secondaires et servent de cibles potentielles d'un basculement du groupe de disponibilité. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Un réplica de disponibilité apporte la redondance uniquement au niveau de la base de données, pour l’ensemble des bases de données d’un groupe de disponibilité. Les basculements ne sont pas dus à des problèmes de base de données, tels qu’une base de données devenue suspecte à la suite de la perte d’un fichier de données ou de l’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. Le réplica principal envoie les enregistrements du journal des transactions de chaque base de données primaire à chaque base de données secondaire. Ce processus (appelé synchronisation des données) se produit au niveau de la base de données. 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.

SQL Server 2017 a introduit deux architectures différentes pour les groupes de disponibilité. Les groupes de disponibilité Always On permettent un haut niveau de disponibilité, la récupération d’urgence et l’équilibrage de l’échelle lecture. Ces groupes de disponibilité nécessitent un gestionnaire de cluster. Dans Windows, la fonctionnalité de clustering de basculement fournit le gestionnaire du cluster. Dans Linux, vous pouvez utiliser Pacemaker. L’autre architecture est un groupe de disponibilité avec échelle lecture. Un groupe de disponibilité avec échelle lecture fournit des réplicas pour les charges de travail en lecture seule, mais pas de haut niveau de disponibilité. Dans un groupe de disponibilité avec échelle de lecture, il n’existe pas de gestionnaire de cluster, car le basculement ne peut pas être automatique.

Le déploiement de Groupes de disponibilité Always On pour une haute disponibilité sur Windows nécessite un cluster de basculement Windows Server (WSFC). 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.

Remarque

Pour plus d’informations sur les groupes de disponibilité sur Linux, consultez Groupes de disponibilité pour SQL Server sur Linux.

Dans une configuration à haut niveau de disponibilité, un rôle de cluster est créé pour chaque groupe de disponibilité que vous créez. Le cluster WSFC surveille ce rôle pour évaluer l'intégrité du réplica principal. Le quorum pour Groupes de disponibilité Always On est basé sur tous les nœuds du cluster WSFC, indépendamment du fait qu'un nœud de cluster donné héberge des réplicas de disponibilité. Contrairement à la mise en miroir de bases de données, il n'existe aucun rôle de témoin dans Groupes de disponibilité Always On.

Remarque

Pour plus d’informations sur la relation entre les composants SQL Server Always On et le cluster WSFC, consultez Clustering de basculement Windows Server 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, notamment un réplica principal et quatre réplicas secondaires avec validation synchrone.

Groupe de disponibilité avec cinq réplicas.

Termes et définitions

Terme Description
groupe de disponibilité Conteneur d’un ensemble de bases de données ( bases de données de disponibilité) qui basculent ensemble.
base de données de disponibilité Base de données qui appartient à un groupe de disponibilité. Pour chaque base de données de disponibilité, le groupe de disponibilité conserve une seule copie en lecture-écriture (la base de données primaire) et une à huit copies en lecture seule (lesbases de données secondaires).
base de données primaire Copie en lecture-écriture d'une base de données de disponibilité.
base de données secondaire Copie en lecture seule d'une base de données de disponibilité.
réplica de disponibilité Instanciation d'un groupe de disponibilité hébergé par une instance spécifique de SQL Server et qui conserve une copie locale de chaque base de données de disponibilité appartenant au groupe de disponibilité. Il existe deux types de réplicas de disponibilité : un seul réplica principal et un à huit réplicas secondaires.
réplica principal Réplica de disponibilité qui rend les bases de données primaires disponibles pour les connexions en lecture-écriture à partir des clients et envoie également des enregistrements du journal des transactions pour chaque base de données primaire à chaque réplica secondaire.
réplica secondaire Réplica de disponibilité qui conserve une copie secondaire de chaque base de données de disponibilité, et sert de cible potentielle d'un basculement du groupe de disponibilité. Éventuellement, un réplica secondaire peut prendre en charge l'accès en lecture seule et la création de sauvegardes sur des bases de données secondaires.
écouteur de groupe de disponibilité Nom du serveur auquel les clients peuvent se connecter afin d’accéder à une base de données dans un réplica principal ou secondaire d’un groupe de disponibilité. Les écouteurs de groupe de disponibilité dirigent les connexions entrantes vers un réplica principal ou un réplica secondaire en lecture seule.

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 se trouve dans l’état RESTORING jusqu’à ce qu’elle soit jointe au groupe de disponibilité. Pour plus d’informations, consultez Démarrer un déplacement des données sur une base de données secondaire Always On (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 Always On 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 Always On.

SQL Server 2019 (15.x) augmente le nombre maximal de réplicas synchrones à 5, contre 3 dans SQL Server 2017 (14.x). Vous pouvez configurer ce groupe de cinq réplicas de manière à instaurer le basculement automatique en son sein. Il existe un seul réplica principal, plus quatre réplicas secondaires synchrones.

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.

Notes

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, pour valider des transactions sur une base de données, qu'un réplica secondaire donné ait écrit les enregistrements du journal des transactions sur le disque (journal renforcé). Groupes de disponibilité Always On prend en charge deux modes de disponibilité : le mode avec validation asynchrone (asynchronous-commit mode) et le mode avec validation synchrone (synchronous-commit mode).

  • Asynchronous-commit mode

    Un réplica de disponibilité qui utilise ce mode de disponibilité est appelé réplica en 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é les journaux des transactions. 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.

  • Synchronous-commit mode

    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. En option, SQL Server 2017 a introduit une fonctionnalité de réplicas secondaires synchronisés obligatoires pour améliorer davantage la sécurité au détriment de la latence quand vous le voulez. La fonctionnalité REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT peut être activée pour exiger un nombre spécifié de réplicas synchrones visant à valider une transaction avant qu’un réplica principal ne soit autorisé à la valider.

Pour plus d’informations, consultez Différences entre les modes de disponibilité pour un groupe de disponibilité Always On.

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. Lors d’un basculement, le réplica secondaire cible joue le rôle principal, en 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.

Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Les basculements ne sont pas dus aux problèmes de base de données, tels qu’une base de données devenant suspecte en raison de la perte d’un fichier de données, de la suppression d’une base de données ou de l’altération d’un journal des transactions.

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 le réplica secondaire cible est actuellement synchronisé avec le réplica principal. 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 qu'à la fois le réplica principal et le réplica 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é, posséder le quorum WSFC et remplir les conditions spécifiées par la stratégie de basculement souple du groupe de disponibilité.

  • 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 Basculement et modes de basculement (Groupes de disponibilité Always On).

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.
  • Notez que si vous exécutez une commande de basculement forcé sur un réplica secondaire synchronisé, le réplica secondaire se comporte de la même manière que pour un basculement manuel programmé.

Avantages

Les groupes de disponibilité Always On fournissent un riche ensemble d’options qui améliorent la disponibilité des bases de données et l’utilisation des ressources. Les composants clés sont les suivants :

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 Se connecter à un écouteur de groupe de disponibilité Always On.

Conseil

Si un groupe de disponibilité a uniquement 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 avoir migré une base de données de la mise en miroir de bases de données vers Groupes de disponibilité Always On. Avant d’ajouter des réplicas secondaires supplémentaires, vous devrez créer un écouteur de groupe de disponibilité pour le groupe de disponibilité, puis mettre à jour vos applications afin d’utiliser le nom réseau de l’écouteur.

Réplicas secondaires actifs

Groupes de disponibilité Always On prend 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. Vous devez comprendre que la préférence n’est pas appliquée par SQL Server. Par conséquent, elle n’a aucun effet sur les sauvegardes ad hoc. La traduction de cette préférence dépend de la logique, le cas échéant, que vous avez écrite dans vos travaux de sauvegarde pour chacune des bases de données dans 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 Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité.

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

    Tout réplica de disponibilité secondaire peut être configuré pour autoriser uniquement l’accès en lecture seule à ses bases de données locales, bien que certaines opérations ne soient pas totalement prises en charge. Cela empêche les tentatives de connexion en lecture-écriture au réplica secondaire. Vous pouvez également empêcher les charges de travail en lecture seule sur le réplica principal en autorisant uniquement l’accès en lecture-écriture. Cela empêche des connexions en lecture seule soient établies avec le réplica principal. Pour plus d’informations, consultez Décharger une charge de travail en lecture seule vers un réplica secondaire d’un groupe de disponibilité Always On.

    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 Se connecter à un écouteur de groupe de disponibilité Always On.

Période d’expiration de session

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éplicas primaire et secondaire exécutent réciproquement une commande ping pour signaler qu'ils sont toujours actifs. La réception d’une commande ping de l’autre réplica au cours de la période de 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’attendent pas que ce réplica se reconnecte et se 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

Pour le rôle de résolution, la période d'expiration de session ne s'applique pas parce que la requête 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 du réplica principal. Si le réplica principal ne peut pas lire une page, le réplica diffuse une demande de nouvelle copie à tous les réplicas secondaires et obtient la page du premier qui y répond. 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 Réparation de page automatique (Groupes de disponibilité : mise en miroir de bases de données).

Interopérabilité et coexistence avec d'autres fonctionnalités de moteur de base de données

Groupes de disponibilité Always On peuvent être utilisés avec les fonctionnalités ou les composants SQL Server suivants :

Étape suivante

Bien démarrer avec les groupes de disponibilité Always On