N-way replication

Question

hi,
can someone please provide a script, allowing n-way/mesh/update anywhere topology HA/DR system.
I am able to setup a hot standby two-way replicating system;
MACH1<---->MACH2 [SITE A]
these two servers replicate using the two way hot standby replication scheme.
MACH3<----->MACH4 [SITE B]
also these two servers replicate using the two way hot standby replication scheme.
but now i need the two sites also replicate with the other, for example;
MACH2<------>MACH3 [SITE A]+[SITE B]
Is it possible to do this with a secondary replication scheme? (it is not a problem two sites are one way or two way replicating, all solutions will be appreciated :) )
Thanks.

Answer 1

Thanks for the extra detail. My first comment is that unless you have a compelling reason to use TimesTen 7.0 you should really consider using TimesTen 11.2.1 for any new developments; it has many new features compared to 7.0 plus better performance in many scenarios.
The configuration that you want to achieve can easily be realised using classic or legacy replication. Here is a 4-way example using database level replication:
CREATE REPLICATION myrepscheme
ELEMENT e1 DATASTORE
MASTER mystore ON mach1
SUBSCRIBER mystore ON mach2
SUBSCRIBER mystore ON mach3
SUBSCRIBER mystore ON mach4
ELEMENT e2 DATASTORE
MASTER mystore ON mach2
SUBSCRIBER mystore ON mach1
SUBSCRIBER mystore ON mach3
SUBSCRIBER mystore ON mach4
ELEMENT e3 DATASTORE
MASTER mystore ON mach3
SUBSCRIBER mystore ON mach1
SUBSCRIBER mystore ON mach2
SUBSCRIBER mystore ON mach4
ELEMENT e4 DATASTORE
MASTER mystore ON mach4
SUBSCRIBER mystore ON mach1
SUBSCRIBER mystore ON mach2
SUBSCRIBER mystore ON mach3
STORE mystore ON mach1 PORT 10000
STORE mystore ON mach2 PORT 10001
STORE mystore ON mach3 PORT 10002
STORE mystore ON mach4 PORT 10003;
Looks easy but there are some important caveats:
1. If you use the default asynchronous mode of operation then when the currently 'active' datastore (the one receiving application updates) or the machine hosting it fails there will, in general, be some trapped transactions. If you immediately failover the application to another datastore and then recover the failed store you need to consider what will happen to those transactions... You really have 2 choices; allow them to flow across after the store has been recovered but then you run the risk of 'old' updates overwriting 'newer' updates or you discard the failed datastore entirely and re-create it by duplicating the new active datastore. Either way you will typically 'lose' some transactions and/or have diverged datastores. Using conflict resolution may help (this is only available with table level replication not datastore level replication) but it is not always a foolproof solution.
2. You need to take care with the geopgraphic links to make sure that the bandwidth and latency of the connections is sufficient for replication to operate successfully. You will almost certainly have to activate the software compression option (COMPRESS TRAFFIC ON) if you are using geographic replication. You also need to ensure that the O/S TCP/IP settings are tunes suitable for high latency connections.
There is an alternative (and preferred) solution for this requirement based on active/standby pair replication. Rather than explain it here (it is quite detailed) I have written a whitepaper that describes this (and other) replication solutions; if you are interested and can give me an e-mail address I will send it to you.
Chris