-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sever update from 1.112 to 1.113 fails citing duplicate key in migration. #12245
Comments
Update, going back to 1.112.1 images works just fine. |
Yes, this is unrelated. It doesn't really make sense to me, though. This is a new table and there should be no way for that insert command to violate the unique constraint. It might indicate corruption. |
As a first step, I recommend backing up the database. Then try connecting to the DB and running the |
Okay, Stopped all services, made a file based backup (because I didn't really quickly see how to do a DB backup and figured that if anything, replacing all the DB files will take me back to where I was) Restarted the services I connected via ssh: sudo docker exec -it immich_postgres psql --dbname=immich --username=postgres --command="VACUUM FULL;" With that return should I try the update again? |
Yup, you can try again now. |
Nah, got the same thing I think (sorry, I'm reading remotely so I didn't intensely look at the logs) 2024/09/03 07:33:42 stdout Detected CPU Cores: 4 |
I'm having the same problem after upgrading to v1.114.0 :( any workarounds?
|
for folks hitting this issue like me, i downgraded to v1.112.1 by adding this into .env file
Then |
Hello, Update, but no luck. I tried the steps under Docs/Administration/Backup and Restore $database I did take the time to directly run immich on my insanely powerful desktop (I use another hypervisor that doesn't run with WSL) and let it chew through rebuilding since I had not yet really done anything that couldn't be redone. So while this has thumb data that is nearly 1TB and the new one is less than 100GB so far, I will keep this totally intact for a while in case there is want to revist this issue, but for now I'm going to run with known good. This second try was started on 1.113.1 and later that day 1.114 was released and after the two place days of work, it finished and upgraded easily. [skippable] [End-skip] [Server output upgrading to 1.114] 2024/09/09 12:18:56 stdout Detected CPU Cores: 4 2024/09/09 12:18:44 stderr microservices worker exited with code 1 2024/09/09 12:18:44 stderr } 2024/09/09 12:18:44 stderr routine: 'transformFkeyCheckAttrs' 2024/09/09 12:18:44 stderr line: '11081', 2024/09/09 12:18:44 stderr line: '11081', 2024/09/09 12:18:44 stderr at async /usr/src/app/dist/services/database.service.js:105:17 2024/09/09 12:18:44 stderr at async DatabaseRepository.runMigrations (/usr/src/app/dist/repositories/database.repository.js:191:9) 2024/09/09 12:18:44 stderr at async DataSource.runMigrations (/usr/src/app/node_modules/typeorm/data-source/DataSource.js:265:35) 2024/09/09 12:18:44 stderr at async MigrationExecutor.executePendingMigrations (/usr/src/app/node_modules/typeorm/migration/MigrationExecutor.js:225:17) 2024/09/09 12:18:44 stderr at async AddAssetFilesTable1724101822106.up (/usr/src/app/dist/migrations/1724101822106-AddAssetFilesTable.js:9:9) 2024/09/09 12:18:44 stderr at async PostgresQueryRunner.query (/usr/src/app/node_modules/typeorm/driver/postgres/PostgresQueryRunner.js:184:25) 2024/09/09 12:18:44 stderr at process.processTicksAndRejections (node:internal/process/task_queues:95:5) 2024/09/09 12:18:44 stderr at /usr/src/app/node_modules/pg/lib/client.js:526:17 2024/09/09 12:18:44 stderr driverError: error: there is no unique constraint matching given keys for referenced table "assets" 2024/09/09 12:18:44 stderr parameters: undefined, 2024/09/09 12:18:44 stdout Migration "AddAssetFilesTable1724101822106" failed, error: there is no unique constraint matching given keys for referenced table "assets 2024/09/09 12:18:26 stdout Starting api worker 2024/09/09 12:18:20 stdout Detected CPU Cores: 4 [end-server output] [pg_dump restore] gunzip < "/volume1/docker/immich_bck.sql.gz" \
public, pg_catalog SET
|
was able to fix it by running |
Awesome @harshit181 I might be able to figure this figure this out but if you feel like posting a step by step, I'd be grateful. Once I try this, if successful I'll also note any changes for Synology. |
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
The bug
The server only runs for about a minute then dies, it auto restarts but goes though the same thing. I see a complaint about a duplicate key in the migration and that it violates a policy.
The system has 16GB of ram and the initial import was done via another system and them moved in as it would take too long to build such a large cache of thumbnails and other metadata. The other system was WSL2 based.
After comparing the changes in the docker-compose.yml and seeing that there was nothing really new. I removed the containers, deleted the images and rebuilt the project, same has I have done since 1.110 (I think)
Will try going back to 1.112 like similar issue: 12243
The OS that Immich Server is running on
Synology DSM 7.2.1
Version of Immich Server
1.113.0
Version of Immich Mobile App
N/A
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
1.Run Immich 1.112 and create system
2.Go through steps to update to 1.113
3.
...
Relevant log output
Additional information
No response
The text was updated successfully, but these errors were encountered: