ARTIFACTORY: How to Resolve Upgrade Startup Failures Caused by Duplicate 'groupDn' Keys in Access Database Migration

Introduction 
This article addresses an issue where Artifactory fails to start during or after a version upgrade (7.111.x and above). The failure is characterized by the Artifactory application failing to initialize and refusing local connections, with the access-service.log pointing to a Flyway database migration error. This issue is triggered by a unique constraint violation on the access_groups_data_pk index. The solution involves manually removing the duplicate groupDn entries from the database to allow the migration script to complete successfully.

Important: 

This troubleshooting procedure is only applicable when upgrading from a version older than 7.111.x to a newer version. If you are already running Artifactory version 7.111.x or higher, this migration has already been completed, and these steps should not be performed for future upgrades (e.g. upgrading from 7.125.x to 7.133.x).


Problem
When upgrading Artifactory, particularly in a clustered environment, one or more nodes may fail to start. During this time, you may see "Connection refused" errors in the artifactory-service.log indicating that the cluster join or service registry ping failed.
If you examine the access-service.log, you will observe a Flyway migration error similar to the following:

Could not initialize database:
org.flywaydb.core.api.exception.FlywayValidateException: Validate failed: Migrations have failed validation
Detected failed migration to version 7.1136.0.0 (AddGroupDnToCustomData).
…
org.flywaydb.core.internal.exception.FlywayMigrateException: SQL State: 23505
Message: ERROR: duplicate key value violates unique constraint "access_groups_data_pk"
Detail: Key (group_id, prop_key)=(<id>, groupDn) already exists.

This occurs because the Access service attempts to migrate group data (specifically groupDn entries) from the access_groups table to a new custom data table (access_groups_custom_data). If a previous upgrade attempt was interrupted, failed midway, or if nodes were upgraded out of sync, these groupDn entries may have already been partially copied over. When the startup migration script runs again, it encounters the existing entries, violates the unique constraint, and blocks the application from starting.


Resolution 
To resolve this issue, the duplicate groupDn entries must be manually deleted from the database so the Flyway migration can execute cleanly on startup.

Step-by-Step Instructions

1. Connect to your Artifactory database.
   
2. Back up the target table: Before making any modifications, it is highly recommended to create a backup of the access_groups_custom_data table. You can use your database's native export tools or execute a query to create a copy of the table. For example:
   

   CREATE TABLE access_groups_custom_data_bkp AS 
   SELECT * FROM access_groups_custom_data;

   
   
3. Verify the duplicate entries: Confirm the presence of the problematic groupDn entries before deleting them. Run the following SELECT query:
   

   SELECT * FROM access_groups_custom_data WHERE group_id = <id> AND prop_key = 'groupDn';

   
   
4. Delete the conflicting records: Once confirmed, execute the DELETE statement to clear the existing groupDn properties that are blocking the migration, as well as the failed Access migration record from the access_schema_version table:
   

   DELETE FROM access_groups_custom_data WHERE group_id = <id> AND prop_key = 'groupDn';
   
   DELETE FROM access_schema_version WHERE version = '7.1136.0.0';

   
   
5. Restart Artifactory: Restart the Artifactory service on the affected node(s). With the duplicate entries removed, the database migration should now complete successfully and the application will start.