SQL Server AlwaysOn est une fonctionnalité de SQL Server qui offre des solutions de haute disponibilité et de reprise après sinistre pour les bases de données. Il vous permet de créer un groupe de bases de données, appelé groupe de disponibilité (AG), qui peut basculer en cas de défaillance. Dans cet article de blog, nous discuterons de quelques questions et concepts courants liés à SQL Server AlwaysOn.

Stockage partagé et stockage local

Une question courante est de savoir comment SQL Server AlwaysOn peut être mis en œuvre avec à la fois un stockage partagé et un stockage local. La réponse est que les nœuds de votre cluster peuvent avoir à la fois un stockage partagé et un stockage local. Le groupe de disponibilité utilisera le stockage local et dupliquera les bases de données sur tous les nœuds, tandis que le FCI utilisera le stockage partagé et peut ne pas être installé sur tous les nœuds du cluster. Le stockage partagé et le stockage local sont pris en charge ensemble.

Bases de données système

Une autre question qui se pose souvent est pourquoi les bases de données système ne sont pas ajoutées au groupe de disponibilité. Tout comme la mise en miroir, les bases de données système ne sont pas éligibles et ne peuvent pas être ajoutées à un AG.

Réplicas en lecture/écriture et en lecture seule

En ce qui concerne les réplicas en lecture/écriture et en lecture seule, seul le réplica principal est en lecture/écriture. Tous les réplicas secondaires sont en lecture seule par défaut, mais vous pouvez désactiver ou limiter cette fonctionnalité si nécessaire.

SQL FCI et AG

Avant les AG, il était courant d’utiliser un SQL FCI en tant que réplica principal et un autre SQL FCI en tant que réplica secondaire pour la protection, tout en profitant des AG pour des fins de reporting. Cependant, avec les AG, il est plus pratique d’avoir deux réplicas dans chaque centre de données avec un AG entre eux et aucun FCI.

Procédures stockées et tâches SQL Agent

Les procédures stockées sont automatiquement répliquées vers les réplicas secondaires, car elles sont stockées dans la base de données. Cependant, les tâches SQL Agent doivent être recréées sur les réplicas secondaires, avec du code supplémentaire ajouté pour qu’elles se terminent correctement si le réplica agit actuellement en tant que réplica secondaire. Cela garantit que les tâches s’exécutent automatiquement si le réplica devient le principal.

Installation des Service Packs SQL

Lors de l’installation des Service Packs SQL après la mise en place des AG, il est recommandé de mettre à jour d’abord un réplica secondaire, de s’assurer qu’il est en mode synchrone, puis de basculer dessus. Une fois que les réplicas restants sont mis à niveau, vous pouvez revenir à votre réplica préféré.

SELECT @@SERVERNAME

L’instruction SELECT @@SERVERNAME renvoie le nom du nœud. Cependant, les anciennes versions de SQL Server peuvent renvoyer le nom de l’écouteur pour un FCI. Pour obtenir le nom du nœud indépendamment de la version, vous pouvez utiliser l’instruction SELECT SERVERPROPERTY(‘ComputerNamePhysicalNetBIOS’).

Vues indexées sur les réplicas secondaires

Les vues indexées ne peuvent pas être créées séparément sur les réplicas secondaires par rapport au réplica principal. Elles doivent être créées sur le principal et se synchroniseront avec les réplicas secondaires. Il est important de se rappeler que les réplicas secondaires sont en lecture seule et ne peuvent pas être écrits.

Basculement automatique et délai d’expiration de la connexion client

Lors de l’utilisation des AG en mode de basculement automatique, les applications doivent être conçues pour réessayer la connexion. Il est également recommandé d’ajouter MultiSubnetFailover=true à la chaîne de connexion et de réduire le TTL du nom de l’écouteur.

Avantages de regrouper des bases de données dans un AG

Regrouper plusieurs bases de données dans un seul AG est avantageux lorsque plusieurs bases de données prennent en charge une seule application. Si l’une d’entre elles échoue, elles peuvent toutes basculer ensemble. Cela atténue le risque de rupture de l’application si les bases de données étaient mises en miroir individuellement.

Réplicas dans des domaines différents

Tous les réplicas d’un AG doivent faire partie du même cluster Windows, ce qui nécessite que tous les nœuds soient dans le même domaine. Il est important de noter que même si les serveurs sont dans des domaines différents au sein d’une hiérarchie de forêt, ils ne peuvent pas faire partie du même AG.

Cluster de 8 nœuds

Si tous les serveurs de votre environnement sont déjà dans un cluster de 8 nœuds, il n’est pas nécessaire de créer un autre cluster au sein de ce cluster. Vous pouvez utiliser le cluster existant pour mettre en œuvre SQL Server AlwaysOn.

SQL Server AlwaysOn est une fonctionnalité puissante qui offre des solutions de haute disponibilité et de reprise après sinistre pour vos bases de données. En comprenant ces concepts et meilleures pratiques, vous pouvez mettre en œuvre et gérer efficacement SQL Server AlwaysOn dans votre environnement.