--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@...> wrote:

>
> Dimitry Sibiryakov wrote:
>
> >On 2 Feb 2006 at 11:08, m_theologos wrote:
> >
> >
> >
> > I don't think so. Because you can't control network buffers
> >shadowing to another computer either lead to slowdown (if FB will
> >wait till the data is really written to the shadow) or broken shadow
> >if the server crashed before sending data from buffers.
> >
> >
> We used to shadow across NFS and we never had a problem. It is true
> that it significantly adds to the effective page write time, but

careful

> write handles the case of the primary system crash case. A crash of a
> remote shadow server would require that the shadow be rebuilt, but
> that's to be expected because the primary server has to continue anyway.
>
> If shadow propogation were delegated to a separate thread rather than
> performed inline, the overhead would disappear provided the network
> bandwidth was up to the effect disk write bandwidth.
>

Is easy for you to do it?

> The downside of shadowing is that like NBak, if the database get
> corrupted, you have N equally corrupted copies.
>

Of course. I think that NO ONE will replace the _real_ backup with the
shadows. The shadows (in this discussion, at least) is to minimize
downtime in the case of server crash.

> > I think that currently there is only one real way to decrease
> >downtime with FB (and IB) - replication. But neither method guarantee
> >against data loss. When you use replication and server crashed you'll
> >lose data that is not replicated yet. If you use shadowing you may
> >lose whole database if the shadow become inconsistent (broken).
> >
> >
> I think this is a much better approach, all in all. It makes better

use

> of network bandwidth, allowing geographical distribution of replicants
> in case of wide spread disaster. This may seem a little far fetched,
> but replication to a machine in a distant bunker is accepted

business ...

I proposed the shadow sollution because is easy to implement (AFAIK).
Of course, better, IMHO is to have on the main server let's say S1 a
client for the shadow server S2 and to send to him only the commands
which changes the data (ie. not SELECTs) and let the fbserver from S2
to manage the shadow db. (in fact a middleware on the server side).

What do you think?

m. Th.

P.S.: Why do you say that the replication is more efficient on net
b/width? On the shadow file the server doesn't propagate (apply) the
changes only?