Each PingDirectory server has an embedded replication server that is responsible for transmitting updates to other replication servers. Each replicating base distinguished name (DN), such as cn=schema, dc=example,dc=com, has a separate component called a replica. Each replica connects to the embedded replication server running within the PingDirectory server Java virtual machine (JVM) process.

When a client application updates an entry on the PingDirectory server, the replica sends an update message to its embedded replication server. The replication server applies the change to the replicationChangelog backend repository and then sends an update message to the connected replication server on another PingDirectory server. The replication server on other PingDirectory servers then passes the change to the appropriate replica, which in turn applies the change to its backend after performing conflict resolution.

The following figure shows the standard setup.

Replicas and Replication Servers
Canvas 1 Layer 1 Identity Data Store A Austin Replication Server 1 Identity Data Store B Austin Replication Server 2 Replica 2 Replica 1 Update Desktop Client/Application LDAP Replication 2 1 3 4
  1. The client or application sends a modification request to Identity Store A. The identity store applies the change.
  2. The Replica backend in Identity Store A sends an update message to the Replication Server in Identity Store A.
  3. The Replication Server in Identity Store A pushes the update to the Replication Server in Identity Store B.
  4. The Replication Server in Identity Store B applies the update the to the Replica backend in Identity Store B.