Creating a complex topology with peer replication

 

Use this information to create a complex topology with peer replication.

Peer replication is a replication topology in which multiple servers are masters. However, unlike a multi-master environment, no conflict resolution is done among peer servers. LDAP servers accept the updates provided by peer servers, and update their own copies of the data. No consideration is given for the order the updates are received, or whether multiple updates conflict.

To add additional masters (peers), you first add the server as a read-only replica of the existing masters (see Creating a replica server), initialize the directory data, and then promote the server to be a master (see Moving or promoting a server).

Initially, the ibm-replicagroup object created by this process inherits the ACL of the root entry for the replicated subtree. These ACLs might be inappropriate for controlling access to the replication information in the directory.

For the Add subtree operation to be successful, the entry DN which you are adding must have correct ACLs, if it is not a suffix in the server.

For Non-filtered ACLs:

  • ownersource : <the entry DN>

  • ownerpropagate : TRUE

  • aclsource : <the entry DN>

  • aclpropagate: TRUE

Filtered ACLs :

  • ownersource : <the entry DN>

  • ownerpropagate : TRUE

  • ibm-filteraclinherit : FALSE

  • ibm-filteraclentry : <any value>

Use the Edit ACLs function of the Web administration tool to set ACLs for the replication information associated with the newly created replicated subtree (see Editing access control lists).

The replica is in a suspended state and no replication is occurring. After you have finished setting up your replication topology, click Manage queues, select the replica and click Suspend/resume to start replication. See Managing replication queues for more detailed information. The replica now receives updates from the master.

Use peer replication only in environments where the pattern of directory updates is well known. Updates to particular objects within the directory must be done only by one peer server. This is intended to prevent the scenario of one server deleting an object, followed by another server modifying the object. This scenario creates the possibility of a peer server receiving a delete command followed by a modify command; which creates a conflict.

To define a peer-forwarder-replica topology, consisting of two peer-master servers, two forwarding servers, and four replicas :

  1. Created a master server and a replica server. See Creating a master-replica topology.

  2. Create two additional replica servers for the master server. See Creating a replica server.

  3. Create two replicas under each of the two newly created replica servers.

  4. Promote the original replica to a master. See Promoting a server to be a peer.

    The server that you want to promote to a master must be a leaf replica with no subordinate replicas.

  5. Copy the data from the master to the new master and replicas. See Coping data to the replica.

 

Parent topic:

Replication tasks

 

Related tasks


Moving or promoting a server