I've read all of the documentation I could find, and doing an in-place upgrade seems to be the way to go. (Despite the fact it scares the hell out of me. 
But throughout all the documentation, I've yet to see some simple and fairly important questions answered.
How does the process of upgrading SQL Server work when you're dealing with a cluster?
Do you upgrade one machine then the other? If so, do you upgrade the active node first, or the passive node?
What happens if you're forced to failover from one instance to the other before you've had a chance to upgrade both to 2005? In other words, you failover from 2005 to 2000. Would that even work?
What happens if your upgrades fails for some reason? Is it easy to rollback the installation? If not, will reinstalling SQL Server 2000 cause any issues? Will it remember the previous configuration and simply fix the broken install?
Any help/insight would be greatly appreciated.
Can anybody offer any advice on this?|||Moved to ...Availability forum.|||Maybe I can help. I, along with our network admin, spent a solid 2-3 weeks working on upgrading a active/active cluster to SQL 2005 from 2000. From my experience, it was incredibly simple, yet ridiculously hard. Unless you have every single setting correct on the cluster you will likely run into problems....we did. Here is how we eventually were successful:
1. Fail all active nodes over to one node (I'll call the primary node).
2. Make sure MSDTC is a clustered resource on the cluster. ( we can a test cluster setup and forgot to do this).
3. Install the upgrade to the primary node. There was a little bit of ambiguity when running the install that makes you think that it is going to install it on the 2nd node as well. In my situation, it didnt.
4. After installing on the first node, reboot.
5. Fail over all nodes to the 2ndary node and install the upgrade.
6. Reboot.
7. Failover to primary and install the service pack.
8. Reboot.
9. Failover to the 2ndard and install the service pack.
I am pretty sure these are the steps we followed that worked for us. Most likely, this isn't the recommended course of action of making the upgrade, but it worked. Make sure that when you do install the upgrade, that you install the SQL client tools on the first node. If you don't, you will run into problems later.
If someone else has had a better experience and would like to share their steps to success, please, please do.
Hope this helped,
Tim|||Thanks for your insight. It is incredibly frustrating that there is almost no documentation on this process.
I'm a little confused by your process. You say in step 4 that after you install you should reboot the first node. Does this mean you have downtime or does this cause a failover to other nodes? (I assume it doesn't since you forced the failover to the primary node before starting the process.)
You say in step 5 that you fail over to the secondary node. So this means you're failing over from SQL Server 2005 (on the primary) to SQL Server 2000 (on the secondary). If that works, can we simply fail over to the secondary before we reboot during step 4, thereby avoiding downtime?
Your situation is slightly different than mine since my cluster is active/passive with just two machines. Using your process as a template, mine would look something like:
1.) Install the upgrade on node 1.
2.) Force a failover to node 2 (which is still running SQL Server 2000).
3.) Reboot node 1. Wait for node 1 to restart.
4.) Install the upgrade to node 2.
5.) Force a failover to node 1.
6.) Reboot node 2.
Does this seem correct?
|||
RMD: Did you complete this successfully following your steps? We have the same configuration you do and any previous experience advice would be helpful.
thanks
No comments:
Post a Comment