I have taken over responsibility for my org's internal artifactory server which has been around about a decade or so. My experience with artifactory specifically is quite minimal though I do have 30 years of Linux experience and about 24 years of working with various java apps.
I have a "pro" license, though last I heard that doesn't come with any actual formal support so am trying the community for any ideas.
Currently it runs 7.77.11(for this testing I am using a local MariaDB 11.8.5), and the documentation made it sound like upgrading was super simple so I just decided to go at it(upgrade to latest version) in production, that blew up and after 3 hours I rolled back. A couple of days ago I built a nonprod system and made copies of the DB and the artifactory repo(~260k artifacts around 1.5TB). I am using the tarball distribution of artifactory on Ubuntu 24.04 with Java 17. I do see the docs explicitly state for artifactory 7.x the user can jump to the latest version without intermediate jumps.
I tried going to the latest version and just got tons of SQL/schema/migration errors, so I thought try a more conservative upgrade path(I restore from backups and go back to the original version each time I test).
I've been trying for about 6 hours now all attempts have failed.
I can go from 7.77.11 to 7.77.17 without an issue, in case it is useful the md_database_migrations table in the DB shows 51 rows with the most recent being v051_md_fil_qualifiers_delete_cascade.sql
If I try to go from there to either 7.84.10 or 7.84.23, I get different errors, regarding unable to create a projects table that already:
2026-08-26T17:09:10.767Z [jfac ][ERROR] [2043437a33563bda] [o.f.c.i.c.DbMigrate:296 ] [Catalina-utility-2 ] - Migration of schema `artifactorydb` to version 7.103.1 - Create projects v2 table failed! Please restore backups and roll back database and code!
2026-08-26T17:09:10.776Z [jfac ][ERROR] [2043437a33563bda] [.s.d.u.AccessJdbcHelperImpl:81] [Catalina-utility-2 ] - Could not initialize database:
org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException:
Migration V7_103_1__Create_projects_v2_table.sql failed
-------------------------------------------------------
SQL State : 42S01
Error Code : 1050
Message : Table 'access_projects' already exists
Location : db/mysql/migration/V7_103_1__Create_projects_v2_table.sql (/file:/data/artifactory-pro-7.84.10/app/artifactory/tomcat/webapps/access/WEB-INF/lib/access-server-core-7.106.9.jar!/db/mysql/migration/V7_103_1__Create_projects_v2_table.sql)
Line : 1
Statement : CREATE TABLE access_projects
(
id BIGINT,
project_key VARCHAR(255) NOT NULL,
name VARCHAR(255) NOT NULL,
description VARCHAR(255) NOT NULL,
created BIGINT NOT NULL,
modified BIGINT NOT NULL,
storage_quota_bytes BIGINT,
storage_quota_soft_limit BOOLEAN DEFAULT 0,
storage_quota_disable_email_notification BOOLEAN DEFAULT 0,
CONSTRAINT access_projects_pk PRIMARY KEY (id)
)
(java stack trace follows)
Following that failure I checked the md_database_migrations table again and still showed what appeared to be the same 51 rows.
So I hoped maybe that was just a bug or something so I decided to try the next version -
Going from 7.77.17 to 7.98.19 initially I got an odd schema error it was trying to create a table that already existed.
2026-08-26T19:22:47.275Z [jfmd ] [INFO ] [ ] [database_bearer.go:160 ] [main ] - Db connection driver::mysql and kerberosAuth::false [database]
2026-08-26T19:22:47.277Z [jfmd ] [INFO ] [ ] [database_bearer.go:175 ] [main ] - Connecting to (db config: {mysql jdbc:mysql://127.0.0.1/artifactorydb?characterEncoding=UTF-8&elideSetAutoCommits=true&useSSL=false}) [database]
2026-08-26T19:22:47.290Z [jfmd ] [INFO ] [ ] [migrator.go:63 ] [main ] - Applying migration files [database]
2026-08-26T19:22:47.291Z [jfmd ] [INFO ] [ ] [migrator.go:172 ] [main ] - Migration lock table created or is already present [database]
2026-08-26T19:22:47.291Z [jfmd ] [INFO ] [ ] [migration_lock_manager.go:49 ] [main ] - Trying to acquire migration lock for na-nonprod-artifactory-01.atl01.mydomain.com [database]
2026-08-26T19:22:47.294Z [jfmd ] [INFO ] [ ] [migration_lock_manager.go:70 ] [main ] - Migration lock acquired for na-nonprod-artifactory-01.atl01.mydomain.com [database]
2026-08-26T19:22:47.296Z [jfmd ] [INFO ] [ ] [migrator.go:142 ] [main ] - Applying 1 migrations files [database]
2026-08-26T19:22:47.297Z [jfmd ] [WARN ] [ ] [migrator.go:246 ] [main ] - This error occurred when upgrading the database : 'Error 1050 (42S01): Table 'md_version_repo_stats' already exists'. [database]
2026-08-26T19:22:47.297Z [jfmd ] [WARN ] [ ] [migrator.go:247 ] [main ] - The failing statement is 'CREATE TABLE md_version_repo_stats
(
repo_id BIGINT NOT NULL,
version_id BIGINT NOT NULL,
download_count BIGINT NOT NULL,
last_downloaded BIGINT NOT NULL,
remote_last_downloaded BIGINT NOT NULL,
PRIMARY KEY (repo_id, version_id),
CONSTRAINT md_version_repo_stats_repos_fk FOREIGN KEY (repo_id) REFERENCES md_repos (id),
CONSTRAINT md_version_repo_stats_versions_fk FOREIGN KEY (version_id) REFERENCES md_versions (id)
);'. [database]
2026-08-26T19:22:47.297Z [jfmd ] [WARN ] [ ] [migrator.go:248 ] [main ] - Your database is in an unexpected state or there is a temporary failure. [database]
2026-08-26T19:22:47.298Z [jfmd ] [WARN ] [ ] [migrator.go:250 ] [main ] - Once the problem is fixed you will need to do the upgrade by executing the following queries (in this order) then start the service : [database]
2026-08-26T19:22:47.298Z [jfmd ] [WARN ] [ ] [migrator.go:255 ] [main ] - 'INSERT INTO md_database_migrations (id,applied_at) VALUES (?,?)' with these parameters : [v052_md_version_repo_stats.sql 1787772167] [database]
2026-08-26T19:22:47.298Z [jfmd ] [ERROR] [ ] [migrator.go:239 ] [main ] - Migration v052_md_version_repo_stats.sql failed ! Rollback to latest successful migration. Err: Error 1050 (42S01): Table 'md_version_repo_stats' already exists. Panic : [database]
2026-08-26T19:22:47.298Z [jfmd ] [INFO ] [ ] [migration_lock_manager.go:76 ] [main ] - Trying to release lock owned by: na-nonprod-artifactory-01.atl01.mydomain.com [database]
2026-08-26T19:22:47.299Z [jfmd ] [INFO ] [ ] [migration_lock_manager.go:90 ] [main ] - Released lock owned by node na-nonprod-artifactory-01.atl01.mydomain.com [database]
2026-08-26T19:22:47.299Z [jfmd ] [ERROR] [ ] [application.go:99 ] [main ] - Could not execute database migrations Error 1050 (42S01): Table 'md_version_repo_stats' already exists
So I run this SQL:
INSERT INTO md_database_migrations (id,applied_at) VALUES ("v052_md_version_repo_stats.sql",1787772167);
Following that update I checked the md_database_migrations table again and showed 52 rows, with the one I just added being the new one.
So I restarted again, and got a familiar error regarding the projects table again(though no raw SQL logged). I ran tcpdump and captured the app inserting a row into the access_schema_version table.
2026-08-26T19:29:00.324Z [jfac ] [ERROR] [fe6310db5cbe7173] [.s.d.u.AccessJdbcHelperImpl:87] [main ] - Could not initialize database:
org.flywaydb.core.api.FlywayException: Detected failed migration to version 7.103.1 (Create projects v2 table)
at org.flywaydb.core.internal.info.MigrationInfoImpl.validate(MigrationInfoImpl.java:218)
at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.validate(MigrationInfoServiceImpl.java:327)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:174)
[..]
(lots of java stack traces saying the same thing)
I'm no DBA, I don't even play one on TV but I poked around in the DB (this is a nonprod system after all), and decided to try to trick artifactory into skipping that by doing this query (rank 63 is V7_103_1__Create_projects_v2_table.sql)
update access_schema_version set success = "1" where installed_rank = "63";
Then ran into the same issue with rank 65 (V7_104_1__Alter_projects_v2_table.sql) and rank 67 (V7_104_3__Environments_table.sql), and 69 (V7_105_1__Projects_resources_table.sql), and as I write this I am continuing down this path.. these are things that already exist in the DB. Each time I override, I restart, and artifactory inserts a new row into that table and then fails because the DB already has that info, then I stop it, update the row and restart, and repeat again..
I tried looking through all of the jars/wars but couldn't find these particular SQL files.
No idea why this is happening.. unsure if the person who setup/maintained this over the past decade ran into similar issues or not, I tried a bunch of web searches but came up with nothing.
thanks