One way to prevent the mirror failover is:
- Pause Mirroring with
ALTER DATABASE XYZ SET PARTNER SUSPEND
- Move the SQL instance
- Resume mirroring with
ALTER DATABASE XYZ SET PARTNER RESUME
The instance is failing over to the mirror because both the witness and the secondary can no longer see the primary instance.
It sounds like you are attempting to recreate SQL Server 2012 Availability Groups by combining mirroring and clustering.
Database mirroring only times-out on so-called "soft" errors. Hard errors, like a cluster failing over are reported to the mirroring session immediately causing the immediate failover. Read more at http://msdn.microsoft.com/en-us/library/ms190913.aspx
Possible causes of hard errors include (but are not limited to) the following conditions:
A broken connection or wire
A bad network card
A router change
Changes in the firewall
Endpoint reconfiguration
Loss of the drive where the transaction log resides
Operating system or process failure
Conditions that might cause mirroring time-outs include (but are not limited to) the following:
Network errors such as TCP link time-outs, dropped or corrupted packets,
or packets that are in an incorrect order.
A hanging operating system, server, or database state.
A Windows server timing out.
Insufficient computing resources, such as a CPU or disk overload, the transaction
log filling up, or the system is running out of memory or threads. In these
cases, you must increase the time-out period, reduce the workload, or change
the hardware to handle the workload.
For more information about mirroring and potential issues, you might want to see my question What can cause a mirroring session to timeout then failover? SQL Server 2005
Windows Server 2008 (no R2) did ship a 32-bit variant of the OS (last one MS shipped that way). So you can cluster it. You can install a 32-bit FCI on a 32-bit node. You cannot install a 32-bit FCI on a 64-bit node. So no, what you want is not possible. If you need a 32-bit FCI, install it on a 32-bit OS.
Best Answer
There really isn't a short answer because there are a few hidden questions in the question.
A few thoughts to help here:
1.) The Browser service is not cluster aware, so it generally would be just running on each node. The browser is really used to handle incoming connections to a SQL instance. When you don't have a fixed port, are using named instances and in other situations the browser handles the "finding" of the instance a client desires to connect to. So if you have it running on the active node and it is being used to direct connections, I would make sure it is automatic and running on each node.
2.) That said the browser shouldn't prevent DLLs from being found or take any part in preventing or allowing a failover. So the issue you are having with failing over is most likely not related to the browser but something else. Instead you should be looking at things like - Have you failed over before? Is this a new install of a second node? Have there been any required restarts missed on that node? Did the install throw up any errors? Are there issues in the clustering logs? Can you post the exact error you are receiving? Have you searched for that exact error?