Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.

There is a difference between fault tolerant and high availability. I don't
know of any system that will persist open transactions in a high
availability system. Rather, the calling program should attempt to re-try a
transaction if connectivity is lost.

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau


"Steve Kitley" <Steve Kitley (AT) discussions (DOT) microsoft.com> wrote

Hi,

From what I have read, SQL Server is per se not fault tolerant. In other
words, in a two node instance should one node fail the transactions in
progress will not automatically switchover and hit the node that is still
running, ie, there is a lag in the switching of the nodes. Does anybody
know that if we put a load balancer with a virtual ip address in front of
the
cluster would resolve this problem? Now, the load balancer can be either a
software or hardware solution, but I believe a hardware load balancer
appliance would be better.