Syncing two Artifactory instances so that they share equivalent repository information can present a challenge, as scenarios exist where simple instance-to instance updating can lead to cyclic replication. If changes are made to the same artifact on both instances, the instances can go back and forth endlessly, trying to work things out.
One configuration that can be used to avoid these problems, is to configure two local repositories on each system. One of which you use for local content changes, (which will push any changes to the other instance’s “receiving” repository,) and the other you only use to receive event-based push updates from the other instance. A small problem with this scenario is that you will have a local-repository on each Artifactory instance that individuals using Artifactory must know that they must not deploy artifacts to. (The receiving repository must only be used to receive updates that have been pushed to it from the other Artifactory instance.)
A slightly different configuration is one where you create one local repository and one remote repository on each Artifactory instance, with each remote repository pointing to the other Artifactory instance’s local repository. In this case, synchronization will be done via Pulls by the system with the Remote repository from the instance with the local-repository. Event-based replication will not occur when content is changed on the system with the local-repository. This means that the systems will experience periods of time where they may be out of sync with each other, but from a functional perspective, they will be equivalent.
In either scenario, you must aggregate the repositories that are involved into a virtual-repository, and then resolve from that virtual repository to access your binaries. The resultant virtual repository will act/perform equivalently on both systems.
Attached is a short paper on multi-site topology that might be helpful for replication configuration, and also a drawing of the above configuration.