Daniel,

No solution here, just some considerations regardless of what you end
up doing. If you have multiple clients, you probably need to deal
with the possibility that some client(s) may incorrectly judge that
connection to the primary server is not possible.

If PC1 was going up in flames then I probably would want it to be as
obvious as possible so someone would get the extinguisher ;)

Seriously though you would need to define some machine with the
responsibility of identifying when the first machine went down,
define what you mean by "going down" (ie TimeOuts and retries before
reaching the conclusion), probably run some automailer scripts to
notify someone. It would also need to adjust the dns entry of server1
to now point to server2. I doubt it will be totally seamless as the
db connection will be broken and will need to re-establish, what you
do achieve though is minimal downtime.

Adam



--- In firebird-support@yahoogroups.com, "Daniel R. Jimenez"
<d.jimenez@c...> wrote:

> Hi,
>
> I have had a look at Helen's book, but unfortunately I have not

found a

> answer, I was not expecting one, as I believe this is probably to

far of

> topic for the book.
>
> I would like know if there is a build in facility on FB 1.5.x SS,

which

> allows for full live automated DB redundancy to a separate PC (the

FDB on

> PC-2 is identical to the FDB on PC-1 at all times, 24/7), so that

if PC-1

> was to go up in flames, PC-2 could take over transparently.
>
> That is, the application will see that the connection to PC-1 is

down, so it

> would switch to PC-2, so with transparently, what I really mean, is

that our

> application(s) does not have to take responsibility for keeping the

two FDB

> in perfect sink at all times, etc.
>
> If this is not part of FB 1.5.x SS what tools do the members of

this group

> recommend?
>
>
> Thank you
>
> daniel