1

I've got an odd issue with a SQL 2012 cluster. The cluster itself uses FC shared storage, and generally works perfectly. The SQL service works, and failover occurs as expected.

The issue I have is that the inactive node occasionally tries to access the shared storage. This throws an eventlog error similar to:

MSSQLSERVER: 17058: initerrlog: Could not open error log file 'G:\MSSQL11.MSSQLSERVER\MSSQL\Log\ERRORLOG'. Operating system error = 3(The system cannot find the path specified.)

This error will sporadically occur between 8-12 times over a 3 second period and G: is one of the shared disks.

It looks like the inactive node is trying to start the service, and failing because it can't write to the shared storage, because it doesn't own it. What could be causing this?

growse
  • 8,020
  • 13
  • 74
  • 115
  • Is the shared storage also configured as a cluster shared volume? – Chris McKeown Jul 04 '12 at 22:00
  • It is. It happily fails over between the two nodes. – growse Jul 04 '12 at 22:28
  • Is this required for SQL 2012? The nature of Cluster Shared Volumes is that a single LUN can be written to by both nodes at the same time (it enables Live Migration in Hyper-V). I can't see this being a good thing in an instance where there needs to be only one exclusive owner of a LUN. – Chris McKeown Jul 04 '12 at 22:42
  • Ah, apologies, I misunderstood. I thought you meant 'is the volume configured as a failover cluster resource'. I didn't realise that a 'Cluster shared volume' was an actual thing. So, it is configured as a failover cluster resource, it is *not* configured as a cluster shared volume. Cluster shared volumes are, in fact, disabled. – growse Jul 05 '12 at 10:14

0 Answers0