Option 1 - Manual High Availability Deployment

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

NEW IN 3.50.0

Sonatype Nexus Repository High Availability deployments should be fully deployed and tested in a development environment before attempting to deploy in production. Improper deployment in a production environment can result in critical data loss.

Use Cases

HA is designed to protect against the following scenarios:

An Availability Zone (AZ) outage within a single region
A virtual machine/bare metal/EC2 instance failure
A Nexus Repository instance failure

It also provides the following necessary functionality to highly scalable Nexus Repository deployments that must meet varying loads:

Manually scale repository instances
Auto scale instances in AWS/Azure
Deploy in Kubernetes to facilitate scaling instances up and down without having to shut down Nexus Repository

Requirements

Each Sonatype Nexus Repository instance must meet our Sonatype Nexus Repository System Requirements.
You must also meet all System Requirements for High Availability Deployments, including using shared blob storage (see Migrating to Shared Blob Storage if necessary).
If you require your clients to access more than one Docker Repository, you must use an external load balancer (e.g., NGINX) as a reverse proxy instead of the provided ingress for Docker YAML.
Before proceeding, you must have adjusted the max_connections.

Limitations

All active Sonatype Nexus Repository instances will have to be shut down in order to upgrade the Sonatype Nexus Repository version.
We do not recommend deploying HA clusters across regions due to the large number of database interactions is involved in HA.
In the absence of a distributed solution for logging, local disks are required to persist the log files that are needed for support zip creation.

Database

To set up a Sonatype Nexus Repository cluster manually, you must configure each Sonatype Nexus Repository instance following our documentation for Configuring Nexus Repository Pro for PostgreSQL.

Blob Storage

Enabling HA will disable the ability to create default blob stores and repositories. If you are already using the default blob store on your instance, you will need to follow the instructions in Migrating to Shared Blob Storage to change your default blob store's path to connect to a shared location.

Enable HA Property

Beyond the instructions linked above, you must also modify the $data-dir/ sonatype-work/nexus3/etc/nexus.properties in each instance to include the following line:

nexus.datastore.clustered.enabled = true

If you accidentally start in the wrong mode, you will need to shut down any started instances, set the flag above on each instance, and then restart each instance.

License Store for On-Premises and Cloud

As outlined in the documentation for Configuring Nexus Repository Pro for PostgreSQL, you should specify the license file via the nexus.licenseFile in $data-dir/sonatype-work/nexus3/etc/nexus.properties by adding the following line, replacing the placeholders with the appropriate path to point to your valid Pro license:

nexus.licenseFile=/path/to/your/sonatype-license.lic

Log Store

You will find Sonatype Nexus Repository logs on each instance in the data directory (i.e., $data-dir/sonatype-work/nexus3/logs/).

Each Sonatype Nexus Repository instance will write logs to the local disk. The correct instance will respond to support zip generation requests and store the generated zip in the blob store.