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

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.

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.

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.

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.

Termes et définitions

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.

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.

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).

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 :

• Prend en charge jusqu'à neuf réplicas de disponibilité. Un réplica de disponibilité est une instanciation d'un groupe de disponibilité hébergé par une instance spécifique de SQL Server qui conserve une copie locale de chaque base de données de disponibilité appartenant au groupe de disponibilité. Chaque groupe de disponibilité prend en charge un réplica principal et jusqu'à huit réplicas secondaires. Pour plus d’informations, consultez Qu’est-ce qu’un groupe de disponibilité Always On ?

  Important

  Chaque réplica de disponibilité doit résider sur un nœud différent d'un cluster de clustering de basculement Windows Server (WSFC). Pour plus d’informations sur les prérequis, les restrictions et les recommandations pour les groupes de disponibilité, consultez Prérequis, restrictions et recommandations pour les groupes de disponibilité Always On.

• Prend en charge d'autres modes de disponibilité, comme suit :

  • Mode de validation asynchrone. Ce mode avec validation asynchrone est une solution de récupération d'urgence qui fonctionne bien lorsque les réplicas de disponibilité sont séparés par des distances considérables.

  • Mode de validation synchrone. Ce mode de disponibilité privilégie la haute disponibilité et la protection des données plutôt que les performances, au prix d'une latence accrue des transactions. Un groupe de disponibilité donné peut prendre en charge jusqu’à cinq réplicas de disponibilité avec validation synchrone, y compris le réplica principal actuel.

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

• Prend en charge plusieurs formes de basculement de groupe de disponibilité : le basculement automatique, le basculement manuel planifié (généralement appelé simplement « basculement manuel ») et le basculement manuel forcé (généralement appelé simplement « basculement forcé »). Pour plus d’informations, voir Basculement et modes de basculement (groupes de disponibilité Always On).

• Vous permet de configurer un réplica de disponibilité donné pour prendre en charge l'une des deux fonctions secondaires actives suivantes :

  • Accès à la connexion en lecture seule, permettant aux connexions en lecture seule au réplica d’accéder à ses bases de données et de les lire lorsqu’il s’exécute comme réplica secondaire. 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.

  • Exécution d’opérations de sauvegarde sur ses bases de données lorsqu’il s’exécute comme réplica secondaire. Pour plus d’informations, consultez Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité.

    L'utilisation de fonctions secondaires actives améliore l'efficacité informatique et réduit les coûts grâce à une meilleure utilisation des ressources du matériel secondaire. En outre, le déchargement des applications de tentative de lecture et des travaux de sauvegarde vers des réplicas secondaires permet d'améliorer les performances au niveau du réplica principal.

• Prend en charge un écouteur de groupe de disponibilité pour chaque groupe de disponibilité. Un écouteur de groupe de disponibilité est un nom de 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é Always On. Les écouteurs de groupe de disponibilité dirigent les connexions entrantes vers un réplica principal ou un réplica secondaire en lecture seule. L'écouteur fournit un basculement d'application rapide après le basculement d'un groupe de disponibilité. Pour plus d'informations, consultez Se connecter à un écouteur de groupe de disponibilité Always On.

• Prend en charge une stratégie de basculement flexible pour un contrôle optimisé du basculement de cluster de disponibilité. Pour plus d’informations, voir Basculement et modes de basculement (groupes de disponibilité Always On).

• Prend en charge la réparation de page automatique pour éviter les pages endommagées. Pour plus d’informations, consultez Réparation de page automatique (Groupes de disponibilité : mise en miroir de bases de données).

• Prend en charge le chiffrement et la compression, qui fournissent un transport sécurisé et efficace.

• Fournit un jeu intégré d'outils pour simplifier le déploiement et la gestion de groupes de disponibilité, notamment :

  • Instructions DDL Transact-SQL pour créer et gérer les groupes de disponibilité. Pour plus d’informations, consultez Instructions Transact-SQL pour les groupes de disponibilité Always On..

  • SQL Server Management Studio , comme suit :

    • L' Assistant Nouveau groupe de disponibilité crée et configure un groupe de disponibilité. Dans certains environnements, cet Assistant peut également préparer automatiquement les bases de données secondaires et démarrer la synchronisation de données pour chacune d'elles. Pour plus d’informations, consultez Utiliser la boîte de dialogue Nouveau groupe de disponibilité (SQL Server Management Studio).

    • L'Assistant Ajouter une base de données au groupe de disponibilité ajoute une ou plusieurs bases de données primaires à un groupe de disponibilité existant. Dans certains environnements, cet Assistant peut également préparer automatiquement les bases de données secondaires et démarrer la synchronisation de données pour chacune d'elles. Pour plus d’informations, consultez Ajouter une base de données à un groupe de disponibilité Always On avec « l’Assistant Groupe de disponibilité ».

    • L'Assistant Ajouter un réplica au groupe de disponibilité ajoute un ou plusieurs réplicas secondaires à un groupe de disponibilité existant. Dans certains environnements, cet Assistant peut également préparer automatiquement les bases de données secondaires et démarrer la synchronisation de données pour chacune d'elles. Pour plus d’informations, consultez Ajouter un réplica à un groupe de disponibilité Always On à l’aide de l’Assistant Groupe de disponibilité dans SQL Server Management.

    • L'Assistant Basculer le groupe de disponibilité démarre un basculement manuel sur un groupe de disponibilité. En fonction de la configuration et de l'état du réplica secondaire que vous spécifiez comme cible de basculement, l'Assistant peut effectuer un basculement manuel planifié ou forcé. Pour plus d’informations, consultez Utiliser l’Assistant Basculer le groupe de disponibilité (SQL Server Management Studio).

  • Le Tableau de bord Always On surveille les groupes de disponibilité, les réplicas de disponibilité et les bases de données de disponibilité Always On, et évalue les résultats des stratégies Always On. Pour plus d’informations, consultez Utiliser le tableau de bord des groupes de disponibilité Always On (SQL Server Management Studio).

  • Le volet Détails de l'Explorateur d'objets affiche des informations de base à propos des groupes de disponibilité existants. Pour plus d’informations, consultez Utiliser les détails de l’explorateur d’objets pour surveiller les groupes de disponibilité.

  • Applets de commande PowerShell. Pour plus d’informations, consultez Vue d’ensemble des cmdlets PowerShell pour les groupes de disponibilité Always On.

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.

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.

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 :

• Qu’est-ce que la capture des changements de données (CDC) ?
• À propos du suivi des modifications (SQL Server)
• Bases de données autonomes
• Chiffrement transparent des données (TDE)
• Instantanés de base de données avec des groupes de disponibilité Always On (SQL Server)
• FILESTREAM (SQL Server)
• FileTables (SQL Server)
• À propos de la copie des journaux de transaction (SQL Server)
• Magasin d'objets blob distants (RBS) (SQL Server)
• Réplication SQL Server
• Service Broker
• SQL Server Agent
• Reporting Services avec les groupes de disponibilité Always On (SQL Server)

Tâches associées

• Conditions préalables requises, restrictions et recommandations pour les groupes de disponibilité Always On
• Informations de référence sur la création et la configuration des groupes de disponibilité Always On
• Administration d’un groupe de disponibilité
• Outils pour surveiller les groupes de disponibilité Always On
• Décharger une charge de travail en lecture seule vers un réplica secondaire d’un groupe de disponibilité Always On
• Décharger les sauvegardes prises en charge vers des réplicas secondaires d’un groupe de disponibilité
• Se connecter à un écouteur de groupe de disponibilité Always On
• Instructions Transact-SQL pour les groupes de disponibilité Always On
• Vue d’ensemble des applets de commande PowerShell pour les groupes de disponibilité Always On
• Blog sur le support SQL Server - Haute disponibilité
• Blog SQL Server - SQL Server Always On
• Archive : Blogs de l’équipe SQL Server Always On : Blog officiel de l’équipe SQL Server Always On
• Archive : Blogs des ingénieurs du Service clientèle et du Support technique de SQL Server
• Guide de solutions Microsoft SQL Server Always On pour la haute disponibilité et la récupération d’urgence

Étape suivante