Clusters and Log Shipping

Does anyone know of any issues with using Active/Passive or Active/Active clusters and log shipping. Will log shipping still work if a failover occurs?

Thanks

Yes, log shipping still works after a cluster failover. A failover in a cluster is basically the same as restarting your SQL Service. Assuming you have log shipping configured correctly (i.e. using the virtual instance name, which would be the case if you configured log shipping using the built-in wizards/plans), log shipping will pick up where it left off before the failover occured (i.e. the next time the t-log is backed up, it will be shipped to your shared log location for application to the standby server).

HTH

|||

Setting up log-shipping between two clusters gets a little more intricate because you have to establish the file shares log-shipping needs and although the shared disk fails over, the shares have to be setup in advance, and the node has to be the active node in order to setup the "shared disk" shares.

Clusters and Log Shipping

Does anyone know of any issues with using Active/Passive or Active/Active clusters and log shipping. Will log shipping still work if a failover occurs?

Thanks

Yes, log shipping still works after a cluster failover. A failover in a cluster is basically the same as restarting your SQL Service. Assuming you have log shipping configured correctly (i.e. using the virtual instance name, which would be the case if you configured log shipping using the built-in wizards/plans), log shipping will pick up where it left off before the failover occured (i.e. the next time the t-log is backed up, it will be shipped to your shared log location for application to the standby server).

HTH

|||

Setting up log-shipping between two clusters gets a little more intricate because you have to establish the file shares log-shipping needs and although the shared disk fails over, the shares have to be setup in advance, and the node has to be the active node in order to setup the "shared disk" shares.

Clusters and licensing in 2005

I need help with a licensing question for 2005. Assuming two servers with two
processors each:
If I have one instance on Server A in an active/passive cluster with Server
B, my understanding is that I need licenses for two processors on Server A)
If I have one instance on Server A and one instance on Server B
(Active/active cluster) my understanding is that I need licenses for all 4
processors.
If I have two instances on Server A and am using Server B for failover, how
many licenses do I need? In the case of a single instance failing over I'd
have instances running on both servers.
thanks
Your best bet is call Microsoft. The answer varies depending on your
current/future agreement with them. Various price points can exist.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
"Peter Feakins" <PeterFeakins@.discussions.microsoft.com> wrote in message
news:6ECF0749-8857-4791-A36C-025EDC6B276F@.microsoft.com...
>I need help with a licensing question for 2005. Assuming two servers with
>two
> processors each:
> If I have one instance on Server A in an active/passive cluster with
> Server
> B, my understanding is that I need licenses for two processors on Server
> A)
> If I have one instance on Server A and one instance on Server B
> (Active/active cluster) my understanding is that I need licenses for all 4
> processors.
> If I have two instances on Server A and am using Server B for failover,
> how
> many licenses do I need? In the case of a single instance failing over I'd
> have instances running on both servers.
> thanks
|||The answer from Microsoft licensing was that any multi-instance cluster is
considered to be active/active rather than active/passive, regardless of
where the instances run. In this case processors on both servers would need
licenses.
"Peter Feakins" wrote:

> I need help with a licensing question for 2005. Assuming two servers with two
> processors each:
> If I have one instance on Server A in an active/passive cluster with Server
> B, my understanding is that I need licenses for two processors on Server A)
> If I have one instance on Server A and one instance on Server B
> (Active/active cluster) my understanding is that I need licenses for all 4
> processors.
> If I have two instances on Server A and am using Server B for failover, how
> many licenses do I need? In the case of a single instance failing over I'd
> have instances running on both servers.
> thanks
|||Hi Peter,
I am not a Licensing expert but I found a Whitepaper on SQL Server 2005 Licensing that you may find helpful. Here is the link
http://download.microsoft.com/downlo..._Licensing.doc
Here is a section from the whitepaper
When doing failover support, a server is designated as the passive server. The purpose of the passive server is to absorb the data and information held in another server that fails. A passive server does not need a
license, provided that the number of processors in the passive server is equal or less than those of the active server. The passive server can take the duties of the active server for 30 days. Afterwards, it must be
licensed accordingly.
Also, found another link that you may find helpful
SQL Server 2005 Licensing: Frequently Asked Questions
http://www.microsoft.com/sql/howtobuy/faq.mspx
Here is a section from this link
Q. How does licensing work for computers that run SQL Server 2005 in failover scenarios?
A. Failover support, where servers are clustered together and set to pick up processing duties if one computer should fail, is now available in Workgroup, Standard, and Enterprise editions of SQL Server 2005.
Under each of these editions, keeping a passive server for failover purposes does not require a license as long as the passive server has the same or fewer processors than the active server (under the per
processor scenario). For details on which failover methods are available under each edition, visit the SQL Server 2005 Features Comparison page.
HTH,
Best Regards,
Uttam Parui
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection Program and to order your FREE Security Tool Kit, please visit http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their Microsoft software to better protect against viruses and security vulnerabilities. The easiest way to do this is to visit the following websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx

Clustering with 2 active nodes and 1 passive node

Normally, clustering is setup as a 1-to-1 relationship between active and
passive nodes, at least that is my understanding. We have a situation where
we are being asked to setup a 2 active node, 1 passive node environment.
Here's the question - if one of the active nodes fails, it fails over to the
passive node. Now what happens if the 2nd active node fails? Will the other
active node (originally the passive node) handle the failover or will it try
to failover to the first active node that failed or will the whole thing just
grind to a screeching halt? I know we can setup a 2 active/ 2passive node
setup, but we wanted to research the 2-to-1 possibility as well.
Thanks!
Message posted via http://www.droptable.com
Hi
You don't need a 1:1 relationship between nodes.
And forget the terms active / passive, it is totally out of date and does
not describe SQL Server 2000/2005 clustering.
You have an instance of SQL Server running on an node.
If you have 2 nodes, it could run on any of those nodes at any one time. If
you had 3 nodes, it could run on any of those nodes, at any one time.
If you have 2 nodes, one sits around waiting for a failover. If you have 3
nodes, 2 sit around waiting for a failover.
If you have more than one SQL Server instance running on the cluster, then
the instances can run on any of the nodes.
The instances could be all running on the same node, or dispersed over the
various nodes.
Quite often, people run with 3 nodes and 2 instances or 4 nodes with 3
instances. There is nothing stopping you running 3 instances on 3 nodes, 4
instances on 4 nodes, or any combination of up to 16 instances over 4 nodes.
You just need to make sure that you have enough resources, that in worst
case, one node could run all instances.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Michael G via droptable.com" <forum@.droptable.com> wrote in message
news:541CE6C54F90F@.droptable.com...
> Normally, clustering is setup as a 1-to-1 relationship between active and
> passive nodes, at least that is my understanding. We have a situation
> where
> we are being asked to setup a 2 active node, 1 passive node environment.
> Here's the question - if one of the active nodes fails, it fails over to
> the
> passive node. Now what happens if the 2nd active node fails? Will the
> other
> active node (originally the passive node) handle the failover or will it
> try
> to failover to the first active node that failed or will the whole thing
> just
> grind to a screeching halt? I know we can setup a 2 active/ 2passive node
> setup, but we wanted to research the 2-to-1 possibility as well.
> Thanks!
>
> --
> Message posted via http://www.droptable.com
|||Very helpful. Question: So now, even with RAID 10, the single point of
failure becomes the shared drive array? How does one go about creating a
failover for this?
Respectfully,
Michael Wiederhold
michael@.auctionarms.com
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%230j6BCZtFHA.3236@.TK2MSFTNGP14.phx.gbl...
> Hi
> You don't need a 1:1 relationship between nodes.
> And forget the terms active / passive, it is totally out of date and does
> not describe SQL Server 2000/2005 clustering.
> You have an instance of SQL Server running on an node.
> If you have 2 nodes, it could run on any of those nodes at any one time.
> If you had 3 nodes, it could run on any of those nodes, at any one time.
> If you have 2 nodes, one sits around waiting for a failover. If you have 3
> nodes, 2 sit around waiting for a failover.
> If you have more than one SQL Server instance running on the cluster, then
> the instances can run on any of the nodes.
> The instances could be all running on the same node, or dispersed over the
> various nodes.
> Quite often, people run with 3 nodes and 2 instances or 4 nodes with 3
> instances. There is nothing stopping you running 3 instances on 3 nodes, 4
> instances on 4 nodes, or any combination of up to 16 instances over 4
> nodes. You just need to make sure that you have enough resources, that in
> worst case, one node could run all instances.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Michael G via droptable.com" <forum@.droptable.com> wrote in message
> news:541CE6C54F90F@.droptable.com...
>
|||Hi
Most high end SAN's have a block level copy mechanism so that you can
"mirror" that data to another SAN, preferably at another location.
EMC has SRDF that can run synchronous or asynchronous over fast WAN links.
Tape backups must never be forgotten either.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"michael wiederhold" <michael@.auctionarms.com> wrote in message
news:%23RhSzuztFHA.3068@.TK2MSFTNGP14.phx.gbl...
> Very helpful. Question: So now, even with RAID 10, the single point of
> failure becomes the shared drive array? How does one go about creating a
> failover for this?
> Respectfully,
> Michael Wiederhold
> michael@.auctionarms.com
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:%230j6BCZtFHA.3236@.TK2MSFTNGP14.phx.gbl...
>
|||Thanks. Really do appreciate your participation in this newsgroup.
Respectfully,
Michael Wiederhold
michael@.auctionarms.com
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:ONHGyz8tFHA.2540@.TK2MSFTNGP09.phx.gbl...
> Hi
> Most high end SAN's have a block level copy mechanism so that you can
> "mirror" that data to another SAN, preferably at another location.
> EMC has SRDF that can run synchronous or asynchronous over fast WAN links.
> Tape backups must never be forgotten either.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "michael wiederhold" <michael@.auctionarms.com> wrote in message
> news:%23RhSzuztFHA.3068@.TK2MSFTNGP14.phx.gbl...
>

Clustering Question...

Say I have a current standalone SQL 2005 node that is SAN attached.
How can I get it clustered by adding a passive secondary node to it ? Can I
do so ? Or do I have to setup an entirely 2 new clustered set of servers and
move the database from the standalone server to it ?
I am trying to avoid buying 2 new servers and move the database across but
would like to just add another node to the existing standalone server and
get it clustered. If this is possible, how can I do it ?
Clusters have built from the ground up. You can't make it a cluster after
the install of SQL. Migrate to a new cluster, built from the ground up, that
is the best option.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"Hassan" <Hassan@.hotmail.com> wrote in message
news:%23PKJjfJHHHA.3872@.TK2MSFTNGP06.phx.gbl...
> Say I have a current standalone SQL 2005 node that is SAN attached.
> How can I get it clustered by adding a passive secondary node to it ? Can
> I do so ? Or do I have to setup an entirely 2 new clustered set of servers
> and move the database from the standalone server to it ?
> I am trying to avoid buying 2 new servers and move the database across but
> would like to just add another node to the existing standalone server and
> get it clustered. If this is possible, how can I do it ?
>
>
|||Just to expand on what Rodney said, it is possible to create a cluster from
existing equipment, but it is neither desirable nor supported. The
potential disruption during the install and migration process will likely
cause some unplanned downtime, which defeats the entire purpose of a
cluster. It is best to start from a clean slate and migrate the data into
the new system.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Rodney R. Fournier [MVP]" <rod@.die.spam.die.nw-america.com> wrote in
message news:ODTKVxJHHHA.4804@.TK2MSFTNGP03.phx.gbl...
> Clusters have built from the ground up. You can't make it a cluster after
> the install of SQL. Migrate to a new cluster, built from the ground up,
> that is the best option.
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://www.msmvps.com/clustering - Blog
> "Hassan" <Hassan@.hotmail.com> wrote in message
> news:%23PKJjfJHHHA.3872@.TK2MSFTNGP06.phx.gbl...
>
|||What you can do, however, if you are willing to live with a new network
name, is to build a new single-node cluster and install SQL Server on it.
After migrating the databases to this new host, you can then rebuild the
original server and then have it joined to the new cluster as a new cluster
node.
This last bit has very specific steps. Look them up in Books Online or
TechNet. I even think I have a detailed list lying around this new group
somewhere. If I find it, I'll shoot it out to you.
Anyway, this should save you the cost of buying a third server.
Sincerely,
Anthony Thomas

"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23WajdlSHHHA.960@.TK2MSFTNGP04.phx.gbl...
> Just to expand on what Rodney said, it is possible to create a cluster
from[vbcol=seagreen]
> existing equipment, but it is neither desirable nor supported. The
> potential disruption during the install and migration process will likely
> cause some unplanned downtime, which defeats the entire purpose of a
> cluster. It is best to start from a clean slate and migrate the data into
> the new system.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "Rodney R. Fournier [MVP]" <rod@.die.spam.die.nw-america.com> wrote in
> message news:ODTKVxJHHHA.4804@.TK2MSFTNGP03.phx.gbl...
after[vbcol=seagreen]
Can[vbcol=seagreen]
server
>

Clustering

If i have an active\passive cluster for SQL Server, under what circumstances would it prompt to automatic changeover to the passive cluster ? Failure of the SQL Server, or let's say 1 user database out of 25 becomes suspect?It would require a failure of the entire SQL Server. Individual databases can be brought online and offline all throughout the day. A failover is only done when one of the cluster resources has failed.

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henry
cross-posted to microsoft.public.sqlserver.clustering
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:

>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is the
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
HenryThis is a multi-part message in MIME format.
--030309070404030102020809
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
cross-posted to microsoft.public.sqlserver.clustering
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:
>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is the
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>
--030309070404030102020809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>cross-posted to microsoft.public.sqlserver.clustering</tt><br>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Henry wrote:
<blockquote cite="midE64C9F95-F0A5-42B5-A7AD-3CE7515EB4FE@.microsoft.com"
type="cite">
<pre wrap="">Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is the
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henry
</pre>
</blockquote>
</body>
</html>
--030309070404030102020809--

Clustered SQL Server shut down for third-party application install

Dear Sir,
If I needed to install something to the active then passive node one by one
and required to restart the server serveral times during install, what is th
e
procedures if I don't want SQL Server to auto startup during reboot?
Steps:
01) Offline "passive" node from cluster admin.
02) Shut down "passive" node server.
03) Offline "active" node SQL Server Group
04) From OS Services, change SQL Server to "Not auto startup"
05) Install application
06) Reboot active server
07) ....
Is the above procedures ok?
Please advise! Thanks!
Henrycross-posted to microsoft.public.sqlserver.clustering
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Henry wrote:

>Dear Sir,
>If I needed to install something to the active then passive node one by one
>and required to restart the server serveral times during install, what is t
he
>procedures if I don't want SQL Server to auto startup during reboot?
>Steps:
>01) Offline "passive" node from cluster admin.
>02) Shut down "passive" node server.
>03) Offline "active" node SQL Server Group
>04) From OS Services, change SQL Server to "Not auto startup"
>05) Install application
>06) Reboot active server
>07) ....
> Is the above procedures ok?
>Please advise! Thanks!
>Henry
>
>

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

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

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

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

Clustered SQL Server 2000 to 2005 Upgrade

I would like to upgrade a production active/passive SQL Server 2000 cluster to SQL Server 2005.

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