t_j_haynes wrote:

>Have to agree that trigger based replication is a lot more flexible -
>but it's arguable that this very flexibility allows far more scope
>for error.
>
>Setting up a shadow is really easy and it should be relatively simple
>to allow it to shadow to an adjacent computer over a dedicated
>gigabit network cable without trashing the shadow if the other
>machine is unavailable for a few seconds or minutes.
>
>

It's a lot more complicated than that. If the connection drops, there
has to be a resynchronization mechanism to bring the shadow back in
sync, meaning that state must preserved both on the shadow and primary
systems as well as a mechanism for the shadow machine to identify
itself. Keep in mind that if the the shadow machine crashed, it may be
necessary to go back a repeat a sequence of pages to make sure every one
gets copied. Clone a new copy is an alternative, but a little pricey on
a hundred gig database.

But it could be done, of course. But I don't see anybody jumping up and
down to take this on, particularly since much of what shadows once did
is now handled better by RAID.

There is no question, however, that disaster recovery must be one of
Firebird's highest priorities.

>The nearest I have to a performance comparison is between shadow
>mechanism and stnadards triggers. Daabase write time to a single
>table rose ~30% with a shadow, and over 100% using a trigger to copy
>changed records. It seems to stand to reason that the raw disk block
>level version should be faster, but I haven't tried your idea of
>taking the processing to an external process, so I'll have a look.
>
>

There will always be a tradeoff between bandwidth and cpu. If you're
doing replication over a gigabit ethernet, you don't care about
bandwidth. If you're replicating over a modest speed line to machine in
a bunker 40 miles aways (as one of my customers does), you do care about
bandwidth.

RAID is cheapest, shadows next, and replication the most expensive. You
get what you paid for.

>Still - guess I have to live with what's there!
>
>
>

Then you are definitely on the wrong list. The developer's list is for
people who aren't content with what's there.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376