Synchronization and Conflict Resolution
Learn how Federated repositories resolve sync conflicts using timestamp-based rules.
Federated repositories synchronize artifact metadata and binaries among Federation members using event-based asynchronous replication. This topic describes what is synchronized, what is not, and how conflicts are resolved.
Event-Based Synchronization
Metadata events are updated asynchronously among Federation members. Because of the persistent queue, the Federation mechanism ensures that all events are eventually synchronized among all members. For example, an event might not be sent immediately to a different Federation member due to a server failure or network delays, but the system ensures that the event is sent eventually.
Conflict Resolution
When the same file is sent from two locations simultaneously, conflict resolution is performed based on timestamps where the last event received overrides previous events. This is why clock synchronization is critical to the proper functioning of the Federation. For more information, see Prerequisites.
Any of the CRUD actions that you perform are automatically applied to the Federation members. Users can perform actions according to their permission sets. The logic is applied according to the last action performed on the artifact by any of the users in the Federation.
Synchronized Metadata
Federated repositories synchronize the following metadata among members. The uploadedBy, lastFileModified, and deploymentDate file fields are disabled by default and require a system property to enable them, as described in the note below.
| Folders | Files |
|---|---|
| length (the size of the folder in bytes), properties | checksum, properties, uploadedBy (see note), lastFileModified (see note), deploymentDate (see note) |
Note
Synchronization of the metadata introduced in release 7.90.1 (
uploadedBy,lastFileModified,deploymentDate) is controlled by the system propertyartifactory.federated.mirror.events.upload.info.propagate.enabled. By default, this flag is set tofalse. Set this flag totrueon both the source and target JPDs to synchronize this metadata to other members.
Settings That Are Not Synchronized
The following repository configuration settings aren't synchronized among Federation members:
- proxy
- maxNumberOfThreads
- modificationDate
- blackedOut
- repoLayout
- key
- primaryKeyPairDescriptor
- secondaryKeyPairDescriptor
- xrayConfig (see Xray Configuration Synchronization)
- cdnRedirectConfig
- propertySets
- cdnRedirectRepo
- downloadRedirect
For more information about these settings, see Repository Configuration JSON.
Xray Configuration Synchronization
xrayConfig is an exception to this list: it synchronizes, but only at the moment a member joins the Federation, not afterward.
When you add a new member to a Federated repository, JFrog Artifactory synchronizes the Xray configuration (xrayConfig) from the Federated repository on the JPD where you perform the add-member operation to the new member. This includes settings such as Enable Indexing in Xray and related Xray properties configured on the source repository. For more information, see Enable Indexing in Xray.
This behavior applies when you:
- Create a new Federated repository and add remote members, including when Artifactory automatically creates the repository on the remote JPD
- Add a new member to an existing Federated repository
You can configure Xray settings on a single JPD and rely on those settings being applied to newly added Federation members, without manually enabling Xray indexing on each remote site.
Warning
Changes to Xray configuration on existing Federation members aren't synchronized. If a Platform Administrator updates Xray settings on one member after that member has joined the Federation, those changes aren't propagated to other members. To align Xray configuration across all members, update the settings on each Federation member individually.
Frequently Asked Questions
This section provides answers to frequently asked questions about Federation synchronization and conflict resolution.
FAQs
Q: How does the Federation decide which version of a file wins during a conflict?
A: Conflict resolution is timestamp-based: when the same file is sent from two locations simultaneously, the last event received overrides previous events. See Conflict Resolution for details.
Q: Why is clock synchronization important for Federated repositories?
A: Because conflicts are resolved by comparing event timestamps, unsynchronized clocks across JPDs can cause the wrong version of a file to win a conflict.
Q: Are all repository settings synchronized between Federation members?
A: No. Settings such as proxy, maxNumberOfThreads, and repoLayout aren't synchronized. See Settings That Are Not Synchronized for the full list.
Q: Does Xray configuration stay in sync after a member joins the Federation?
A: No. xrayConfig only synchronizes at the moment a member joins. Changes made afterward on one member aren't propagated to other members.
Q: Why don't I see uploadedBy or lastFileModified values on synchronized files?
uploadedBy or lastFileModified values on synchronized files?A: These fields are disabled by default. Set the artifactory.federated.mirror.events.upload.info.propagate.enabled system property to true on both the source and target JPDs to enable them.
Related Topics
Updated about 7 hours ago