Upgrading a Standalone Instance
Upgrading Nexus Repository Manager presents a necessary step to gain access to new features, bug fixes, performance improvements and other advantages. Regular updates to the latest release are recommended as a general best practice. Version 3 upgrades will only work from version 3.0.0 milestone 7 and later.
Review release notes to understand any important or breaking changes. If using Nexus Lifecycle features, ensure that your new version will be compatible.
Become familiar with the basic directory structure of a Nexus Repository Manager installation. You are encouraged to stick with the standard installation layout to make future upgrades as simple as possible.
You will have to determine your existing installation data directory location. Record this value for later use.
If you are using the embedded OrientDB, databases will be checkpointed automatically to the data directory
upgrades directory during upgrade. The databases are compressed but still may consume a lot of disk space, equivalent to the size of the database backups produced by the Admin - Export databases for backup task. Ensure you have adequate free space for the checkpointed databases before upgrade.
Content Replication Considerations NEW IN 3.48.0
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. 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.
Download the Latest Installer Archive
Download the latest installer archive for your platform from the official downloads.
Extract the newest downloaded distribution archive using the standard approach.
Preparing to Upgrade
The archive distribution offers the familiar process of downloading and simply extracting the install archive in place. There is no graphical or automated process and all commands are done inside a terminal console.
tar xzvf nexus-<version-number>-mac.tgz tar xzvf nexus-<version-number>-unix.tar.gz 7za.exe nexus-<version-number>-win64.zip
nexus-<version-number>/bin/nexus.vmoptions file with your existing version.
Important notes regarding impacts of certain changes you may have made:
- If you changed the default location of the Data Directory (sonatype-work by default), then edit
./bin/nexus.vmoptionsand change the line
-Dkaraf.data=../sonatype-work/nexus3to point to your existing data directory.
- You will also need to change the location of these 4 values: -
- If you changed the default location of the temporary directory, then edit
./bin/nexus.vmoptionsand replace the line
-Djava.io.tmpdir=../sonatype-work/nexus3/tmpto point to your preferred temporary directory.
- If you adjusted the default Java virtual machine max heap memory, then edit
./bin/nexus.vmoptionsand edit the line containing
- If you have enabled jetty HTTPS access, make sure your
etc/jetty/jetty-https.xmlSSL keystore location is still available to the new install and configured according to our recommendations.
- If you manually adjusted any other install files under
./etcyou will need to manually perform a diff between the old files and the new files and apply your changes if applicable to the new version.
Perform the Upgrade
- Ensure you have taken recent backups of the existing Data Directory and any custom blobstore locations according to our recommended practices. Because of involved Upgrade steps, downgrading a Nexus Repository version is not supported and will almost always result in failures. If you have issues, restore from this backup instead.
- Stop your existing install using the scripts under
./binor your operating system service. Make sure it stops completely.
- Start the new installation using the scripts under
./binor adjust your operating system service to use these scripts.
- Review the log files for any possible issues and sign-in to the server to confirm things are working as expected.
If you are using an H2 or PostgreSQL database, you will need to run a task for each Apt, Helm, and Yum repository that existed before upgrading to 3.48.0 in order to rebuild their metadata:
- Apt - Rebuild Apt metadata for each Apt repository
- Helm - Rebuild Helm metadata for each Helm repository
- Repair - Rebuild Yum rebuild metadata (repodata) for each Yum repository