SQL Server Standard : Comprendre les Basic Availability Groups (BAG)

L’édition Standard de SQL Server offre une solution de haute disponibilité : les Basic Availability Groups. Découvrez leurs avantages et leurs limites.

Pendant longtemps, bénéficier de la technologie Always On Availability Groups nécessitait une licence Enterprise, laissant les utilisateurs de l’édition Standard avec le Database Mirroring. Depuis SQL Server 2016, Microsoft a introduit les Basic Availability Groups (BAG) pour remplacer le mirroring dans l’édition Standard.

Qu’est-ce qu’un Basic Availability Group (BAG) ?

Le Basic Availability Group est une déclinaison « light » des Groupes de Disponibilité Always On. Il permet de répliquer une base de données d’une instance SQL Server vers une autre, assurant ainsi un basculement (failover) en cas de panne logicielle ou matérielle.

Comme sa version « Full », il repose sur le service Windows Server Failover Clustering (WSFC), mais il est spécifiquement bridé pour s’adapter aux limitations de l’édition Standard.

Les limitations

C’est ici que le bât blesse. Pour ne pas cannibaliser l’édition Enterprise, Microsoft a imposé des restrictions importantes.

Une seule base de données par groupe

C’est la limite la plus contraignante. Dans un groupe « Standard », vous ne pouvez mettre qu’une seule base. Si votre application utilise trois bases de données interdépendantes, vous devrez créer trois BAG différents.

Cela complexifie la gestion du basculement, car les bases ne basculeront pas forcément ensemble si un problème survient. On peut gérer manuellement cet aspect en créant des scripts de basculements et en réagissant à une erreur spécifique qui est déclenchée par SQL Server lorsqu’un groupe bascule.

Deux nœuds maximum

Un BAG ne supporte que deux réplicas : un Primaire et un Secondaire. Impossible d’ajouter un troisième nœud pour du Disaster Recovery dans une autre région géographique, par exemple.

Pas de lecture sur le secondaire

Le réplica secondaire est « passif ». Vous ne pouvez pas l’utiliser pour décharger vos rapports Power BI ou vos sauvegardes.

Pas de sauvegardes sur le secondaire

Contrairement aux groupes de disponibilité complets, vous ne pouvez pas effectuer vos sauvegardes (Full, Log ou Diff) sur le nœud secondaire pour économiser les ressources du primaire.

Comparatif : Basic AG vs Enterprise AG

FonctionnalitéBasic AG (Standard)Always On AG (Enterprise)
Nombre de bases par groupe1Illimité
Nombre de réplicas2 (1 P + 1 S)Jusqu’à 9
Secondaire lisibleNonOui
Sauvegardes sur le secondaireNonOui
Support de l’ADFS / GMSAOuiOui

Comment gérer les basculements en BAG ?

Comme nous l’avons vu, l’édition Standard impose un groupe de disponibilité par base de données. Si vous avez de très nombreuses bases de données sur votre serveur et que vous voulez toutes les mettre en groupe de disponibilité, cela vous fera beaucoup de groupes de disponibilité à gérer.

Ne créez qu’un seul listener sur un groupe de disponibilité, et connectez toutes vos applications sur ce listener.

Lorsqu’un groupe bascule, il faut que tous les groupes basculent en même temps pour que le listener bascule et que toutes les bases de données soient actives sur le même nœud.

Le risque est un « split-brain » partiel où, suite à un incident, la base A bascule sur le Nœud 2 tandis que la base B reste sur le Nœud 1. Votre application, perdue entre deux serveurs, cessera de fonctionner.

Basculement manuel

Pour la maintenance manuelle, ne basculez pas les bases une par une via l’interface graphique de Management Studio (SSMS). Utilisez PowerShell avec le module dbatools, la référence pour les administrateurs SQL Server.

Une seule ligne de commande permet de basculer tous les groupes d’un nœud vers l’autre proprement :

# Basculer tous les BAG du Nœud 1 vers le Nœud 2
Get-DbaAvailabilityGroup -SqlInstance "SQL-NODE-01" | 
    Invoke-DbaAgFailover -TargetReplica "SQL-NODE-02"