Creating and Managing a Content Replication Connection
Note
Only available in Sonatype Nexus Repository Pro. Interested in a free trial? Start here.
Prerequisites
In order to use content replication, you must meet the following prerequisites:
Contentreplication 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.
Creating the Connection
Before creating a new content replication connection, ensure you have satisfied all prerequsites.
Create or find an existing proxy repository under Administration → Repository → Repositories to serve as your target instance.
Tip
As a best practice, we suggest configuring the proxy repository first and confirming that it works as expected before trying to enable replication.
On the repository configuration form, enter the URL for the remote repository you wish to proxy (the source instance) in the Remote storage field under the Proxy section.
Note
For Docker repositories, use the repository URL from the source instance (e.g., http://localhost:8081/repositories/docker-hosted) as the storage url. You cannot use the subdomain or http/https port.
Select the Pre-emptive Pull checkbox to enable content replication.
If desired, use the Asset Name Matcher to limit the scope of what is replicated. Use a POSIX Regular Expression to define specific components to replicate. See Asset Name Matcher.
If required, provide the appropriate username and password for authentication in the HTTP → Authentication section at the bottom of the form.
Select the Create Repository button to complete.
This automatically creates a task (described in the next section) that is configured to run every minute.
Running the Content Replication Task
Content replication happens whenever the Content Replication - Pull content from remote task runs on the target side. This task is generated automatically when you configure content replication for a repository; you can find it under Administration → System → Tasks. You will see one task per target repository with the default name of "Replicate content: <target-repository-name>."
 |
The task is configured to run every minute; however, you can also manually run the task oradjust the task schedule if needed in order to initiate content replication.
When the task runs, the target instance reaches out to the source instance, requests a list of new content since the last successful replication (stored as a timestamp in the<format>_content_repository table in the repository's configuration), then issues proxy requests for all of those items in order to replicate them to the target.
Pausing Content Replication
If for any reason you need to temporarily pause content replication to a given target instance, you can edit the content replicationtask settings to adjust the schedule as needed.
When you start replication again, it will pick up from the last successful replication timestamp and begin replicating any changes since that stored timestamp.
Disabling Content Replication
To disable a content replication connection, navigate to Administration → Repository → Repositories and select the target repository to open its configuration page. Remove the check from Pre-emptive Pull to disable content replication; once this change is saved, the content replication task will also be removed.
Note
Disabling replication will not remove the stored timestamp for the last successful replication, which is stored in the repository configuration. If you re-enable replication, it will pick up from the last successful replication timestamp and begin replicating any changes since that stored timestamp.
Note
If you accidentally remove the replication task from the task list rather than disabling it in a specific repository, Nexus Repository will not automatically re-create the task, and this will effectively disable content replication. However, if you must disable content replication, we recommend following the instructions above.
Upgrading Nexus Repository Instances that are Using Content Replication
When upgrading Nexus Repository instances that are using content replication, we recommend pausing content replication on the target instance while performing the upgrades to allow for a clean, predictable timeline for when replication is down. You can then re-start replication once you've upgraded both instances to the same version. Content replication will pick up from the last successful replication timestamp and begin replicating any changes since that stored timestamp.
If you do not pause replication, the instances will temporarily be on different versions; this will cause replication to fail as both instances must be using the same version. Once both instances are on the same version again, content replication will pick back up from the last successful replication timestamp, which is stored in the repository configuration in the table <format>_content_repository (e.g., raw_content_repository). Content replication will then replicate an content added since that timestamp.
As a best practice, keep the time between upgrading each instance minimal. Otherwise, it may take a significant amount of time for content replication to catch up.
Content Replication for Group Repositories
If you are planning to use content replication on a group repository, you must set up a replicating proxy repository for each of the hosted repositories in the group.
You can then set up a single normal proxy repository pointing to the source group to cover all of the proxy repository members in that group.
Finally, you can set up a group repository on the target side and ensure the replicating proxy repositories are prioritized over the normal group proxy.
This combines the configuration for all non-replicating repositories into a single proxy repository, reducing the amount of required configuration.
Troubleshooting
Logs
Content replication logs are available under Administration → Support → Logs and in $data-dir /log/replication/.
Here you will find log files for each replicating repository. You can use these logs to confirm that content replication is working as intended and to see any errors or failures.
batchSize Property
In your $data-dir/etc/ nexus.properties, there is a property called nexus.replication.pull.batchSize that determines how many components are replicated each time the content replication task runs. This property is set to 512 by default. You may need to adjust this number so that content replication keeps up with proxying new items without taking longer that the duration between task runs.