what happens when the public connection is lost?

#1

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to each
of the nodes on monday and restart the cluster admin service. Once this was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried to
fail-over to node2. Node2 could not communicate won the public connection so
it tried to fail-ove to node1. This flip-flopping happened a few more times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up and
remove themselves from the cluster thus requiring the restart of the cluster
services?
--
MG

#2

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#3

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#4

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#5

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#6

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#7

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#8

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#9

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG

#10

What happened is an underlying resource failed so SQL tried to find a node
where the resource existed. Eventually it would have exhausted the retry
count and "given up". IF SQL fails to start or restart a given number of
times within a certain time period (both adjustable using the cluster tool),
the clustered resource will be considered unrecoverable and will require
manual restarting.

--
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP

"Hurme" <michael.geles (AT) thomson (DOT) com> wrote

Quote:

A SQL 2000 db on W2K3 cluster with 2 nodes lost it's public connection over
the weekend. Both VIPs were unpingable. I was able to rdc directly to
each
of the nodes on monday and restart the cluster admin service. Once this
was
done the VIPs were reachable again.

I'm trying to understand what happened here. There are messages in the
event log that show that Node1 lost it's public connection and then tried
to
fail-over to node2. Node2 could not communicate won the public connection
so
it tried to fail-ove to node1. This flip-flopping happened a few more
times
before another message appeared indicating the cluster could once again
communicate on the public conn. However, now of the apps were able to
connect to the db.

After a certain number or trys, did both of the nodes eventually give up
and
remove themselves from the cluster thus requiring the restart of the
cluster
services?
--
MG