0

[sqsrvres] OnlineThread: SQL Cluster shared data upgrade failed

Posted on by David Baffaleuf
twitterlinkedinmail

Hello,

Il existe déjà un post sur ce problème spécifique au patch de cluster  SQL Server 2008 / 2008R2 ici, mais je suis tombé dessus ce matin et je me disais qu’il serait pas mal de poster un peu les étapes de résolution en français.

Le problème se pose lorsque l’on patche un SQL Server 2008 ou 2008 R2 dans un cluster WFC Windows 2008 / 2008R2. Contrairement au patch sur windows 2003, où le setup était lancé sur le nœud actif et créait des tâches planifiées sur les nœuds distants, le mode de patch a été revu à partir de Windows 2008 et la procédure est devenue :

– Patch du noeud inactif.
– Reboot du noeud inactif.
– Bascule du groupe SQL Server sur le nouveau noeud.
– Patch du noeud inactif.
– Reboot du noeud inactif.
– Rebascule en mode nominal.

Ce mode a plusieurs avantages: d’abord la disponibilité, puisque pendant que le patch est déposé sur le noeud inactif, SQL Server est toujours up and running sur le noeud actif. L’instance sera réellement upgradée lors de la bascule. Ensuite, un retour arrière plus aisé dans la mesure où il suffit de downgrader le noeud inactif, sans coupure de production.

Le problème se pose lors de la bascule, et donc à l’étape ou SQL Server est redémarré à travers le gestionnaire du cluster: dans l’event viewer, l’erreur éponyme:

[sqsrvres] OnlineThread: SQL Cluster shared data upgrade failed

A partir de là, on ne verra rien de particulier dans l’ERRORLOG, l’instance est démarrée en RTM, puis stoppée par le gestionnaire de services. Il faut aller jeter un coup d’œil au log du cluster. Par défaut ce log se trouve sous C:\Windows\Cluster\Reports\Cluster.log. S’il n’existe pas, il suffit de le créer dans un elevated prompt:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\sqlcluadmin>cluster log /g
Generating the cluster log(s) ...
The cluster log has been successfully generated on node 'node1'...
The cluster log has been successfully generated on node 'node2'...

Pour en savoir un peu plus, il faudra aussi activer le mode Verbose pour la ressource SQL Server, en passant la clé  HKLM\Cluster\Resources\<ID de la ressource SQL>\Parameters\VerboseLogging à 1

Puis relancer la mise en ligne de la ressource SQL Server pour pouvoir constater l’erreur dans la log:

(...)
05/24-09:07:43.951 INFO  [RCM] TransitionToState(SQL Server) OnlineCallIssued-->OnlinePending.
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] OnlineThread: enter; VirtualServerName=MYMSSQLSERVER2; InstanceName=MSSQLSERVER
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] OnlineThread: ServiceName=MSSQLSERVER
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] ClusterResourceControl, found the network name: MYMSSQLSERVER2.
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] OnlineThread: ServerName=MYMSSQLSERVER2
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Calling SQLClusterResourceWorker::WaitForCompletion (200)
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Worker thread starting ...
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Entering SQLClusterSharedDataUpgradeWorker thread.
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): SqlDataRoot = 'E:\MSSQL10_50.MSSQLSERVER\MSSQL',                                    CurrentPatchLevel = '10.51.2811.0',                                    SharedDataPatchLevel = '10.50.1600.1'
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): FTDataPath = 'E:\MSSQL10_50.MSSQLSERVER\MSSQL\FTData',                                    SQLGroup = 'S-1-5-80-3263513310-3392720605-1798839546-683002060-3227631582'
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Entering DoSQLDataRootApplyACL (E:\MSSQL10_50.MSSQLSERVER\MSSQL\Data).
00001bf0.00001cac::2012/05/24-09:07:43.951 WARN  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): DoSQLDataRootApplyACL : Failed to create directory tree at SQLDataRoot.
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Exiting DoSQLDataRootApplyACL (3).
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Exiting SQLClusterSharedDataUpgradeWorker thread (3).
00001bf0.00001cac::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Worker thread exiting (retval = 3) ...
00001bf0.00000c68::2012/05/24-09:07:43.951 INFO  [RES] SQL Server <SQL Server>: [sqsrvres] Worker Thread (A497A0): Calling SQLClusterResourceWorker::WaitForCompletion (4294967295)
00001bf0.00000c68::2012/05/24-09:07:43.951 ERR   [RES] SQL Server <SQL Server>: [sqsrvres] OnlineThread: SQL Cluster shared data upgrade failed                            (status 0, Worker retval = 3)
00001bf0.00000c68::2012/05/24-09:07:43.951 ERR   [RHS] Online for resource SQL Server failed.
(...)

On voit clairement ici qu’il y a un problème de chemin:

(...)
[sqsrvres] Worker Thread (A497A0): SqlDataRoot =  'E:\MSSQL10_50.MSSQLSERVER\MSSQL',                                     CurrentPatchLevel = '10.51.2811.0',                                     SharedDataPatchLevel = '10.50.1600.1'
(...)
[sqsrvres] Worker Thread (A497A0):  DoSQLDataRootApplyACL : Failed to create directory tree at SQLDataRoot.
(...)

En effet, pas de drive E: sur notre installation. Afin de respecter la norme du client, nous avions effectué un changement de lettre au niveau d’un des disques partagés, passant de E:\ à M:\, via la console d’administration du cluster. La modification n’avait pas été poussée dans le registre. Il faut donc le faire, sur les 2 noeuds, manuellement, sous HKLM\Softwares\Microsoft\Microsoft SQL Server\MSSQL10_50.MSSQL\Setup

Une fois les chemins modifiés, il faut remettre la ressource SQL Server en ligne et vérifier dans l’ERRORLOG que l’upgrade a bien été appliqué:

2012-05-24 11:17:44.05 Server      Microsoft SQL Server 2008 R2 (SP1) - 10.50.2811.0 (X64)
Apr  6 2012 01:59:29
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
(...)

Donc bottom-line, il faut penser à vérifier les chemins dans le registre pour les futurs upgrades lorsque l’on modifie une lettre de disque partagé dans un cluster SQL Server.

A+. David

Continuez votre lecture sur le blog :

twitterlinkedinmail

David Baffaleuf

More Posts

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.