Quelle est la meilleure pratique pour le niveau d'accès aux bases de données du cluster de basculement du serveur SQL ?

Question

En principe, un cluster de basculement SQL Server se présente comme une machine virtuelle à laquelle les applications peuvent se connecter sans tenir compte du fait que le serveur SQL est en fait un cluster de serveurs. Ainsi, en principe, aucune logique supplémentaire n'est requise dans le niveau d'accès à la base de données de l'application.

Ma question est de savoir si ce qui précède est vrai et s'il existe des modifications des meilleures pratiques sur la façon dont le niveau d'accès à la base de données fonctionne lorsqu'on utilise un cluster de basculement. Par exemple, on peut supposer que lors d'un basculement, il y aura un délai qui peut causer une erreur de dépassement de temps au niveau de l'accès à la base de données. Nous envisageons de mettre en place une logique dans ce niveau pour réessayer [certains] appels à la base de données lorsqu'un dépassement de temps se produit (nous avons déjà une logique de réessai pour les blocages de la base de données). Cela fournit un autre niveau de protection contre les erreurs affectant l'application.

Si un basculement se produit et que l'application supérieure reçoit une erreur de délai d'attente sur un appel de service, il ne s'agit pas d'un basculement transparent. Devrions-nous simplement fixer nos délais d'attente à une durée qui permette le basculement ?

Merci.

Answer 1

En principe, un cluster de basculement SQL Server se présente comme un v auxquelles les applications peuvent se connecter sans se rendre compte que le serveur SQL est en fait un cluster de serveurs

Ah ? Vraiment ? Cela contredit la documentation. Un cluster n'est en fait rien d'autre qu'une adresse IP mobile avec une installation différente sur différents serveurs, ce qui n'est pas une machine virtuelle.

en principe, aucune logique supplémentaire n'est nécessaire w l'application.

Oui et non - un nœud défaillant tue évidemment toutes les transactions et connexions en cours, et le CLIENT doit donc être capable de réagir à cela et de réessayer. Si le client se plante parce qu'une connexion est interrompue et qu'il ne réessaie pas, cela ne vous aide pas que le serveur soit de nouveau joignable après une seconde ou deux.

Devrions-nous simplement fixer nos délais d'attente à une durée qui permette le basculement ?

Non, une connexion est rompue par le basculement car l'état de la transaction en cours est perdu. Vous devez rétablir la connexion, puis relancer toutes les commandes Sql qui ont été émises dans la transaction.

Du point de vue de la sécurité, le clustering n'est pas une bonne solution et vous devriez utiliser le mirroring - vous courez le risque qu'un nœud de cluster défaillant corrompe les fichiers de la base de données, auquel cas le basculement échoue. La mise en miroir est plus robuste.