hierarchical replication 
Author Message
 hierarchical replication

 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



Sat, 20 Mar 2004 22:29:59 GMT
 hierarchical replication

Hi,

I think the definition of hierarchical routing should be included with the server definitions, not with the replicate definitions. Check
cdr define server syntax, there you can specify whether it is a leaf server or not. After that, combine those two replicate definitions
into one replicate definition.

Regards,
Praveen.

Quote:

>  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



Sat, 20 Mar 2004 23:23:53 GMT
 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.

Quote:

>  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


Sun, 21 Mar 2004 05:51:04 GMT
 hierarchical replication

    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.

Quote:

>  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


Tue, 23 Mar 2004 21:35:27 GMT
 hierarchical replication
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


Wed, 24 Mar 2004 00:00:11 GMT
 hierarchical replication
Hi,

It's time to note all the points from Madison. He cleared all the doubts with the combination of HDR and ER.

If you like to make your backup-server to be known to all other servers, then I can think of a way. But don't know how far it will be
practical for you, depending on your application. Suppose B1 is the backup-server for B.

1. Make B1 also a root server in the ER environment and change your replicate definitions to include B1

2. Revoke all the permissions on tables on B1 except read permissions to allow your report jobs

3. If B fails then grant the update permissions to tables on B1 and divert your application connectivity to B1.

4. Meanwhile all other servers keeps on storing data for B till it comes up. When it comes up, then

    a. Connect your applications back to B and revoke permissions on B1

                    OR

     b. Keep B1 going as primary server and treat B as backup server by revoking the update    permissions. Next time when B1 fails then
change back B as primary server

Ohhhh...is it practical? I doubt.

Regards,
Praveen.

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



Wed, 24 Mar 2004 19:15:26 GMT
 
 [ 6 post ] 

 Relevant Pages 

1. Hierarchical Informations

2. Multi-Level Marketing (MLM)/Hierarchical Database

3. Hierarchical Querying

4. Creating Hierarchical Recordsets in SQL Server 2000

5. Q: Hierarchical queries

6. Hierarchical selects

7. Hierarchical Data

8. Hierarchical Recordsets with more than one child

9. SHAPE & Hierarchical Recordsets

10. Hierarchical table query

11. Relative, hierarchical, sorting algorithm help needed

12. Hierarchical Recordsets


 
Powered by phpBB® Forum Software