t_j_haynes wrote:

>>What exactly do you want? Are you looking for physical replication
>>(which is what shadows are), logical replication, or just something
>>that supports hot rollover? Could you be specific about your
>>objects to IBReplicator and other (potention) trigger based
>>replication schemes?
>>
>>
>
>To ensure continuity of service, the ideal would be to have a quickly
>recoverable copy of the main database maintained on another machine,
>so that in the event of an outage on the main server, a standby can
>be quickly started up. A shadow on another machine would be ideal,
>but it would need to withstand occasional network glitches and
>reboots, so some sort of update queueing mechanism would be needed -
>probably just using disk files.
>
>

Given a choice between a more robust shadowing and replication, I'd go
with replication. Replication is more flexible, allowing cascades for
example, uses less bandwidth (though this should be a significant
consideration), and allows database activity to take place on a replicant.

When I faced the question fresh in Netfrastructure, I implemented the
shadow mechanism (next to trivial) but use it only to clone an active
database, and implemented a strong foundation for application level
replication. Among the things to support the latter were multi-table
triggers, super-cheap metadata access for replication triggers, and blob
repositories support multiple references to blobs to eliminate blob
copies when writing to the replication log.

Replication for availability is more than just replication. It also
requires a clean failover mechanism and an acceptable way to bring
servers back on line.

>Trigger based replication is great if you want selective replication
>of parts of database, but a lot slower for replicating everything.
>It also requires constant maintenance, whenever tables are added,
>nodified etc.
>
>
>

Without evidence, I can't understand how you made that judgement. The
work required is the same whether it is hardcoded inside the engine or
executed inside a trigger. I don't think there is any doubt that
trigger based replication is more flexible.

As for administration, I will consider that the existing trigger
language is less than optimal, but Java based, multi-table triggers with
fast metadata access eliminate almost all of the problems.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376