Content Replication Use Cases and Scenarios
Only available in Nexus Repository Pro. Interested in a free trial? Start here.
NEW IN 3.48.0
Content replication is not appropriate for disaster recovery. If you need a disaster recovery solution, please see our resilient deployment options and backup and restore procedures.
As detailed below, there are multiple use and business cases for content replication. This topic covers basic configuration steps for these use cases.
One Source One Target
Content replication is primarily used to make content in one repository available to another repository shortly after it is published so that users on the second instance do not have to wait for Nexus Repository to proxy content from another instance. With large files (e.g., Docker images), waiting for Nexus Repository to proxy content from another instance can induce timeouts. So, rather than using a proxy repository and only replicating content on demand, we pre-emptively replicate content on a schedule (every minute) . When a person or CI tool on the target end requests content, their local Nexus Repository instance should already have that content, so the request won't induce any timeouts to the format-specific client as Nexus Repository can immediately start serving the new content.
Having one source and one target instance is the most basic form of content replication. You can configure this pattern using our standard content replication configuration instructions.
One Source Multiple Targets
You can also use content replication to replicate content from one source repository to multiple target repositories. You may use this setup if you have a central Nexus Repository server with multiple sites in other parts of the world and desire content to be made available at those other sites for faster access.
It is easy to configure multiple targets to proxy assets from one source repository. Simply follow our standard content replication configuration instructions on both target instances, configuring each to proxy the same source repository URL in the Proxy section of their configuration screen.
Bi-Directional Content Replication
You could also set up a bi-directional content replication scenario where content is replicated between two geographically separate locations. You would use this setup if you had two locations with separate Nexus Repository instances (Team A using Instance A and Team B using Instance B). If both teams consume content that the other team creates, you would need to replicate content in both directions so that Team A has quick access to the content Team B publishes and vice versa.
To use bi-directional content replication, you would need six separate repositories: one group repository on each instance, each containing one target and one source repository.
Within each instance, create a group repository containing one target and one source.
Then, follow our standard content replication configuration instructions on each instance's target repository to create the connection and content replication task.
Use the URL of the other instance's source repository when configuring the target.
Content Replication for Latest Content
Content replication always replicates latest content. When the content replication task runs, the target repository queries the source repository for new content and then issues proxy requests for all new items in order to replicate them to the target instance. Simply follow our standard content replication configuration instructions to configure this use case.
Content Replication for Subset of Content
If you wish to limit content replication to a subset of content, follow our standard content replication configuration instructions, but also create a POSIX Regular Expression in the Asset Name Matcher field to define what content you wish to replicate.