Le basculement automatique de base de données en c # ne fonctionne pas lorsque le serveur principal se déconnecte physiquement


9

Je configure le basculement automatique de base de données en C # avec SQL Server 2008 et j'ai une `` haute sécurité avec miroir de basculement automatique '' à l'aide d'une configuration témoin et ma chaîne de connexion ressemble

"Server=tcp:DC01; Failover Partner=tcp:DC02; database=dbname; uid=sewebsite;pwd=somerndpwd;Connect Timeout=10;Pooling=True;"

Pendant les tests, lorsque je désactive le service SQL Server sur le serveur principal, le basculement automatique fonctionne comme un charme, mais si je mets le serveur principal hors ligne (en arrêtant le serveur ou en tuant la carte réseau), le basculement automatique ne fonctionne pas et mon le site Web arrive à expiration.

J'ai trouvé cet article où l'avant-dernier post suggère que c'est parce que nous utilisons des canaux nommés qui ne fonctionnent pas lorsque le principal se déconnecte, mais nous forçons TCP dans notre chaîne de connexion.

Que manque-t-il pour que ce basculement automatique DB fonctionne?


Cela nécessite-t-il la balise [C #]? Il ne semble en aucun cas être spécifique à C #.
Gabe

Réponses:


6

Après avoir travaillé avec MS pendant une semaine, nous avons compris pourquoi cela se produit.

Essentiellement, l'application ne bascule pas car elle doit être sûre que la base de données a basculé - et la connexion SQL expire avant que la connexion ait déterminé que la base de données a basculé.

Le processus pour confirmer que la base de données a basculé (avec tous les paramètres de registre TCP par défaut) consiste à:

  1. essayer de communiquer avec le principal, voir que ce n'est plus le principal
  2. communiquer avec le basculement pour vous assurer qu'il a basculé et qu'il s'agit désormais du nouveau principal.

Lorsque le principal est en panne, cette communication prend environ 21 secondes car elle:

  1. essayez de communiquer avec le principal, attendez 3 secondes, timeout
  2. essayez de communiquer à nouveau avec le principal, attendez 6 secondes, timeout
  3. essayez de communiquer à nouveau avec le principal, attendez 12 secondes, timeout
  4. essayez de communiquer avec le partenaire de basculement, vérifiez qu'il a basculé, donc basculez dans l'application.

Donc, si votre connexion sql n'attend pas 21 secondes (probablement plus dans la réalité), elle va expirer avant de terminer cette danse et ne va pas basculer du tout.

La solution consiste à définir le délai d'expiration de votre chaîne de connexion sur une grande valeur, nous utilisons 60 secondes pour être sûr.

À votre santé


0

Je me demande si les conditions de basculement automatique ne sont pas remplies lors de vos tests? Plus précisément - si la base de données n'est pas synchronisée avec le miroir (vérifiez l'état de mise en miroir à partir de sys.database_mirroring) au moment de l'échec ET / OU si le témoin et le miroir ne sont pas connectés à ce moment (test via des pings entre les rôles participants).

Vous pouvez également avoir une situation où votre partenaire et votre miroir ne sont pas connectés l'un à l'autre - mais les bases de données partenaire et miroir sont toujours connectées au témoin indépendamment. Dans ce cas, le témoin ne voit rien de mal (et donc pas de basculement). Mais vous avez mentionné que vous avez arrêté le serveur lui-même, donc cela semble moins probable.

Ou dites-vous que le basculement se produit finalement mais que votre reconnexion échoue? Dans ce cas, le temps de détection et de basculement varie en fonction de l'échec du principal et du temps total pour récupérer la base de données miroir.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.