Replicator comments

Randy Eash  writes:
> 
> I am looking for replicator stories.  Good, Bad, Horror.  Is anyone using 
it?
> 

Randy,

Quite a number of sites are using it in the UK. When I worked for Ingres 
consultancy (UK) - prior to CA's takeover - I was sent to many sites to 
install, configure, tune (lots and lots of tuning ;-) ), etc Replicator 
configurations.

Replicator is very flexible (you can basically do whatever you want, 
wherever and however ) but, because it uses KM rules and procedures it 
involves relatively high i/o and processing for each row update to be 
replicated.

It is therefore *VERY* important to get the pre-replicated system tuned and 
efficient and design your replication configuration 'correctly'.

If you've got a problem system, doing loads of updates and you want to 
replicate in real time - you're gonna have problems. If you've got a tuned 
system and spare i/o and CPU capacity you may not even notice it.

There are things that can be done once you've got the system installed to 
increase throughput (some of the replication catalogs can encounter locking 
problems but changing the structure to a sparse HASH can alleviate these).

Good luck,

-- 
Graham Parsons
Principal Consultant
Forest Consulting Limited





bryant@mpr.ca (Nick Bryant) wrote:

>Any info, good or bad or just hearsay would be graciously appreciated.

>Nick Bryant
>bryant@mpr.ca

Here's a bit of a Horror one:

We wanted to replicate most of a largeish database (2 Gig, 350 tables)
to a second host to reduce the impact of on-line ad-hoc queries on the
main application.  Thought this would be a pretty simplistic
situation for replicator to handle. That is a one-way, read only
copy.

Problem number one - replicator (for 6.4/05) can't handle table or
column name greater than 20 chars, without modification of
replicator's own templates, and even with this modification the best
you get is 23 chars.  This meant a number of our tables had to be
re-created with shorter table and/or column names.  To avoid
immediated reprogramming of a 26 Mbyte application, we then had to
create views which looked like the original tables so that the
application would still function.

After all this stuffing around, and some to and fro with the
replicator setup, whenwe eventually were able to fire up replicator,
we had got ourselves in a situation where the target and source data
bases and the intervening replicator tables were out of sync.  This
turned nasty,  we found that replicator was generating some internal
error messages that weren't in its own message tables, and that the
multi-database multi session application that drives it was getting
confused in it session switching and WRITING back to the original
tables in the source database.  Sent CA back to the drawing board to
sort that one out, and wiped replicator off the system.  Still have
not completely recovered from all the stuffing about with table and
column names.

Did notice that with the data capture side of replicator running, our
locking problems (which were already bad) got quite a bit worse.  This
is obvious when you look at the replicator architecture, which relies
on a single central table to keep track of all the transactions it
must issue to the target databases.

To be positive, I still intend to use replicator to get ad-hoc queries
away from the main application and database, but will probably wait
until I've installed OpenIngres and checked out it's version of
replicator.  (which I hear, has done away with the 20 char limit on
names).  That is, if we can ever get the sales people here to talk to
us. 

Tassie.

_______________________________________________________________
Stephen (Tassie ) Ranson                   sranson@pcug.org.au 
Phone (06) 293 3494                  Intl Phone +61-6-293 2494            
Fax (06) 293 2081                      Intl Fax +61-6-293 2081
WWW URL http://www.pcug.org.au/~sranson




Brian Parker wrote:
> 
> Anyone had experience of Ingres/Replicator (Open or rel6)?
> What applications have you used it for?
> What problems or design opportunities did you encounter?
> 
>     Brian

Brian,

I have worked with Ingres/Replicator for a number of clients. A few of the 
big issues which spring to mind are listed below. No doubt others will add to 
this list...

* Any replication scheme (regardless of what product is used) will add a 
significant processing load. Therefore keep it simple ! Question whether 
on-line replication is required (or periodic refreshes ?), can Read-Only 
replication be used rather than Peer-to-Peer, is Collision Resolution really 
required, etc...

* One of the strong points about Ingres/Replicator is its flexibility in 
terms of both DataSets (tables/columns/values to replicate) and Paths 
(Source/Target databases). If your scheme is simple, read-only, or you don't 
mind losing the occasional transaction, it may be worthwhile to code your own 
solution.

* Pre OpenIngres 2.0 Ingres/Replicator used database rules and procedures to 
record changes in archive, shadow and queue database tables. These can cause 
severe locking bottlenecks. Provided you can design your application with 
this in mind (low update volumes, use short transactions, updating few 
records, etc), this need not be a problem. However if your application 
already suffers from locking contention problems, Ingres/Replicator is likely 
to make things much worse.

* With OpenIngres 2.0 Replication is based on the logging system and the 
performance overhead should be considerably less.


John Gedling
CACI Limited
Ingres Q & A
To William's Home Page
Email William