0

J'ai une paire de clusters W2K8 (64) active/passive, exécutant la norme SQL05. Le stockage partagé est sur un SAN HP EVA (FC).Résolution des problèmes de cluster de basculement dans W2K8/SQL05

J'ai récemment développé le système de fichiers sur le nœud actif pour une base de données, en ajoutant une désignation de lecteur. Les lecteurs de stockage partagé sont désignés par F :, I :, J :, L: et X :, avec les systèmes de fichiers SQL sur le premier 4 et X: utilisé pour une destination de sauvegarde. Hier soir, dans le cadre d'un processus de validation (le noeud passif était hors ligne pour la maintenance), j'ai déplacé l'instance SQL vers l'autre noeud du cluster. La base de données en question est immédiatement passée au statut de suspect.

L'examen des journaux système a montré que la base de données ne se chargerait pas car le fichier "K: \ SQLDATA \ whatever.ndf" est introuvable. (Notez que nous n'avons K: désignation du lecteur.)

Un examen du J: disque de stockage a montré zéro contenu - rien - c'est là « whatever.ndf » aurait dû être.

Hmm, je pensais. Problème avec le serveur. Je vais simplement ramener SQL à l'autre serveur et déterminer ce qui ne va pas.

Toujours Toujours pas de base de données. Suspect. Euh-oh. "Whatever.ndf" était parti dans le seau.

J'ai finalement décidé de restaurer à partir de la sauvegarde (qui avait été prise immédiatement avant le test de validation), donc rien n'était perdu, mais quelques heures de sommeil. La question: (1) Pourquoi le nœud passif a-t-il pensé que les fichiers quel que soit.ndf étaient supposés aller sur le lecteur "K:", alors que ce lecteur n'existait pas en tant que ressource sur le nœud actif? (2) Comment puis-je faire en sorte que les nœuds du cluster soient "re-synchronisés" afin que le basculement puisse être effectué? Je ne sais pas qu'il n'y avait pas de lecteur "K:" en tant que ressource de cluster à un moment donné dans le passé, mais je sais que ce lecteur ne possédait pas pas sur le cluster d'origine à ce moment-là de mouvement de ressource.

+0

Vous pourriez obtenir plus d'aide avec ceci à http://serverfault.com/ – jsw

Répondre

0

pensée aléatoire basé sur ce qui est arrivé à moi il y a quelques mois ... son assez similaire

Avez-vous NFTS points de montage? J'ai oublié ce qu'il était exactement (moi monkey code et compté sur les DBA), mais les points de montage étaient soit "double réservé" ou pas partie de la ressource de cluster ou les volumes SAN n'étaient pas configurés correctement.

Nous avions des lecteurs "taille zéro" (j'ai utilisé xp_fixeddrives) pour nos fichiers journaux, mais nous pouvions toujours leur écrire.

Les redémarrages et les basculements assortis ont échoué. Fondamentalement, il s'agissait d'un examen approfondi de tous les paramètres de l'outil de gestion SAN.

Une possibilité pour votre K: drive ...

L'autre chose que j'ai vu est les lecteurs montés ont des lettres ainsi que d'être montés dans des dossiers. J'avais l'habitude d'utiliser des dossiers montés pour SQL Server, mais le système de sauvegarde utilisé une lettre de lecteur direct.