Magiera,
The best way to do what you are describing is to make the ER nodes into an HDR pair and use HDR to replicate the mirror image. Unfortunatly,
combining ER with HDR is not currently supported at this time. That means that the best that you can do is to create an additional ER node and
replicate to it. Unfortunatly, the additional ER node will not be able to fully support the functionality of the main ER node.
To explain what I mean, suppose that there are three levels of servers A, B, C participating in a hierarchy.
A <--> B <--> C
To provide reduncy of B you can do the following:
A <--> B <--> C
|
B1
Unfortunatly, if B goes down, then B1 is not able to replace B because B1 is not directly replicating with either A or C. The ideal would be
to replace A, B, and C with an HDR pair.---
(A/A1) <--> (B/B1) <--> (C/C1)
With this design, B is the primary server within the HDR pair and B1 is the secondary. If B goes down, then B1 becomes the primary server
within the HDR pair and assumes full functionality of the 'B' node. To ER, B and B1 are the same identity. Also, non-updating activity can
be done on the secondary of an HDR pair.
This design is currently not supported. However, if this is the design that you want, please contact your IBM/Informix sales team and have
them make a case for this support. They will need to contact the IDS Product Manager to make this into a priority feature item. His name is
Steven Miller.
Also, if anyone reading this posting would like to have this feature, please do the same. Contact your sales team and have them make a case
for this support.
Quote:
> Hi,
> thank you very much for all your answers, Praveen and Madison.
> I have another question.
> Situation:
> Seven root-server (IDS 9.21 UC2 on: SCO Open Server 3.2v5.0.x)
> exchanging a few master table data via ER (update anywhere).
> We would now like to "mirror" one of the database machines (physically into new machines)
> in order to
> 1) gain some (hardware) redundancy (backup server) and
> 2) let some reporting tasks run against the mirror
> machines instead of the primary database machines.
> For the uses above the 'mirroring' must be just in time.
> I don't want to add the new 'BackupServer' to the existing Replicates.
> The root servers 1-6 shouldn't know the existence of the backup server.
> Is it possible with eg. hierarchical replication to define new replicates only
> between the one root-server and the backup-server, so that replicated data
> from some server (1-6) to server 7 will be replicated to the new backup-server without
> modification of the existing replicates?
> I want to add a replication tree like shown in 'Guide to Informix Enterprice Replication Version 9.2, page 3-13: hierarchical tree'
> with the backup-server as a leaf server.
> Please can you give me some helpful hints where i can read more about hierarchical replication (perhaps with
> examples). The Manual 'Guide to Informix Enterprice Replication Version 9.2' isn't very helpful.
> Do you know other possibilities to solve my problem?
> I hope my explanations are understandable.
> Thanks in advance.
> Heinz
> -----Ursprungliche Nachricht-----
> Gesendet am: Dienstag, 2. Oktober 2001 23:48
> An: Magiera
> Betreff: Re: hierarchical replication
> As Praveen explained, you need to define the replicate as:
> cdr define repl L_artikel -Ctimestamp -Stran -A \
> "select * from artikel " \
> "select * from artikel " \
> "select * from artikel "
> There is a difference between Hierarchical Routing and Cascading Replication.
> Cascading replication is when a replicate is applied on one server and then is re-snooped and re-applied on another server. While this
> works fairly well with one-directional replication, it creates problems with update anywhere. For instance if the replication flow is A
> -> B -> C and we also allow C->B->A, then we have a real problem. A->B->C->B->A->B->C-> etc.... The only way to avoid this is to carry
> shadow control information of all of the nodes that the replicated transaction has visited and not echo the transaction back to a server
> that it has already visited.
> So all of the targets must be defined within the replicate definition to prevent this recursion.
> Understand also, we do not require that the data be applied on all of the servers that the transaction visits. Eventhough the transaction
> must go through server B to get from A to C, it does not have to be applied on server B.
> > Hi
> > Our replication hierarchy is:
> > Root server : oltest_1cdr and oltest_2cdr with 'update anywhere'
> > Leaf server : oltest_3cdr (oltest_3cdr is the child of oltest_2cdr)
> > Replicates:
> > # Defining replicate L_artikel ...
> > cdr define repl L_artikel -Ctimestamp -Stran -A \
> > "select * from artikel " \
> > "select * from artikel "
> > # Defining replicate T_artikel ...
> > cdr define repl T_artikel -Ctimestamp -Stran -A \
> > "select * from artikel " \
> > "select * from artikel "
> > if a row is updated on oltest_2cdr the data is replicated to oltest_1cdr and oltest_3cdr (it's ok).
> > Problem:
> > if a row is updated on oltest_1cdr the data is only replicated to oltest_2cdr but not to oltest_3cdr (which is leaf of oltest_2cdr !).
> > why does Replicate L_artikel not work in this case?
> > How must I define the L_artikel, so that the replicated row on oltest_1cdr goes to oltest_3cdr through oltest_2cdr?
> > IDS 2000 9.21 UC2
> > SCO Open Server 3.2V5.0.x
> > Please excuse my poor english.
> > Thanks for any comment or instructions.
> > Heinz
> --
> ---------------------------------------------------------
> Madison Pruet
> Enterprise Replication Product Development
> IBM Informix Dynamic Server
--
---------------------------------------------------------
Madison Pruet
Enterprise Replication Product Development
IBM Informix Dynamic Server
hierarchical replication