recovering from a clustered node failure

We are running SQL Server 2000 and we had a node failure
on one of our secondary nodes. The node was evicted from
the cluster, and the hardware was rebuilt. When we try to
re-setup the node, we follow the steps listed below.
1. Insert the SQL Server 2000 Enterprise Edition compact
disc in your CD-ROM drive. Select Install SQL Server 2000
Components.
2. Click Install SQL Server 2000 Components, click Install
Database Server, and then click Next.
3. On the Computer Name dialog box, select Virtual Server,
and enter the name of an existing clustered instance of
SQL Server 2000.
4. On the Installation Selection dialog box, select
Advanced options, and then click Next.
5. On the Advanced Options dialog box, select Maintain a
Virtual Server for Failover Clustering, and then click
Next.
6. On the Failover Clustering dialog box, click Next.
7. On the Cluster Management dialog box, select node 2 to
add back into the cluster so that both your nodes show up
on the right pane window.
8. On the Remote Information dialog box, enter the user
name and password for the domain administrator account
used for the clustered instance of SQL Server 2000, and
then click Next.
9. When the process is complete, click Finish.
Having clicked Next after step 8, the installation just
dissappears and SQL never gets installed on the secondary
node. Any thoughts?
Also - can you confirm that it's possible to recover a node without having to de-install the virtual servers (active/active setup) and re-install, as this would mean extended outage on the databases..
Thanks indeed.
Yes, you can recover from a node failure. There are precise step-by-step
instructions in BOL for exactly this scenario. Look under 'Maintaining a
Failover Cluster' for Recovering from Failover Cluster Failure. The key
step that you may have to redo is to run the install app to remove the
failed node from the SQL virtual server. This is in addition to the node
eviction and replacemnet you have already done. Once the node is
uninstalled, you can then install SQL on the replacement node.
You can also re-apply Service packs to the new node only without taking the
Virtual SQL instance offline. Check the Service Pack README file for
details.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Martyn Cavett" <anonymous@.discussions.microsoft.com> wrote in message
news:8D25D32F-7ECF-4BCC-8827-BFBE4D973844@.microsoft.com...
> We are running SQL Server 2000 and we had a node failure
> on one of our secondary nodes. The node was evicted from
> the cluster, and the hardware was rebuilt. When we try to
> re-setup the node, we follow the steps listed below.
> 1. Insert the SQL Server 2000 Enterprise Edition compact
> disc in your CD-ROM drive. Select Install SQL Server 2000
> Components.
> 2. Click Install SQL Server 2000 Components, click Install
> Database Server, and then click Next.
> 3. On the Computer Name dialog box, select Virtual Server,
> and enter the name of an existing clustered instance of
> SQL Server 2000.
> 4. On the Installation Selection dialog box, select
> Advanced options, and then click Next.
> 5. On the Advanced Options dialog box, select Maintain a
> Virtual Server for Failover Clustering, and then click
> Next.
> 6. On the Failover Clustering dialog box, click Next.
> 7. On the Cluster Management dialog box, select node 2 to
> add back into the cluster so that both your nodes show up
> on the right pane window.
> 8. On the Remote Information dialog box, enter the user
> name and password for the domain administrator account
> used for the clustered instance of SQL Server 2000, and
> then click Next.
> 9. When the process is complete, click Finish.
> Having clicked Next after step 8, the installation just
> dissappears and SQL never gets installed on the secondary
> node. Any thoughts?
> Also - can you confirm that it's possible to recover a node without having
to de-install the virtual servers (active/active setup) and re-install, as
this would mean extended outage on the databases..
> Thanks indeed.
>