Assume a Federated Repository is configured among three sites (Site A, Site B, & Site C) that are members of the same Federation. When an artifact is deployed to the Federated Repository of Site A, Artifactory triggers a copy of that artifact to the Federated Repositories of both Site B and Site C.
Similarly, when an artifact is deployed to the Federated Repository of Site B, Artifactory triggers a copy to the Federated Repositories of both Site C and Site A. Likewise, when an artifact is deployed to the Federated Repository of Site C, Artifactory triggers a copy to the Federated Repositories of both Site A and Site B.
For instance, if sample files (Test1 and Test2) are deployed in the federated repository of Site A, Artifactory triggers an event to copy these sample files to Site B and Site C. Consequently, sample files (Test1 and Test2) are now available on all three sites.
Now, assume Site B is down for some reason, and you delete one of the sample files (Test1) from Site A. Once the file is deleted, Artifactory triggers a delete event to remove the files from other sites. However, since Site B is down, Artifactory cannot perform the delete operation in Site B, and file (Test1) remains available in Site B, whereas the same file (Test1) has been deleted from other sites (Site A and Site C).
Now, assume Site B is up and running, then perform a full sync against Site B, which will recreate the deleted file on other sites (Site A and Site C).
So, whenever there is downtime on one of the federated sites, it is always recommended to perform a full sync against the federated site, which incorporates all the latest changes. In our case, we have to perform a full sync against Site A, which will delete the file (Test1) from Site B.
Similarly, when an artifact is deployed to the Federated Repository of Site B, Artifactory triggers a copy to the Federated Repositories of both Site C and Site A. Likewise, when an artifact is deployed to the Federated Repository of Site C, Artifactory triggers a copy to the Federated Repositories of both Site A and Site B.
For instance, if sample files (Test1 and Test2) are deployed in the federated repository of Site A, Artifactory triggers an event to copy these sample files to Site B and Site C. Consequently, sample files (Test1 and Test2) are now available on all three sites.
Now, assume Site B is down for some reason, and you delete one of the sample files (Test1) from Site A. Once the file is deleted, Artifactory triggers a delete event to remove the files from other sites. However, since Site B is down, Artifactory cannot perform the delete operation in Site B, and file (Test1) remains available in Site B, whereas the same file (Test1) has been deleted from other sites (Site A and Site C).
Now, assume Site B is up and running, then perform a full sync against Site B, which will recreate the deleted file on other sites (Site A and Site C).
So, whenever there is downtime on one of the federated sites, it is always recommended to perform a full sync against the federated site, which incorporates all the latest changes. In our case, we have to perform a full sync against Site A, which will delete the file (Test1) from Site B.