7.4 Resolving Conflicts

In Advanced Authentication, conflicts can occur if two servers try to configure the same object. For example, MasterX and MasterY create a same login chain Visitor. This can lead to a conflict because both try to send Visitor to each other. If a conflict occurs, the replication between the conflicting servers stops. Replication uses last-write-wins policy. Conflicts can occur for one of the following reasons:

  • During upgrade when a new server communicates with the old server.

  • When two unique objects have been added.

Outgoing conflict indicates an incoming conflict on the destination server. Unique object collision causes two corresponding conflicts: incoming and outgoing conflicts on both the source and target servers.

You can resolve the conflict in one of the following ways:

  • Simplest way: Click Fix on both the servers.

  • Smarter way: Click Fix on a server in one site and click Forget on a server in the other site.

  • Possible way: Click Forget outgoing on the servers in both the sites. You can use this method for UPDATE conflicts. Object changes are lost but will sync on next object change.

  • Zero way: Source server automatically re-sends the changes until you forget the outgoing conflict.

  • Purge working tables: This method is used as a last resort. If you see low-level errors in the replication log, if conflict resolution does not work for you, you may force the replication system to forget all pending replicas and re-initialize.

Advanced Authentication scans for the replication conflicts, automatically. To resolve the existing conflicts, in the Cluster section of the Advanced Authentication Server Registrar, click Conflicts. If no conflicts are detected, only the information is displayed. If there are any conflicts, the details and controls to resolve the conflicts are displayed. You will get a confirmation request with each action. The confirmation contain notes that help you to resolve the conflicts.