Content Replication

Only available in Nexus Repository Pro. Interested in a free trial?  Start here.

NEW IN 3.48.0

You cannot use Sonatype Repository Firewall with content replication.

Note that you can only use content replication with a hosted repository source, which cannot use Sonatype Repository Firewall. Proxy repositories serving as the target for content replication will only contain components from these hosted repositories.

What is Content Replication?

Content replication allows you to publish artifacts to one Nexus Repository Pro instance and then have other instances pre-fetch them via HTTP to provide faster artifact availability across distributed teams.

With content replication, you can manage what binaries can be replicated (copied and pre-emptively pulled by an instance) between two or more instances. The following diagram illustrates the content replication process, which is also described below:

  1. New assets are published to the Nexus Repository source instance
  2. The replication task runs on the target instance on a schedule (each minute) to identify new assets
  3. The replication task issues proxy requests for each new asset to replicate them to the target instance
  4. Users on the target instance now have access to newly added artifacts on the target instance

 There are multiple ways you can use content replication, including having multiple targets proxying one source, bi-directional content replication, or replicating a subset of content. You can learn more about these use cases and how to configure them in Content Replication Use Cases and Scenarios.

Can I Use Content Replication for Disaster Recovery?

No, content replication is not appropriate for disaster recovery due to a few limitations:

  • Content replication only pulls new content that is published to a Sonatype Nexus Repository source instance after content replication is enabled; pre-existing assets are not pulled
  • Content replication does not transfer metadata (e.g., date uploaded, who uploaded the asset, etc.) or things that are not assets/components (e.g., users, roles, privileges)
  • Pulled content is stored in a proxy repository, to which you cannot publish and which is less permanent than a hosted repository

If you need a disaster recovery solution, please see our High Availability and resilient deployment options and backup and restore procedures.

What Content is Replicated?

After content replication is enabled on an instance, all new assets will be replicated as if requested through the proxy. Pre-existing assets and Nexus repository metadata (downloaded date, uploader IP, etc.) are not replicated.

What that looks like can vary between formats. For example, for Maven, components' assets (e.g., jars, hash files, pom files, etc.) as well as the maven-metadata.xml files will be replicated. For npm, that means the dependency archives (.tgz) as well as the npm metadata.

In general, if you can see it in the browse tree as something to download, it will be replicated.

If you delete an item on the source repository that has already been replicated to the target repository, the item will still exist on the target repository; deletion is not replicated.

Note also that content replication can impact the effectiveness of your cleanup policies. For example, component downloads from the target instance will not update the last downloaded date on the source instance. This could result in a component being unexpectedly removed from the source but not the target.

What are the Supported Formats for Content Replication? 

Content replication requires that the source repository be a hosted repository and the target be a proxy repository. The following formats support both hosted and proxy repositories and are suitable for content replication:

  • APT 
  • Docker
  • Helm 
  • Maven 
  • npm 
  • NuGet (V3) 
  • R
  • Raw 
  • RubyGems

Is Content Replication Appropriate for Me?

First and foremost, 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.

Content replication is primarily used to make content readily available to distributed teams. When enabled, content replication fetches content before you ask for it, reducing latency. 

However, unless you specify limitations through a RegEx pattern in the Asset Name Matcher field, the content replication task will fetch all new content, which may significantly expand your storage needs.

Prerequisites

In order to use content replication, you must meet the following prerequisites:

  • Content replication is only available for Nexus Repository Pro customers; you must have a valid Nexus Repository Pro license to proceed.
  • Ensure you are on the latest Nexus Repository Pro version and that both the source and target instance are on the same version.
  • Both instances must be using a PostgreSQL database.
  • The source repository must be a hosted repository.
  • The target repository must be a proxy repository.