Daniel R. Jimenez wrote:

>Hi Alexander,
>
>If the db app has knowledge regarding the primary FDB and the secondary FDB
>(so it would normally connect to PC-1, but if it becomes un-available it
>will connect to PC-2), and we decide that replication is the way to go, how
>do you deal with the following scenario?
>
>If PC-1 is the main FDB and it became unavailable due to network problems
>and 72 hours later if came back on line (the db app will now see PC-1 as
>available and it will connect to it, as it is the main/primary DB), how
>would you setup the replication so that PC-1 would be updated from PC-2,
>since PC-2 has the latest most recent set of data? And normally the
>replication would take place from PC-1 to PC-2? Please remember that this is
>to be transparent, so minimal user interaction.
>
>
>daniel
>
>
>
>
>

Daniel,

All I am talking about is theory, I have no pratical experience in
replication.

If you replicate in one-way, the PC-2 will be automatically update for
every PC-1 modification (yes replication could be done on-line). There
are cases to handle, like PC-1 lost connection to PC-2, etc. But lets
assume the PC-1 always see PC-2.

The on-line replication will take care to keep PC-2 in sync. When
clients lost connection to PC-1 it will try to reach PC-s (note what
Adam said about false positive PC-1 failure).

In this case, if PC-1 comes back 72 hours later the clients should not
connect to it until "someone" re-enable it. I think something like this:
Client connects to PC-2 asks if it's the primary, if not connects to
PC-1 (this should be true every time)
PC-1 turned in smoke and ashes
Clients lost connection to PC-1
Then NEEDS to connect to PC-2, after this some flag must be set on PC-2
to make it the primary (your application could handle this)
New connections to PC-2 asks if it's the primary (now the answer will be
positive), so no client will atempt to connect to PC-1
The fireman gets in the building extinguish the fire and the sysadm put
back PC1 on-line (the clients will still connect to PC-2)
The DBA brings back PC-1 up to date, mark PC-2 as not primary server
Now clients connects to PC-2 receive a bad response for it be the
primary and go to PC-1
Rinse and repeat :-)

BUT, if you want a more secure, error prone, automatic environment (and
get load share as a gift) you set replication two-way, this way the
client could connect to any of the servers (PC-1 or PC-2), if one of
these get down, then the clients you only connects to the other, when it
get back on-line, the replication engine will syncronize it again (this
time may vary from a few seconds to some hours, depends on the amount of
data that needs to be syncronized). As always you could set a flag to
forbid clients to connect to that server until it is up to date.

Two-way replication bring a big challenge (that's the reason I don't
used it until now) when I needed replication, I needed it 2-way, and I
thought it will be dificult to handle (then I went the Terminal Server
way for remote access :-) ).

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.3.2 - Release Date: 31/05/2005