"AlwaysOn" n'est-il pas toujours "Always On?"

Nous avons créé un cluster de basculement Windows, puis ajouté deux instances de SQL Server en tant que nœuds d'un cluster de basculement SQL Server.

Nous avons configuré les serveurs pour utiliser les «groupes de disponibilité AlwaysOn» dans SQL Configuration Manager.

Pour tester un basculement, j'ai chargé et exécuté une longue requête, puis j'ai arrêté le nœud actif en utilisant le Gestionnaire de cluster de basculement pour arrêter le service de cluster sur le nœud actif.

La requête s'est interrompue sans connexion et le serveur s'est révélé indisponible pendant environ 20 secondes avant que le nœud ne soit vidé et que le nouveau nœud prenne le relais.

Ai-je mal agi? Comment aurais-je dû configurer cela pour qu'il y ait peu ou pas de perte de connectivité?

AlwaysOn n'est-il pas toujours activé?

Vous avez ici un tas de questions différentes.

Q: Qu'est-ce que la fonction "Always On"?

Microsoft utilise ce nom de marque (écrit sans espace avant 2016) pour décrire deux fonctionnalités différentes:

• Instances de cluster de basculement (FCI) - ce que votre grand-père appelait un cluster actif / passif
• Groupes de disponibilité (AG) - comme la mise en miroir de bases de données, mais fonctionne avec des groupes de bases de données dans certains cas (mais pas les bases de données système)

Utilisez ces termes pour décrire la fonctionnalité Always On spécifique que vous utilisez.

Q: Dans un basculement, sera-t-il toujours activé?

Ni les FCI ni les AG ne sont vraiment toujours actifs. Lors d'un basculement, vos transactions en cours échouent et les tentatives de connexion peuvent échouer pendant 5 à 60 secondes (ou plus). C'est à vous de créer une logique de relance gracieuse dans vos applications ou d'intégrer des outils de capacité dégradés comme Stack Overflow .

Q: Comment configurer Always On?

Il varie considérablement en fonction de:

• Quelle fonction AO vous utilisez (FCI ou AG)
• Le nombre de nœuds dans le cluster
• Comment vous souhaitez gérer le quorum (vote)
• Que vous utilisiez le basculement automatique via un écouteur ou un nom d'ordinateur virtuel

Ce sont de grandes décisions qui impliquent beaucoup de travail d'architecture. Pour des détails plus détaillés, incluez les détails ci-dessus, et nous serons en mesure de vous en dire plus sur la façon de le configurer.

Q: Ne s'agit-il pas simplement de cocher la case Always On?

Nan.

Vous pouvez confondre les AG (groupes de disponibilité) «Always ON» avec les FCI (instances de cluster de basculement), qui dépendent tous deux de WSFC (cluster de basculement Windows Server).

Cliquer sur «toujours activé» ne garantit pas que vous disposez désormais d'une configuration AG. Vous devez définir l'async, la synchronisation, les réplicas en lecture seule / basculement, définir la priorité et prendre d'autres considérations telles que l'application prend-elle en charge cette configuration. Par exemple, votre application peut utiliser des transactions MSDTC inter-bases de données, qui ne sont pas prises en charge et peuvent provoquer une corruption irrécupérable qui nécessite une restauration de sauvegarde.

En ce moment, ce que vous rencontrez est un basculement FCI. C'est normal. Cela arrête les services sur un nœud et démarre les services sur l'autre nœud. Cela fonctionne au niveau INSTANCE. Une solution AG est configurée par base de données et les services s'exécutent sur les deux nœuds. SQL utilise les API WSFC pour garder les données synchronisées sur les répliques, et la base de données bascule sur cette réplique; notez pas l'instance.

Vous voudrez peut-être faire beaucoup de tests à ce sujet avant le déploiement en production.

Ma méthode préférée pour tester un basculement dans un AG est de simplement déconnecter le primaire actuel. Il suffit de le couper, de l'éteindre depuis la console, de couper son réseau, de tuer le service SQL avec une solution miracle, peu importe. Vous ne devriez pas le tester à partir de quelque chose comme une interface graphique, car ce n'est pas ainsi que fonctionne le chaos.

_{Réponse du wiki communautaire :}

Il s'agit d'un comportement normal et attendu pour un cluster.

Il est de la responsabilité de l'application de gérer la déconnexion avec élégance. Toutes les transactions en vol seront perdues, car seules les transactions validées sont répliquées entre les serveurs.