Tim Haynes wrote:

>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.
>
>

That's correct. When the feature was implemented, the extreme high end
of disk controllers support shadowing in firmware, but not on anything
that a sane person would call an "inexpensive disk". Shadowing was a
disaster recovery mechanism operationally more palatable than
journaling, which Interbase also supported.

>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.
>

There is nothing that needs to be done to prevent this other than
disabling of code. The penalties, as you know, are the addition time
required to perform the remote write and the danger that the remote
system will not preserve careful write. You are also correct that a
relatively slow network will slow it down, but there is no longer any
need for a slow network when the basic $329 server comes standard with a
gigabit Ethernet. [To put this in perspective, when shadowing was
implemented, the backplanes on Unix workstations were barely able to
sustain Ethernet DMA speeds.]

>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.
>
>

Lets look at this another way. Suppose Firebird write pages to a serial
file (make it even better by putting the file in flash memory) with a
separate thread or threads writing pages from the head to both the local
file and remote copies, then truncating the head after the writes had
been successfully completed. This would change bursty random writes to
bursty sequential writes (much cheaper), preserve careful write
(assuming a suitable recovery mechanism), and eliminate the need for
forced write on the main database file. The serial file could be
implemented in either disk or flash with forced writes. It would
require some internal, reasonable robust structure, probably a variation
on a ring maintaining separate read (head) and write (tail) locations.



--

Jim Starkey
Netfrastructure, Inc.
978 526-1376