Does SQL server support failover without sahred disk or external storage

Hi fellow,
I'd like to know if is it possible to configure SQL Server in a cluster enviroment to provide failover, without using shared disks or external storages.
What I wish is setup and cluster to provide failover in case of a hardware malfuction only between servers A and B. The data "integrity" however will be guarantee by my application. I only wish to provide my clients an transparent and automatic way to c
onnect to server B in case of failure of server A, behaving just like the virtual server in a cluster enviroment.
Anyone knows if this is possible?
Cheers,
Eric.
SQL does not have such a feature. The SQL failover cluster model requires a
common dagta store that can be arbitrated between nodes so that a single
node failure is recoverable.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Eric" <anonymous@.discussions.microsoft.com> wrote in message
news:8F02A739-E588-4C27-9CF2-63999EFBE802@.microsoft.com...
> Hi fellow,
> I'd like to know if is it possible to configure SQL Server in a cluster
enviroment to provide failover, without using shared disks or external
storages.
> What I wish is setup and cluster to provide failover in case of a
hardware malfuction only between servers A and B. The data "integrity"
however will be guarantee by my application. I only wish to provide my
clients an transparent and automatic way to connect to server B in case of
failure of server A, behaving just like the virtual server in a cluster
enviroment.
> Anyone knows if this is possible?
> Cheers,
> Eric.
|||Yes, SQL Server does support failover in that situation. It will not
operate exactly like a virtual server in a cluster environment.
You can use either replication or log shipping to create the second copy of
the database on Server B. Each will have latency as far as what data
exists. Each one has different processes for failing over as well as
failing back. If you search back across this newsgroups and the replication
newsgroup for the last 2 months, there will be more than enough information
posted about that subject.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||Hi Michel,
The replication and log shipping solves the problem of keeping data between servers ok, but my point is related to the client.
Is there a way to make the client service start using the second server automatically in case of server A failure? For example, my apllication use ODBC to connect to DB_SERVER, wich will be directed to Server A only if it is availble. If not, then DB_SE
RVER will point automatically to Server B. The Client is unware of any change, just like a failover cluster.
Cheers,
Eric
|||Not in the current version of SQL Server. However, database mirroring in
Yukon may be of interest to you. Have a look here:
http://www.microsoft.com/technet/pro...n123121120120.
Of course, the downside is that Yukon won't be available until next year...
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Eric" <anonymous@.discussions.microsoft.com> wrote in message
news:32D7E78D-55B4-4B49-A1FE-2385D41E9BA0@.microsoft.com...
> Hi Michel,
> The replication and log shipping solves the problem of keeping data
between servers ok, but my point is related to the client.
> Is there a way to make the client service start using the second server
automatically in case of server A failure? For example, my apllication use
ODBC to connect to DB_SERVER, wich will be directed to Server A only if it
is availble. If not, then DB_SERVER will point automatically to Server B.
The Client is unware of any change, just like a failover cluster.
> Cheers,
> Eric
|||Nope to the original question and no even to database mirroring.
If using replication or log shipping, you will have to write code into you
application to detect it, redirect, and reconnect.
When Yukon ships and if database mirroring is in the product, when the
primary fails, you will be disconnected. You will then have to reinitiate
the connection. You just won't have to redirect to a different server name.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||From Lubor's presentation at the PASS Summit (public info here), there is
supposed to be client library awareness so that an automatic, transparent
shift happens with database mirroring.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:%23ukY8TiLEHA.3096@.TK2MSFTNGP11.phx.gbl...
> Nope to the original question and no even to database mirroring.
> If using replication or log shipping, you will have to write code into you
> application to detect it, redirect, and reconnect.
> When Yukon ships and if database mirroring is in the product, when the
> primary fails, you will be disconnected. You will then have to reinitiate
> the connection. You just won't have to redirect to a different server
name.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>
|||Yes, there is supposed to be client library awareness. The feature is
currently called "transparent client redirect". The transparent redirect
part is that an application doesn't need to change names. It is called
"redirect". It is not called "reconnect". The information is in the PASS
session you refer to. The same basic information with a few extensions is
also contained in a database mirroring session I did in London at DevWeek as
well as in Vienna at XtremeSQL.
There is also a very big word of caution here since this has the potential
to head the wrong direction. Yukon is still in Beta 1. Beta 1 is still
NDA. The only thing allowed to be discussed is what is publicly released.
Outside of that, there are a small group of people authorized to talk about
it. At this point, it is best to not even discuss Yukon features or
functionality. If there are specific questions on Yukon, they can be asked
in "other venues".
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||I am very aware of my NDA obligations on Yukon. I only discuss items where
I can refer to a public statement by an authorized Microsoft representative,
such as the Beta 1 presentations at PASS.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:%23O$GGamLEHA.3324@.TK2MSFTNGP10.phx.gbl...
> Yes, there is supposed to be client library awareness. The feature is
> currently called "transparent client redirect". The transparent redirect
> part is that an application doesn't need to change names. It is called
> "redirect". It is not called "reconnect". The information is in the PASS
> session you refer to. The same basic information with a few extensions is
> also contained in a database mirroring session I did in London at DevWeek
as
> well as in Vienna at XtremeSQL.
> There is also a very big word of caution here since this has the potential
> to head the wrong direction. Yukon is still in Beta 1. Beta 1 is still
> NDA. The only thing allowed to be discussed is what is publicly released.
> Outside of that, there are a small group of people authorized to talk
about
> it. At this point, it is best to not even discuss Yukon features or
> functionality. If there are specific questions on Yukon, they can be
asked
> in "other venues".
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>