Qu'est-ce qui peut provoquer l'expiration d'une session de mise en miroir puis le basculement?
Nous avons deux serveurs SQL de production exécutant SQL Server 2005 SP4 avec une mise à jour cumulative 3. Les deux serveurs fonctionnent sur des machines physiques identiques. Dell PowerEdge R815 avec 4 x 12 cœurs et 512 Go (oui Go) de RAM, avec 10 Go iSCSI SAN lecteurs connectés pour toutes les bases de données et journaux SQL. Le système d'exploitation est Microsoft Windows Server 2008 R2 Enterprise edition avec tous les SP et les mises à jour Windows. Le lecteur du système d'exploitation est une matrice RAID 5 de 3 x 72 Go 2,5 "15k SAS. SAN est un Dell EqualLogic 6510 avec 48 x 10K SAS 3,5 ", configurés en RAID 50, découpés en plusieurs LUN pour les 2 serveurs SQL et également partagés avec une machine Exchange et plusieurs serveurs VMWare.
Nous avons plus de 20 bases de données, dont 11 sont mises en miroir avec une haute disponibilité à l'aide d'un serveur témoin. Le serveur témoin est une machine moins puissante exécutant une instance SQL Server qui n'est utilisée que pour fournir des services témoins. La plus grande base de données en miroir fait 450 Go et génère environ 100 à 300 iops. Le moniteur de mise en miroir de bases de données signale un taux d'envoi actuel d'environ 100 Ko à 10 Mo par seconde, et une surcharge de validation de miroir de (généralement) 0 millisecondes. Le serveur miroir n'a aucun problème à suivre le principal.
Nous rencontrons régulièrement des basculements en miroir. Parfois, une seule base de données basculera, d'autres fois presque toutes les bases de données basculeront simultanément. Par exemple, hier soir, 10 des 11 bases de données ont été basculées, la base de données restante est restée accessible jusqu'à ce que je la bascule manuellement.
J'ai suivi plusieurs étapes de dépannage pour tenter d'identifier le problème, mais jusqu'à présent je n'ai pas pu résoudre le problème:
1) La machine est livrée avec un adaptateur réseau Gigabit Broadcom BCM5709C NetXtreme II à 4 ports que nous avons initialement utilisé comme connexion réseau principale. Nous avons depuis installé un adaptateur de serveur Intel (R) PRO/1000 PT à double port sur les deux machines pour éliminer le NIC comme problème).
2) Toutes les bases de données ont une sauvegarde complète automatique tous les soirs avec une sauvegarde de journal pour les bases de données impliquées dans la mise en miroir. L'utilisation du fichier journal est surveillée et est rarement utilisée à plus de 15%. Le fichier journal de la base de données principale est de 125 Go, composé de 159 fichiers journaux virtuels dont la taille varie de 511 Mo à 1 Go. TempDB est sur son propre LUN et se compose de 24 fichiers de 2 Go.
3) Le journal SQL Server sur le témoin ne montre aucune erreur autre que: La connexion en miroir à "TCP: //SQL02.DOMAIN.INET: 5022" a expiré pour la base de données "Data" après 30 secondes sans réponse. Vérifiez le service et les connexions réseau.
Le journal SQL Server sur les serveurs principal et secondaire affiche des messages relatifs à la mise en miroir:
La connexion en miroir à "TCP: //SQL01.DOMAIN.INET: 5022" a expiré pour la base de données "Data" après 30 secondes sans réponse. Vérifiez le service et les connexions réseau.
La base de données en miroir "Data" fait passer les rôles de "PRINCIPAL" à "MIRROR" en raison de la synchronisation des rôles. (La synchronisation est mal orthographiée ici volontairement, car c'est précisément la façon dont le message réel est affiché.)
La base de données en miroir "Data" fait passer les rôles de "PRINCIPAL" à "MIRROR" en raison du basculement.
La base de données en miroir "Data" change les rôles de "MIRROR" à "PRINCIPAL" en raison du basculement du partenaire.
Les services SQL Server continuent de fonctionner et les connexions réseau semblent rester en place. Nous avons régulièrement entre 500 et 2500 sessions connectées à chaque serveur (principalement des applications robotiques qui se connectent aux files d'attente de Service Broker sur une seule base de données).
4) TCP Chimney et RSS, etc. sont désactivés à l'aide de la syntaxe NET SH.
5) J'ai exécuté SQL Server 2005 Best Practices Analyzer sur les deux machines et je ne trouve rien d'autre que l'erreur très occasionnelle 833 du journal des événements d'application, dont aucune ne coïncide avec les événements de basculement:
SQL Server a rencontré 1 occurrence (s) de demandes d'E/S prenant plus de 15 secondes pour terminer sur le fichier [F:\Data.MDF] dans la base de données [Data] (9). Le descripteur de fichier du système d'exploitation est 0x00000000000010A0. Le décalage de la dernière longue E/S est: 0x000007d4b10000).
6) Parfois, nous voyons "Le client n'a pas pu réutiliser une session avec SPID XXX, qui avait été réinitialisée pour le regroupement de connexions. Cette erreur peut avoir été provoquée par l'échec d'une opération antérieure. Consultez les journaux d'erreurs pour les opérations ayant échoué immédiatement avant ce message d'erreur. . " généré par les deux serveurs. Il ne semble y avoir aucun message "antérieur" qui indique un problème.
7) Parfois, le courrier de la base de données écrit une erreur dans le journal des événements d'application:
Type d'exception: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Message: une erreur s'est produite sur la connexion. Raison: le délai a expiré. Le délai d'expiration s'est écoulé avant la fin de l'opération ou le serveur ne répond pas., Paramètres de connexion: Nom du serveur: MGSQL02, Nom de la base de données: msdb Data: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common.SqlConnectionInfo) HelpLink: NULL Source: DatabaseMailEngine
Informations StackTrace sur Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) sur Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection (String dbServerName, String dbName Password String ) sur Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Je crois que les délais d'attente provoquent le basculement; qu'est-ce qui pourrait provoquer ces délais? Évidemment, s'il y avait un problème de réseau réel tel qu'un mauvais câble ou un mauvais commutateur, cela pourrait entraîner une perte de paquets et donc un délai d'attente, mais quelles autres choses pourraient provoquer des délais d'attente? Blocage? Si MSDB ou une autre base de données système avait un délai d'E/S, cela pourrait-il provoquer le basculement de la mise en miroir?
Merci pour tout conseil!
MSDN a le suivant pour dire sur le mécanisme de timeout lui-même :
Le mécanisme de temporisation de mise en miroir
Étant donné que les erreurs logicielles ne sont pas détectables directement par une instance de serveur, une erreur logicielle peut potentiellement faire attendre indéfiniment une instance de serveur. Pour éviter cela, la mise en miroir de bases de données implémente son propre mécanisme de délai d'expiration, basé sur chaque instance de serveur dans une session de mise en miroir envoyant un ping sur chaque connexion ouverte à un intervalle fixe.
Pour garder une connexion ouverte, une instance de serveur doit recevoir un ping sur cette connexion dans le délai d'expiration défini, plus le temps nécessaire pour envoyer un ping supplémentaire. La réception d'un ping pendant le délai d'attente indique que la connexion est toujours ouverte et que les instances de serveur communiquent via elle. Lors de la réception d'un ping, une instance de serveur réinitialise son compteur de délai d'attente sur cette connexion.
Si aucun ping n'est reçu sur une connexion pendant le délai d'expiration, une instance de serveur considère que la connexion a expiré. L'instance de serveur ferme la connexion expirée et gère l'événement d'expiration en fonction de l'état et du mode de fonctionnement de la session.
netsh interface tcp show global montre:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled
netsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510
SELECT name, value_in_use FROM sys.configurations
Requêtes distribuées ad hoc 0 Masque d'E/S d'affinité 0 Masque d'affinité 0 Masque d'E/S d'affinité64 0 Masque d'affinité64 0 Agent XPs 1 Autorise les mises à jour 0 Awe activé 0 Seuil de processus bloqué 5 C2 mode d'audit 0 Clr activé 1 conformité aux critères communs activée 0 seuil de coût pour le parallélisme 4 chaîne de propriété croisée de la base de données 0 seuil du curseur -1 Base de données XPs de messagerie 1 langue par défaut du texte intégral 1033 langue par défaut 0 trace par défaut activée 1 interdiction des résultats des déclencheurs 0 facteur de remplissage (%) 0 ft bande passante d'exploration (max) 100 ft bande passante d'exploration (min) 0 ft notifier la bande passante (max) 100 ft notifier la bande passante (min) 0 index créer de la mémoire (Ko) 0 résolution de xact dans le doute 0 regroupement léger 0 verrouille 0 degré maximal de parallélisme 6 plage d'exploration maximale du texte intégral 4 mémoire maximale du serveur (Mo) 393216 Taille maximale de réponse de texte (B) 65536 Nombre maximal de threads de travail 0 Rétention du support 0 Min mémoire par requête (Ko) 2048 Min mémoire du serveur (Mo) 52427 déclencheurs imbriqués 1 taille de paquet réseau (B) 1400 Procédures d'automatisation Ole 1 objets ouverts 0 Délai d'expiration du PH (s) 60 précalcul du rang 0 augmentation de priorité 0 limite du coût du gouverneur de requête 0 attente (s) de requête -1 intervalle de récupération ( min) 0 accès à distance 1 Connexions admin distantes 0 Délai (s) de connexion à distance 20 Processus distant trans 0 Délai (s) de requête à distance 600 XP de réplication 0 Recherche de procs de démarrage 0 Récursion de déclenchement du serveur 1 Set working set size 0 Affiche les options avancées 1 SMO et DMO XPs 1 SQL Mail XPs 0 Transforme les mots parasites 0 Coupure de l'année à deux chiffres 2049 Connexions utilisateur 0 Options utilisateur 4216 Assistant Web Proce dures 0 xp_cmdshell 1
Il y a quelque temps, j'ai modifié manuellement le mirroring_connection_timeout valeur pour toutes les bases de données en miroir à 30 secondes pour tenter de résoudre le problème; cela a simplement augmenté la durée entre les événements de basculement. Avec le mirroring_connection_timeout paramètre défini à la valeur par défaut de 10 secondes, nous voyons beaucoup beaucoup plus de basculements.
Un commentaire m'avait demandé de m'assurer qu'IPSec était désactivé, donc je poste le contenu de plusieurs commandes netsh qui affichent la configuration IPSec du système d'exploitation:
C: \> netsh ipsec dynamic afficher tout Aucune stratégie actuellement affectée Stratégies de mode principal non disponibles. Stratégies de mode rapide non disponibles. Filtres génériques en mode principal non disponibles. Filtres génériques en mode principal non disponibles. Filtres génériques en mode rapide non disponibles. Filtres spécifiques en mode rapide non disponibles. Sécurité IPsec MainMode Associations non disponibles. Associations de sécurité IPsec QuickMode non disponibles. Paramètres de configuration IPsec ---------------- -------------- StrongCRLCheck: 1 IPsecexempt: 3 Statistiques IPsec --- ------------- Association active: 0 SA de déchargement: 0 Clé en attente: 0 Clés ajoutées: 0 Suppressions de clés: 0 Touches clés: 0 Tunnels actifs: 0 Mauvais SPI Pkts : 0 Paquets non déchiffrés: 0 Paquets non authentifiés: 0 Paquets avec détection de relecture: 0 Octets confidentiels envoyés: 0 Octets confidentiels Reçu: 0 Octets authentifiés envoyés: 0 Octets authentifiés reçus: 0 Octets de transport envoyés: 0 Octets de transport reçus: 0 Octets envoyés Dans les tunnels: 0 Octets reçus Dans les tunnels: 0 Octets déchargés envoyés: 0 Octets déchargés reçus: 0 C: \> netsh ipsec statique afficher tout ERR IPsec [05072]: Aucune stratégie dans le magasin de stratégies
MISE À JOUR: 2012-12-20
Nous avons maintenant déplacé nos systèmes de production sur SQL Server 2012. Nous exécutons cela depuis le matin du 17 décembre - jusqu'à présent, aucun basculement. Cependant, quelques jours sont bien dans ce que nous avons vu avec les systèmes basés sur 2005.
Afin de documenter les performances de nos nouveaux systèmes, j'ai examiné sys.dm_os_wait_stats plus attentivement; et remarqué DBMIRROR_DBM_EVENT, qui est un type d'attente non documenté. Graham Kent chez Microsoft a une intéressante article concernant le dépannage des basculements inattendus et ce type d'attente. Je récapitulerai ses conclusions ici:
Le client connaissait une énorme chaîne de blocage basée sur un volume élevé OLTP base de données où tous les bloqueurs principaux attendaient sur DBMIRROR_DBM_EVENT. Voici la séquence d'événements que j'ai traversée:
Examinez la chaîne de blocage elle-même - ho aide ici car tout ce que nous pouvons voir, c'est que nous attendons sur DBMIRROR_DBM_EVENT
Vérifiez la source du type d'attente non documenté. Évidemment, vous ne pouvez pas faire cela en dehors de MS, mais je peux dire qu'au moment de l'écriture, ce type d'attente représente l'attente utilisée lorsque le principal attend que le miroir durcisse un LSN, ce qui signifie que la transaction dont il fait partie ne peut pas être validée . Cela pointe immédiatement tout à fait spécifiquement au problème que le principal ne peut pas commettre de transactions pendant qu'il attend sur le miroir. Nous devons maintenant rechercher pourquoi le miroir ne commet pas de transactions ou pourquoi le principal ne sait pas si c'est le cas.
Passez en revue les tables système msdb
(a) Examinez la table [backupset] pour voir si la taille des journaux produits au moment du problème est nettement supérieure à la normale. S'ils étaient exceptionnellement grands, il se peut que le miroir soit inondé de transactions et ne puisse tout simplement pas suivre le volume. C'est pourquoi les livres en ligne vous diront parfois de désactiver la mise en miroir si vous devez effectuer une opération journalisée exceptionnellement grande telle qu'une reconstruction d'index. (référence pour savoir pourquoi c'est à http://technet.Microsoft.com/en-us/library/cc917681.aspx ). Ici, j'ai utilisé le TSQL suivant
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'
(b) d'autre part, j'ai regardé les données dans les tableaux [dbm_monitor_data]. La clé ici est de localiser le délai dans lequel nous avons eu un problème et de voir ensuite si nous avons subi des changements importants dans l'un des éléments suivants:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate
Ce sont tous des indicateurs similaires à la partie (a) en ce qu'ils peuvent montrer un composant ou un morceau d'architecture qui ne répond pas. Par exemple, si send_queue commence soudainement à croître mais que la file d'attente re_do n'augmente pas, cela impliquerait que le principal ne peut pas envoyer les enregistrements de journal au miroir, vous voudrez peut-être regarder la connectivité ou les files d'attente du courtier de service traitant des transmissions réelles.
Dans ce scénario particulier, nous avons noté que tous les compteurs semblaient avoir des valeurs étranges, en ce sens qu'il y avait des sauvegardes de journaux en cours de tailles normales, mais il n'y avait aucun changement d'état, 0 file d'attente d'envoi, 0 file d'attente de rétablissement, un taux d'envoi plat et un plat refaire le taux. C'est très étrange car cela implique que le moniteur DBM n'a pu enregistrer aucune valeur de n'importe où au cours de la période de problème.
Consultez les journaux d'erreurs SQL Server. Dans ce cas, il n'y a eu aucune erreur ou message d'information, mais dans d'autres scénarios comme celui-ci, il est très courant que des erreurs de la plage 1400 soient signalées, dont vous pouvez trouver des exemples à d'autres endroits dans mes autres blogs en miroir, tels que cet exemple d'erreur 1413
Passez en revue les fichiers de trace par défaut - dans ce scénario, je n'ai pas reçu les traces par défaut, mais ce sont des sources fantastiques d'informations sur les problèmes DBM, car elles enregistrent les événements de changement d'état sur tous les partenaires. Ceci est documenté ici:
Classe d'événement de changement d'état de mise en miroir de bases de données
Cela vous donne souvent une excellente image de scénarios tels que lorsque la connectivité réseau a échoué entre un ou tous les partenaires, puis l'état du partenariat par la suite.
CONCLUSIONS:
Dans ce scénario particulier, il me manque actuellement 2 points clés de données, mais à part cela, je peux encore faire une hypothèse raisonnable sur les informations ci-dessus. Nous pouvons certainement dire que le blocage a été causé par le fait que DBM a été activé à cause des bloqueurs qui attendent tous sur le type d'attente DBMIRROR_DBM_EVENT. Étant donné que nous savons que nous n'avons pas inondé le miroir d'une opération journalisée volumineuse et que ce déploiement s'exécute normalement correctement dans ce mode, nous pouvons exclure les opérations volumineuses inhabituelles. Cela signifie que nous avons à ce stade 2 candidats potentiels:
Problèmes matériels sur la connectivité entre certains ou tous les partenaires.
Épuisement du processeur sur le serveur miroir - tout simplement incapable de suivre les redos - l'épuisement du processeur peut lui-même provenir d'un processus en dehors de SQL Server ou en dehors de ce partenariat miroir.
Un problème avec le code miroir lui-même (nous aurions vraiment besoin de quelques vidages de mémoire pour le confirmer).
Sur la base de l'expérience, je soupçonne 1 ou 2, mais je garde toujours un esprit ouvert à propos de 3 également, nous essayons de collecter plus de données maintenant pour examiner ce problème plus en détail.
Il semble que vous manquiez de ports TCP sur le serveur SQL. Combien de connexions voyez-vous au serveur à la fois?
Des délais d'attente comme celui-là seraient certainement à l'origine du problème.
Pouvez-vous vous vérifier sys.dm_os_schedulers ? Plus précisément, work_queue_count s'écarte de 0 pendant un temps significatif? Cela indiquerait famine du travailleur et expliquerait bon nombre de vos symptômes.