Skip to main content

Migrating an Existing Nexus Repository Instance to a Resilient or High Availability Deployment

Migrating an existing Nexus Repository instance to a resilient or highly available (HA) architecture requires migrating to a PostgreSQL database (preferably cloud-based) and then migrating your blobs before setting up the architecture outlined in one of our resilient deployment examples or HA deployment options.

The sections below describe the necessary steps for migrating.

Prerequisite: Migrating to a PostgreSQL Database

Regardless of whether you are migrating from on-premises to on-premises or migrating to the cloud, you will need to be using a PostgreSQL database to use any of our resilient or HA deployment options. If you are migrating to the cloud, you can migrate to AWS Aurora or RDS PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, or any self-hosted PostgreSQL database in your cloud environment.

Note

The Database Migrator utility available in our Download section and described in our help documentation for migrating to PostgreSQL does not directly support migrating from an on-premises OrientDB to a cloud PostgreSQL database. Before using the Database Migrator, you need to ensure that it can see both locations (e.g., the on-premises file system and new database). It is your DevOps Engineer's responsibility to set up the underlying architecture to ensure migrator has this access before proceeding.

If your existing instance is using OrientDB or H2, you will first need to follow these instructions for migrating to PostgreSQL.

Migrating an On-Premises Single Nexus Repository Instance to an On-Premises Resilient or HA Deployment

To migrate from an on-premises single Nexus Repository instance to an on-premises resilient or HA deployment, complete the following steps:

Note

PostgreSQL backups take place outside of Nexus Repository and are not covered in our documentation. See PostgreSQL documentation for more information.

Note

Note that you will need to complete the prerequisite step of adjusting max_connections if moving to an HA deployment.

  1. First, migrate to a PostgreSQL database.

  2. After migration, ensure that you have database scheduled backups configured; if not, you should kick this off manually and consider scheduling backups.

  3. After migrating your database, follow the instructions for setting up the architecture in our Single Data Center On-Premises Deployment Example Using Kubernetes or on-premises HA deployment option.

Migrating a Single Cloud Nexus Repository Instance to a Resilient or HA Cloud Deployment (AWS/Azure/GCP)

Note

If you need to migrate multiple Terabytes of blob data, you should consult directly with AWS, Azure, or Google for guidance to avoid prolonged downtime.

To migrate from a single cloud Nexus Repository instance to a resilient or HA cloud deployment using AWS, Azure, or Google Cloud, complete the following steps:

Note

PostgreSQL backups take place outside of Nexus Repository and are not covered in our documentation. See PostgreSQL documentation for more information.

  1. First, migrate to a PostgreSQL database. (You can migrate to AWS Aurora or RDS PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL, or any self-hosted PostgreSQL database in your cloud environment.)

  2. After migration, ensure that you have database scheduled backups configured; if not, you should kick this off manually and consider scheduling backups.

  3. Move blobs to either Amazon Simple Storage Service (S3), Azure Blob, or Google Cloud Storage:

      Note

      Before proceeding, you should ensure you have backed up your blob store.

    1. Moving to Amazon S3 - Migrating from file blob storage to Amazon S3 requires copying blobs to S3 using a tool such as AWS DataSync. Amazon provides documentation for using DataSync to move data between other storage systems and AWS storage services.

    2. Moving to Azure Blob - In order to migrate to Azure Blob, you must copy blobs to Azure Blob using a tool such as AzCopy. Microsoft provides documentation for using AzCopy to move data to and from Azure Blob.

    3. Moving to Google Cloud Storage - In order to migrate to Google Cloud Storage, you must copy blobs to Google Cloud Storage using a tool such as Google's Storage Transfer Service. and provides documentation for moving data between other storage systems and GCP.

  4. Update the blob store configuration in your database to match the new type of blob store and new location.

    1. Create the new blob store in your Sonatype Nexus Repository instance.

    2. Shut down Sonatype Nexus Repository.

    3. Run a SQL query like the following:

      delete from blob_store_configuration where name = '<blob store name>'; -- the name of the blob store which was moved to S3/Azure

-- update the reference to the new S3 blob store
update blob_store_configuration
set name = '<blob store name>'
where type = '<S3 or Azure Cloud Storage or Google Cloud Storage>'
and name = '<name of the new blob store>';

    4. Re-start your Sonatype Nexus Repository instance.

  5. After migrating your database and blob store, refer to one of the following to set up your resilient or HA architecture:

    1. AWS Cloud Resilient Deployment

    2. Azure Cloud Resilient Deployment

    3. Google Cloud Resilient Deployment

    4. AWS HA Deployment

    5. Azure HA Deployment

    6. Google Cloud HA

    Note

    Note that you will need to complete the prerequisite step of adjusting max_connections if moving to an HA deployment.

Migrating an On-Premises Single Nexus Repository Instance to a Resilient or HA Cloud Deployment (AWS/Azure/GCP)

Note

If you need to migrate multiple Terabytes of blob data, you should consult directly with AWS or Azure for guidance to avoid prolonged downtime.

To migrate from a single on-premises Nexus Repository instance to a resilient or HA cloud deployment using AWS or Azure, complete the following steps:

  1. First, migrate your database to Aurora PostgreSQL, Azure Database for PostgreSQL, or Google Cloud SQL for PostgreSQL.

    Note

    The Database Migrator does not directly support on-premises OrientDB to cloud PostgreSQL migration. Before using the Database Migrator, you need to ensure that it can see both locations (e.g., the on-premises file system and new database). It is your DevOps Engineer's responsibility to set up the underlying architecture to ensure that the Database Migrator has this access before proceeding.

  2. After migration, ensure that you have database scheduled backups configured; if not, you should kick this off manually and consider scheduling backups.

    Note

    PostgreSQL backups take place outside of Nexus Repository and are not covered in our documentation. See PostgreSQL documentation for more information.

  3. Move blobs to either Amazon Simple Storage Service (S3), Azure Blob, or Google Cloud Storage:

    Note

    Before proceeding, you should ensure you have backed up your blob store.

    1. Moving to Amazon S3 - Migrating from file blob storage to Amazon S3 requires copying blobs to S3 using a tool such as AWS DataSync. Amazon provides documentation for using DataSync to move data between other storage systems and AWS storage services.

    2. Moving to Azure Blob - In order to migrate to Azure Blob, you must copy blobs to Azure Blob using a tool such as AzCopy. Microsoft provides documentation for using AzCopy to move data to and from Azure Blob.

    3. Moving to Google Cloud Storage - In order to migrate to Google Cloud Storage, you must copy blobs to Google Cloud Storage using a tool such as Google's Storage Transfer Service. and provides documentation for moving data between other storage systems and GCP.

  4. Update the blob store configuration in your database to match the new type of blob store and new location.

    1. Create the new blob store in your Sonatype Nexus Repository instance.

    2. Shut down Sonatype Nexus Repository.

    3. Run a SQL query like the following:

      delete from blob_store_configuration where name = '<blob store name>'; -- the name of the blob store which was moved to S3/Azure

-- update the reference to the new S3 blob store
update blob_store_configuration
set name = '<blob store name>'
where type = '<S3 or Azure Cloud Storage or Google Cloud Storage>'
and name = '<name of the new blob store>';

    4. Re-start your Sonatype Nexus Repository instance.

  5. After migrating your database and blob store, refer to one of the following to set up your resilient or HA architecture:

    1. AWS Cloud Resilient Deployment

    2. Azure Cloud Resilient Deployment

    3. Google Cloud Resilient Deployment

    4. AWS HA Deployment

    5. Azure HA Deployment

    6. Google Cloud HA

    Note

    Note that you will need to complete the prerequisite step of adjusting max_connections if moving to an HA deployment.