Skip to main content

Upgrading to Nexus Repository 3.71.0 and Beyond

Nexus Repository 3.70.0 was the final release to support the embedded OrientDB database, Java 8, and Java 11.

Before updating to release 3.71.0 and on, you must migrate to an H2 or PostgreSQL database and Java 17.

Find Your Upgrade Path

Use the table below to find your upgrade instructions.

Current Database

Current Nexus Repository Version

Current Java Version

Upgrade Instructions

PostgreSQL

Any

Java 17

No additional actions; follow normal upgrade procedures

PostgreSQL

Any

Java 8/11

Upgrade to Java 17 while upgrading to 3.71.0+ following normal upgrade procedures

How to Change Your Java Version

H2

3.70.x

Java 17

No additional actions; follow normal upgrade procedures

H2

3.70.x

Java 8/11

Upgrade to Java 17 while upgrading to 3.71.0+ following normal upgrade procedures

How to Change Your Java Version

H2

3.69.0

Java 17

Specific Upgrade instructions for 3.69.0 deployments on H2 and Java 17

H2

3.69.0

Java 8/11

Specific Upgrade instructions for 3.69.0 deployments on H2 and Java 8/11

H2

3.68.x or earlier

Java 8/11

Specific Upgrade instructions for pre-3.69.0 deployments on H2 and Java 8/11

OrientDB

3.70.x

Java 8/11

Specific Upgrade instructions for 3.70.x deployments on OrientDB and Java 8/11

OrientDB

3.69.x or earlier

Java 8/11

Specific Upgrade instructions for 3.69.0 and earlier deployments using OrientDB and Java 8/11

Frequently Asked Questions

This section covers frequently asked questions related to upgrading to 3.71.0+.

  • Do I have to buy a Pro license to upgrade to version 3.71.0+?

    As of 3.70.0, users may migrate to an H2 database.

    As of 3.77.0+, Community Edition users may migrate to a PostgreSQL (recommended) database.

  • When is OrientDB going away?

    OrientDB is in extended maintenance. OrientDB is no longer included in Nexus Repository versions 3.71.0 and beyond. We will support OrientDB in our 3.70.x release line, including releasing patches to the 3.70.x line for the near term.

    Download the latest 3.70.x release from our OrientDB Downloads page.

  • Do I have to get off of OrientDB to keep using Nexus Repository?

    We recommend everyone migrate off of OrientDB as soon as possible. OrientDB is supported in our 3.70.x release line for security fixes but will not receive new features.

    To upgrade to a newer version migrate to the internal H2 or external PostgreSQL (preferred) database.

  • Why did we remove OrientDB from versions 3.71.0+?

    As detailed in our Nexus Repository 3 sunsetting information, Sonatype is invested in continually improving our solutions to take advantage of newer, more advanced technologies. As such, we are strategically moving away from legacy technologies like OrientDB and investing in supporting newer database options. Moreover, Sonatype has observed data integrity problems in deployments using OrientDB.

Upgrading to 3.71.0+ for Instances Using H2, Nexus Repository Version 3.69.0, and Java 8 or 11

Nexus Repository versions from 3.70.0 and beyond require a version 2.x H2 database; previous Nexus Repository versions used a version 1.x database. Therefore, you will need to run a task to export your H2 v1.x database before upgrading Nexus Repository. Sonatype added this task in version 3.69.0, so you must be on 3.69.0 before proceeding. The sections below will walk you through this process.

Nexus Repository version 3.71.0 and above require Java 17, so you will need to upgrade your Java version before you can upgrade to 3.71.0.

The sections below walks through the process.

H2_369_Java811

Phase 1 - Export your H2 Database from your 3.69.x Instance

Upgrading your H2 database involves generating an export of that database; should any changes continue to be made in your Nexus Repository instance after generating this export, those changes will be lost and not included in the exported file. To minimize any potential for lost information during the upgrade period, complete the following prerequisite steps immediately before upgrading Nexus Repository:

  1. In version 3.69.0, create and run the Admin - Export SQL database to script task.

  2. Check the $data-dir/db folder for the file that the task created; it will have a name like "nexus-<timestamp>.sql."

You can now continue to upgrade your Java and Nexus Repository versions.

Phase 2 - Upgrade Your H2 Database, Java Version, and Nexus Repository Instance

Since Nexus Repository 3.71.0+ requires Java 17, you will need to change your Java version while upgrading your Nexus Repository instance. If you are unsure how to do this, refer to our documentation on how to change your Java version. Otherwise, your upgrade follows normal upgrade procedures with the following additional steps to upgrade your H2 database:

  1. Before starting your upgraded Nexus Repository instance, ensure the $data-dir/db folder contains the previously built nexus-<timestamp>.sql file and the H2 database file called "nexus.mv.db." Do not remove or rename the nexus.mv.db file.

  2. Start your Sonatype Nexus Repository instance.

  3. Sonatype Nexus Repository will now perform the H2 upgrade.

    1. As part of the upgrade process, Nexus Repository will create a backup of the H2 v1.4.200 database in the $data-dir/db folder should you need it for rollback purposes. This file will be called nexus-<timestamp>-backup.zip.

    2. Note that if multiple nexus-<timestamp>.sql files exist in the $data-dir/db folder, Nexus Repository will use the file with the most recent timestamp to create the H2 v2.2.224 database.

  4. Verify that Nexus Repository started correctly with all expected repository information.

  5. You can now delete the SQL and backup files.

Upgrading to 3.71.0+ for Instances Using H2, Nexus Repository 3.69.0, and Java 17

Nexus Repository versions from 3.70.0 and beyond require a version 2.x H2 database; previous Nexus Repository versions used a version 1.x database. Therefore, you will need to run a task to export your H2 v1.x database before upgrading Nexus Repository. Sonatype added this task in version 3.69.0, so you must be on 3.69.0 before proceeding. The sections below will walk you through this process.

H2_369_java17.png

Phase 1 - Export your H2 Database from your 3.69.x Instance

Upgrading your H2 database involves generating an export of that database; should any changes continue to be made in your Nexus Repository instance after generating this export, those changes will be lost and not included in the exported file. To minimize any potential for lost information during the upgrade period, complete the following prerequisite steps immediately before upgrading Sonatype Nexus Repository:

  1. In version 3.69.0, create and run the Admin - Export SQL database to script task.

  2. Check the $data-dir/db folder for the file that the task created; it will have a name like "nexus-<timestamp>.sql."

You can now continue to upgrade your Nexus Repository version.

Phase 2 - Upgrade Your Nexus Repository Instance and H2 Database

  1. Follow normal upgrade procedures to upgrade Nexus Repository to 3.71.0.

  2. Before starting your upgraded Nexus Repository instance, ensure the $data-dir/db folder contains the previously built nexus-<timestamp>.sql file and the H2 database file called "nexus.mv.db." Do not remove or rename the nexus.mv.db file.

  3. Start your Sonatype Nexus Repository instance.

  4. Sonatype Nexus Repository will now perform the H2 upgrade.

    1. As part of the upgrade process, Nexus Repository will create a backup of the H2 v1.4.200 database in the $data-dir/db folder should you need it for rollback purposes. This file will be called nexus-<timestamp>-backup.zip.

    2. Note that if multiple nexus-<timestamp>.sql files exist in the $data-dir/db folder, Nexus Repository will use the file with the most recent timestamp to create the H2 v2.2.224 database.

  5. Verify that Nexus Repository started correctly with all expected repository information.

  6. You can now delete the SQL and backup files.

Upgrading to 3.71.0+ for Instances Using H2, a Pre-3.69.0 Nexus Repository Version, and Java 8 or 11

Nexus Repository versions 3.70.0 and above require that your H2 database be on version 2.x; earlier Nexus Repository versions used H2 version 1.x. In release 3.69.0, we added a task to help you upgrade your H2 database. Therefore, you will need to upgrade to 3.69.0 before you can continue beyond that version.

Nexus Repository version 3.71.0 and above also require Java 17, so you will need to upgrade your Java version before you can upgrade to 3.71.0.

H2_Pre368_Java811.png

The sections below will walk you through the process.

Phase 1 - Upgrade to 3.69.x and Export Database

Upgrading your H2 database involves generating an export of that database; should any changes continue to be made in your Nexus Repository instance after generating this export, those changes will be lost and not included in the exported file. To minimize any potential for lost information during the upgrade period, complete the following prerequisite steps immediately before upgrading to Sonatype Nexus Repository 3.70.0+:

  1. Upgrade to Sonatype Nexus Repository version 3.69.0.

  2. In version 3.69.0, create and run the Admin - Export SQL database to script task.

  3. Check the $data-dir/db folder for the file that the task created; it will have a name like "nexus-<timestamp>.sql."

You can now continue to upgrade to 3.71.0 while also upgrading to Java 17.

Phase 2 - Upgrade Your H2 Database, Java Version, and Nexus Repository Instance

Since Nexus Repository 3.71.0+ requires Java 17, you will need to change your Java version while upgrading your Nexus Repository instance. If you are unsure how to do this, refer to our documentation on how to change your Java version. Otherwise, your upgrade follows normal upgrade procedures with the following additional steps to upgrade your H2 database:

  1. Before starting your upgraded Nexus Repository instance, ensure the $data-dir/db folder contains the previously built nexus-<timestamp>.sql file and the H2 database file called "nexus.mv.db." Do not remove or rename the nexus.mv.db file.

  2. Start your Sonatype Nexus Repository instance.

  3. Sonatype Nexus Repository will now perform the H2 upgrade.

    1. As part of the upgrade process, Nexus Repository will create a backup of the H2 v1.4.200 database in the $data-dir/db folder should you need it for rollback purposes. This file will be called nexus-<timestamp>-backup.zip.

    2. Note that if multiple nexus-<timestamp>.sql files exist in the $data-dir/db folder, Nexus Repository will use the file with the most recent timestamp to create the H2 v2.2.224 database.

  4. Verify that Nexus Repository started correctly with all expected repository information.

  5. You can now delete the SQL and backup files.

Upgrading to 3.71.0+ for Instances Using OrientDB, Nexus Repository 3.70.x, and Java 8 or 11

Nexus Repository 3.71.0 and beyond does not support an OrientDB database. To upgrade to version 3.71.0+, you will need to migrate to an H2 or PostgreSQL database.

Nexus Repository 3.71.0 and beyond also requires Java 17, so you will need to upgrade your Java version before upgrading to 3.71.0+.

Orient_370_java811.png

The sections below will walk you through the process.

Phase 1 - Migrate to H2 or PostgreSQL

In this phase, you will migrate your Nexus Repository instance to an H2 or PostgreSQL database.

Considerations Before Migrating

Review the following considerations before migrating:

  • Migration is non-destructive

    The original Orient database is not changed and may be used as a recovery point.

  • Migration is one-way

    The migrator does not support migrating back to OrientDB from H2 or PostgreSQL. Running the migrator again overwrites any data in the target database.

  • Test the migration before running in production

    We recommended performing a test migration using a backup of your production instance. Be aware that a backup instance connecting to cloud blob stores may still be connected to production data.

  • Review the difference in the search feature and cleanup policies

    Searching works differently in H2 and PostgreSQL databases. Evaluate that cleanup policies identify the correct components for cleanup.

  • Unsupported formats

    PostgreSQL and H2 do not support Bower or the community formats (e.g., APK, Composer, CPAN, Puppet). Unsupported formats are not migrated.

  • NuGet v2 client compatibility

    A subset of Nuget v2 protocol does not work the same as from Orient DB.

  • Review custom plug-ins

    Custom plugins that interact with the database, assets, or components may no longer work with the new databases. Adjust custom plug-ins to work with H2 or PostgreSQL database.

  • Migrating directly to the cloud from on-premises is not supported

    Your DevOps engineer's responsibility is to set up the underlying architecture to ensure that the migrator has access to the on-premises file system and new database before performing a database migration.

Migration Environment Prerequisite Requirements

Review the requirements below for the database migration:

  • The database migrator requires OpenJDK

    The database migrator does not support Oracle JDK. OrientDB requires using Java 8 or 11.

  • Use the migrator that matches your Nexus Repository version

    Visit Downloads to get the supported version. We recommend upgrading to the latest version first when possible.

  • OrientDB migration requirements

    Your Nexus Repository instance must be on the latest 3.70.x version to migration from OrientDB.

    See OrientDB Deployments.

  • High-availability deployments require adjusting the default max connections

    Multiple nodes connecting to the same database require increasing the allowed connections to PostgreSQL.

    See Adjusting the PostgreSQL Max Connections

  • The database user must be the owner of the database

    The following example creates a user and a database owned by that user:

    CREATE USER <username> WITH PASSWORD '<password>';
CREATE DATABASE <db-name> WITH OWNER <username> ENCODING 'UTF8';
  • The migrator requires at least 16GM of RAM available
  • The migrator requires three times the disk space as your instance's database directory (minimum 10 GB)

    The $data-dir/db directory and the temp directory must have enough space for both the backup and the extracted backup to the tmp directory.

Migrating From OrientDB to PostgreSQL

The section below covers migrating your Nexus Repository instance from OrientDB to an external PostgreSQL database.

When using AWS Aurora as your database, include gssEncMode=disable as a query parameter of JDBC URL.

  1. Create a database called nexus on the PostgreSQL server. Use UTF8 as its character set to be compatible with Nexus Repository.

  2. We recommend setting the PostgreSQL autovacuum configuration to be on.

  3. In the sonatype-work/nexus3/etc/fabric/ directory (i.e., $data-dir/etc/fabric), create nexus-store.properties; below is a sample that you will need to update with the appropriate configuration.

    The user provided must be the database owner.

    username=<postgres_user>
password=<postgres_password> 
jdbcUrl=jdbc\:postgresql\://<database-host>\:<database-port>/nexus

    For versions 3.31.0 - 3.34.1, you will need the following additional properties in your nexus-store.properties file:

    name=nexus
type=jdbc

  4. Servers under heavy load may also need to configure the connection pool size for the database. Nexus Repository uses a default pool of 100, but you may increase this by appending a line like the following example to nexus-store.properties:

    advanced=maximumPoolSize\=200

  5. Add the following to $data-dir/etc/nexus.properties

    nexus.datastore.enabled=true

  6. Perform a full backup using the backup task

  7. Copy the backup to a clean working location on a different filesystem so that any extraction doesn’t impact the existing production system

  8. Shut down Nexus Repository

  9. Update and run the following command from the location containing your database backup. Use the appropriate values for host, port, username, password, and migrator utility jar file name.

    The following parameter is needed for OrientDB Java 11 deployments.

    --add-exports java.base/sun.nio.ch=ALL-UNNAMED
    java -Xmx16G -Xms16G -XX:+UseG1GC \
-XX:MaxDirectMemorySize=28672M \
-jar nexus-db-migrator-*.jar \
--migration_type=postgres \
--db_url="jdbc:postgresql://<database URL>:<port>/nexus?user=<postgres_user>&password=<postgres_password>"

    When using database names and schemas that do not match, you need to add the variable &currentSchema=<name> to the end of the line. This variable is optional as this is not expected in a standard setup.

    • <database URL>:<port> – This is the URL to your Postgres database

    • nexus – database name

    • user – database user

    • password– database user password

    • currentSchema=nexus – example database schema (optional).

    • Use 2 dashes before the full-named parameters.

    • Use the db_url parameter value with double quotes.

  10. Run the following command on the Nexus Repository database after migrating but before starting Nexus Repository. This will reclaim storage occupied by obsoleted tuples left from the migration.

    VACUUM(FULL, ANALYZE, VERBOSE);

  11. Start Nexus Repository.

    Ensure you are still on the same Nexus Repository version you were before the migration (e.g., if you were using 3.70.x, start your newly migrated instance as 3.70.x before upgrading beyond this).

    Post-migration tasks must be completed before you can upgrade your Nexus Repository version.

    If you encounter errors during the migration to PostgreSQL, it may be necessary to recreate the PostgreSQL database (or schema) before retrying the migration. This ensures a clean environment for the migration process.

Optional Parameters

  • -y, --yes:

    Parameter to skip waiting for user input and assume a "yes" response to the initial warning.

  • --content_migration=false

    Parameter to only migrate the security and config tables: users, roles, and blobstore configuration. Repository content is not migrated.

  • --shutdown_compact=false

    Parameter to disable H2 Content DB compression; this is set to true by default.

  • --healthcheck

    Parameter to run a health check on your OrientDB database. This check focuses on detecting and reporting existing corruption in component and asset classes. The migration will not occur when using this parameter.

    java -jar nexus-db-migrator-*.jar --healthcheck

    The optional healthcheck parameter has been known to cause the migration command to fail when they try to run it against the OrientDB "*.bak" files. Do not use the "--healthcheck" option with *.bak files.

Migrating From OrientDB to H2

Migrate Nexus Repository instance from OrientDB to H2.

  1. Perform a database backup using the Admin - Export Database for backup task. We recommend copying the backup to another filesystem to avoid impacting the production environment.

    The migrator uses the following backup files:

    component-<timestamp>.bak
config-<timestamp>.bak 
security-<timestamp>.bak

  2. Shut down Nexus Repository.

  3. Run the following command from the location containing your backup.

    java -Xmx16G -Xms16G -XX:+UseG1GC \ 
  -XX:MaxDirectMemorySize=28672M \ 
  -jar nexus-db-migrator-*.jar \ 
  --migration_type=h2

  4. Copy the produced nexus.mv.db file to your $data-dir/db directory.

    See Directories for details.

  5. Edit the $data-dir/etc/nexus.properties file with the following line:

    nexus.datastore.enabled=true

  6. Start Nexus Repository.

  7. Complete the post-migration tasks before upgrading Nexus Repository.

Optional Parameters

  • -y, --yes:

    Skip waiting for user input and assume a yes response to the initial warning.

  • --content_migration=false

    Parameter to migrate the security and config tables: users, roles, and blobstore configuration.

    Repository content is not migrated.

  • --shutdown_compact=false

    Parameter to disable H2 Content DB compression; this is true by default.

Phase 2 - Upgrade Nexus Repository and Java

You can now upgrade your Nexus Repository instance to 3.71.0+ but will also need to upgrade your Java version to Java 17; Nexus Repository 3.71.0+ do not support Java 8 or 11. If you do not know how to change your Java version, see our documentation on how to change your Java version.

Otherwise, follow normal upgrade procedures; see our help documentation for upgrading a standalone instance.

Upgrading to 3.71.0+ for Instances Using OrientDB, a Pre-3.70.1 Nexus Repository Version, and Java 8 or 11

After the 3.70.x version, Nexus Repository does not include the OrientDB database. Follow these steps to upgrade to a newer version of Nexus Repository.

Orient_369_java811.png
  1. Upgrade to the Latest Nexus Repository 3.70.x Version

    Upgrade to the latest branch of version 3.70.x using the standard upgrade procedures. You will still use Java 8 or 11 as OrientDB does not support Java 17. Start the instance before proceeding to ensure everything works as expected.

    See the Upgrade Instructions

  2. Use the Database Migrator to switch to the database

    Nexus Repository Pro deployments may switch to PostgreSQL, however, Community Edition users will need to use the H2 database until upgrading to the 3.77.0 release.

    See the Phase 2 section for details on migrating the database.

  3. Upgrade your Java version before upgrading to 3.71.0 or later.

    Upgrade to Java version 17 before upgrading to 3.71.0 or later. Nexus Repository 3.71.0 and later do not support Java 8 or 11.

    See how to change your Java version.

Phase 2 - Migrate to H2 or PostgreSQL

In this phase, you will migrate your Nexus Repository instance to an H2 or PostgreSQL database. Note that PostgreSQL requires a paid Nexus Repository Pro license.

Considerations Before Migrating

Review the following considerations before migrating:

  • Migration is non-destructive

    The original Orient database is not changed and may be used as a recovery point.

  • Migration is one-way

    The migrator does not support migrating back to OrientDB from H2 or PostgreSQL. Running the migrator again overwrites any data in the target database.

  • Test the migration before running in production

    We recommended performing a test migration using a backup of your production instance. Be aware that a backup instance connecting to cloud blob stores may still be connected to production data.

  • Review the difference in the search feature and cleanup policies

    Searching works differently in H2 and PostgreSQL databases. Evaluate that cleanup policies identify the correct components for cleanup.

  • Unsupported formats

    PostgreSQL and H2 do not support Bower or the community formats (e.g., APK, Composer, CPAN, Puppet). Unsupported formats are not migrated.

  • NuGet v2 client compatibility

    A subset of Nuget v2 protocol does not work the same as from Orient DB.

  • Review custom plug-ins

    Custom plugins that interact with the database, assets, or components may no longer work with the new databases. Adjust custom plug-ins to work with H2 or PostgreSQL database.

  • Migrating directly to the cloud from on-premises is not supported

    Your DevOps engineer's responsibility is to set up the underlying architecture to ensure that the migrator has access to the on-premises file system and new database before performing a database migration.

Migration Environment Prerequisite Requirements

Review the requirements below for the database migration:

  • The database migrator requires OpenJDK

    The database migrator does not support Oracle JDK. OrientDB requires using Java 8 or 11.

  • Use the migrator that matches your Nexus Repository version

    Visit Downloads to get the supported version. We recommend upgrading to the latest version first when possible.

  • OrientDB migration requirements

    Your Nexus Repository instance must be on the latest 3.70.x version to migration from OrientDB.

    See OrientDB Deployments.

  • High-availability deployments require adjusting the default max connections

    Multiple nodes connecting to the same database require increasing the allowed connections to PostgreSQL.

    See Adjusting the PostgreSQL Max Connections

  • The database user must be the owner of the database

    The following example creates a user and a database owned by that user:

    CREATE USER <username> WITH PASSWORD '<password>';
CREATE DATABASE <db-name> WITH OWNER <username> ENCODING 'UTF8';
  • The migrator requires at least 16GM of RAM available
  • The migrator requires three times the disk space as your instance's database directory (minimum 10 GB)

    The $data-dir/db directory and the temp directory must have enough space for both the backup and the extracted backup to the tmp directory.

Migrating From OrientDB to PostgreSQL

The section below covers migrating your Nexus Repository instance from OrientDB to an external PostgreSQL database.

When using AWS Aurora as your database, include gssEncMode=disable as a query parameter of JDBC URL.

  1. Create a database called nexus on the PostgreSQL server. Use UTF8 as its character set to be compatible with Nexus Repository.

  2. We recommend setting the PostgreSQL autovacuum configuration to be on.

  3. In the sonatype-work/nexus3/etc/fabric/ directory (i.e., $data-dir/etc/fabric), create nexus-store.properties; below is a sample that you will need to update with the appropriate configuration.

    The user provided must be the database owner.

    username=<postgres_user>
password=<postgres_password> 
jdbcUrl=jdbc\:postgresql\://<database-host>\:<database-port>/nexus

    For versions 3.31.0 - 3.34.1, you will need the following additional properties in your nexus-store.properties file:

    name=nexus
type=jdbc

  4. Servers under heavy load may also need to configure the connection pool size for the database. Nexus Repository uses a default pool of 100, but you may increase this by appending a line like the following example to nexus-store.properties:

    advanced=maximumPoolSize\=200

  5. Add the following to $data-dir/etc/nexus.properties

    nexus.datastore.enabled=true

  6. Perform a full backup using the backup task

  7. Copy the backup to a clean working location on a different filesystem so that any extraction doesn’t impact the existing production system

  8. Shut down Nexus Repository

  9. Update and run the following command from the location containing your database backup. Use the appropriate values for host, port, username, password, and migrator utility jar file name.

    The following parameter is needed for OrientDB Java 11 deployments.

    --add-exports java.base/sun.nio.ch=ALL-UNNAMED
    java -Xmx16G -Xms16G -XX:+UseG1GC \
-XX:MaxDirectMemorySize=28672M \
-jar nexus-db-migrator-*.jar \
--migration_type=postgres \
--db_url="jdbc:postgresql://<database URL>:<port>/nexus?user=<postgres_user>&password=<postgres_password>"

    When using database names and schemas that do not match, you need to add the variable &currentSchema=<name> to the end of the line. This variable is optional as this is not expected in a standard setup.

    • <database URL>:<port> – This is the URL to your Postgres database

    • nexus – database name

    • user – database user

    • password– database user password

    • currentSchema=nexus – example database schema (optional).

    • Use 2 dashes before the full-named parameters.

    • Use the db_url parameter value with double quotes.

  10. Run the following command on the Nexus Repository database after migrating but before starting Nexus Repository. This will reclaim storage occupied by obsoleted tuples left from the migration.

    VACUUM(FULL, ANALYZE, VERBOSE);

  11. Start Nexus Repository.

    Ensure you are still on the same Nexus Repository version you were before the migration (e.g., if you were using 3.70.x, start your newly migrated instance as 3.70.x before upgrading beyond this).

    Post-migration tasks must be completed before you can upgrade your Nexus Repository version.

    If you encounter errors during the migration to PostgreSQL, it may be necessary to recreate the PostgreSQL database (or schema) before retrying the migration. This ensures a clean environment for the migration process.

Optional Parameters

  • -y, --yes:

    Parameter to skip waiting for user input and assume a "yes" response to the initial warning.

  • --content_migration=false

    Parameter to only migrate the security and config tables: users, roles, and blobstore configuration. Repository content is not migrated.

  • --shutdown_compact=false

    Parameter to disable H2 Content DB compression; this is set to true by default.

  • --healthcheck

    Parameter to run a health check on your OrientDB database. This check focuses on detecting and reporting existing corruption in component and asset classes. The migration will not occur when using this parameter.

    java -jar nexus-db-migrator-*.jar --healthcheck

    The optional healthcheck parameter has been known to cause the migration command to fail when they try to run it against the OrientDB "*.bak" files. Do not use the "--healthcheck" option with *.bak files.

Migrating From OrientDB to H2

Migrate Nexus Repository instance from OrientDB to H2.

  1. Perform a database backup using the Admin - Export Database for backup task. We recommend copying the backup to another filesystem to avoid impacting the production environment.

    The migrator uses the following backup files:

    component-<timestamp>.bak
config-<timestamp>.bak 
security-<timestamp>.bak

  2. Shut down Nexus Repository.

  3. Run the following command from the location containing your backup.

    java -Xmx16G -Xms16G -XX:+UseG1GC \ 
  -XX:MaxDirectMemorySize=28672M \ 
  -jar nexus-db-migrator-*.jar \ 
  --migration_type=h2

  4. Copy the produced nexus.mv.db file to your $data-dir/db directory.

    See Directories for details.

  5. Edit the $data-dir/etc/nexus.properties file with the following line:

    nexus.datastore.enabled=true

  6. Start Nexus Repository.

  7. Complete the post-migration tasks before upgrading Nexus Repository.

Optional Parameters

  • -y, --yes:

    Skip waiting for user input and assume a yes response to the initial warning.

  • --content_migration=false

    Parameter to migrate the security and config tables: users, roles, and blobstore configuration.

    Repository content is not migrated.

  • --shutdown_compact=false

    Parameter to disable H2 Content DB compression; this is true by default.