Dimitry Sibiryakov wrote:

>>Create shadow <...> \\<Server>\<Share>\MyShadow.sh
>>
>>IMHO, this is rather simple to achieve and then we have a sort of RAID
>>between computers which can be very "usefull" when a server fails.
>
>
> 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.
> 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).

The main problem having shadow on the remote computer is even not need
to wait for a data to be really written to the shadow. With 1GBit link
between servers one has data transfer speed higher than can be achieved
with almost any HDD. And if you use NFS mount you can create remote
shadow and use it as a kind of RAID. But NFS has special mount parameter
- sync/async. With sync as the default. I'm not sure do MS servers
support same feature or not, but default is well known - file is
buffered at the client side. Certainly, it breaks safe write order.

A number of our clients work with NFS-based shadows, and statistic is
the following. There were approximately about 9 power-failures analyzed
during 3 years, and in 4 cases main database was broken up to being
unrecoverable with gfix/backup/restore process. Shadow has always been
health. Therefore if we can guarantee safe write order over MS network,
I don't see big problems having such shadows.