Resolved Upgrade to 18.0.75 Integrity constraint violation: 1062 Duplicate entry 'localhost-database\_-user' for key 'PRIMARY':

[hschramm]

The script is generating the needed sql statements correctly to delete the doublicated entries without the escaping.

Then you are lucky. The script has a major flaw: it does not respect the "Host" field. So if a user adds ip adresses for limiting access to the database the script recognises these users as "duplicate" but this is wrong. So i had to write my own script for the problem to fix it.

 

[Hangover2]

@Hangover2 Thank you for the clarification. Could you please try manually running and let us know if it produce the same output:

plesk db "FLUSH PRIVILEGES;"

@Sebahat.hadzhi I’m confused. This database command does not re-run the failed upgrade step (2025-11-05-09-56-08_FixGrantPrivileges.php). How can we trigger that upgrade step again after fixing the duplicated entries?

 

[Hangover2]

Then you are lucky. The script has a major flaw: it does not respect the "Host" field. So if a user adds ip adresses for limiting access to the database the script recognises these users as "duplicate" but this is wrong. So i had to write my own script for the problem to fix it.

@hschramm Thanks for the info. So far we only cleaned up servers with a single database host setup. However, we also have affected servers with a multi-host database setup, where we grant access rights for different database hosts per user.

 

[Sebahat.hadzhi]

@Hangover2 , after fixing the issue with the escaped characters, the privileges should be flushed. Please run the command manually and let us know if the issue with the upgrade continues afterwards.

 

[Hangover2]

@Sebahat.hadzhi But this is my question: how do I re-run the upgrade? Please provide the command. The error log says:

Run upgrade with option --repair to rerun failed steps.

I cannot find any command in the Plesk documentation. Please help me sort this out.

 

[Sebahat.hadzhi]

@Hangover2 , if I correctly understand and you are referring to the entries initially logged while running the upgrade, now that the database names are fixed and the privileges are manually flushed there shouldn't be any other actions required. If you are still seeing the error actively being reported, please let me know where exactly and after what actions that happens.