Upgrade fails with db_migrations_pkey duplicate key error

I have a personal MM instance that was upgraded from a MySQL database last year. It was on version 10.5.14 (ESR). System is AlmaLinux-10, postgresql-server-16.13-1.

Today I upgraded it to 10.11.18 (ESR) without any apparent issues. I then attempted to upgrade that to 11.7.1 (ESR) and mattermost would no longer start. The log has repeated instances of:

{"timestamp":"2026-05-25 14:15:22.787 -04:00","level":"error","msg":"failed to initialize platform: cannot create store: failed to apply database migrations: driver: postgres, m
essage: failed to execute migration, command: executing_query, originalError: pq: duplicate key value violates unique constraint \"db_migrations_pkey\" (23505), query: \n\nINSER
T INTO db_migrations (version, name) VALUES (142, 'create_content_flagging_tables')\n","caller":"commands/server.go:75"}

Do I need to go to a different release first? I didn’t see any earlier 11.x releases tagged ESR.

Follow-up, looks like this is a bug: [Bug]: create_content_flagging_tables fails to migrate from 10.11.17 to 11.7.0 · Issue #36594 · mattermost/mattermost · GitHub

For this Mattermost upgrade error, I’d first treat it as a migration/state issue, not immediately as database corruption. The error is basically saying the migration table already has that version entry, so Mattermost is trying to insert something that exists already.

I’d do the safer checks first:

Take a DB backup/snapshot.
Check the migration table:
SELECT * FROM db_migrations ORDER BY version DESC;
Confirm which migration is failing from the Mattermost logs.
Make sure you are following the correct upgrade path — skipping releases can cause migration problems.

If it is just a duplicate migration entry, fixing the migration state may solve it. Don’t delete rows blindly without a backup.

If the upgrade left the database actually damaged (corrupted tables, failed reads, etc.), then a tool like Stellar Repair for MySQL can be a last recovery option to extract data from a damaged MySQL/MariaDB database. But for this error, I’d investigate the migration records first.