Hope this is the right place to post an improvement suggestion. Apologies
if I am mistaken.

A feature which looks very attractive at first sight is the shadow database,
maintaining an immediately available copy of a database on another volume to
allow recovery from disk failure. I can see how this might have been needed
once, but with RAID now incredibly cheap this seems to be rather defunct.

What would make it very powerful is if the shadow database volume could
reside on another computer, allowing immediate recovery on an alternate
machine in the event of the failure of the primary server. This is what I'm
looking into, as I really need a resilient solution. The Firebird Book
indicates that this is possible using NFS, but sadly appears to be disabled
for Windows shares. Also, as far as I can see, any interruption to the
connection would destroy the shadow. I also suspect that the (relatively)
slow network write could really slow things down.

What would be REALLY useful would be to queue shadow database updates so
that a shadow can be effectively maintained on second machine. I would
imagine that this could be fairly easily done by queueing via disk files.

For example: at present new/changed blocks of data are written directly to
the shadow database. Instead, the database server could simply write each
to a separate file, with a suitable sequence number and block number in the
filename. A process on he second machine could poll this disk area (via
nfs, windows share, ftp etc) and simply merge the new blocks of data into
the shadow database file held on that second machine. OK, maybe that's a
litle simplistic (too many small files) but something similar should work -
perhaps a file per transaction or somesuch.

Any mileage in something along these lines? Right now the whole
resilience/failove thing is a big decider in my database choice and Firebird
seems so very close...

Cheers,

Tim