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.

 

[hschramm]

@Hangover2 I would like to briefly say something about the re-execution of the failed update: In my tests on a demo machine, I was unable to convince PLESK to run the update again. Unfortunately, the plesk repair function is completely useless in this regard.

During the test runs where the update went through, I was unable to detect any changes in the database server compared to the "manual variant" via script. I therefore suspect that the script intended to fix the permissions only does exactly that and nothing more.

Since it fails, we are left on our own and have to resolve it ourselves. However, I find it very regrettable that one is left out in the cold like this. Because unfortunately, all we received was a semi-functional AWK script.
The bare minimum i had expected was that they will provide an update for the repair function, so we can fix the problem easily instead of sitting hours in a running database server with active customers around the globe and fixing permissions.

This is one point more why plesk updates are getting more and more a gambling game and the scripts collection we need to fix this and that is continously growing.

 

[Sebahat.hadzhi]

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.

Thank you for bringing our attention to the issue. I forwarded your feedback to our team and they reworked the script. I am attaching a new version “1.0.4” where all: db, user, and host columns are included on the comparison, and the delete statements provide all columns to avoid wrong deletions but to target the specific ones only.

 

[learning_curve]

As per several of the previous posts in this thread, it appears that the Plesk upgrade process does complete, but, with the warning that's already been posted: "Some steps of upgrade failed. Run upgrade with option --repair to rerun failed steps "

After running "plesk repair all -n" and/or plesk repair db -v -n Then again as per other posts in this thread, no faults are found anywhere & operation is normal.

We only have one common example of the Integrity constraint violation issue, in all setups, so we happily followed posts #11 & #13 from this thread.

The post #13 script, does correctly find the one example of duplicated db_name and db\_name, but then running the 3. delete instruction from post #11 (and yes we did run the 4. Reload the grants table instruction afterwards) doesn't appear to work, because running the post #13 script again (to verify) provides data that is unchanged, from before running the post #13 script / then deleting the one not properly escaped entry in the mysql.db table actions.

It was reasonably clear that you would make a further post @Sebahat.hadzhi so we waited and did run the post #28 script, but this time it's an error output, (despite the mysql reference being common across all posts / scripts)

~# ./fix-duplicate-dbs_1.0.4.sh
/tmp/tmp.9F40zlBAsx
Error: Failed to connect to MySQL or execute query
mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
ERROR 2002 (HY000): Can't connect to server on '10.66.93.79' (115)
~#

 

[Sebahat.hadzhi]

Thank you for the feedback, @learning_curve . The correct equivalent of the mysql command present in the script for newer MariaDB versions is mariadb. I updated it. Could you please give it another go and let me know if there are further issues, so I can consult with our team.

 

[learning_curve]

~ Could you please give it another go and let me know if there are further issues, so I can consult with our team.

The mysql reference warning, is common across all posts / scripts (see post #29) and... the depreciated program name replacement, is an ongoing Plesk task from MariaDB 11.*.* onward (as per other existing posts) so this warning is a distraction with no operational penalty - currently.

The 'culprit' appears to be the lack of a consistent connection to '10.66.93.79' which maybe an error within the script or, our own specific config - TBC!

~# ./fix-duplicate-dbs_1.0.4-new.sh
/tmp/tmp.xiSdCl3k09
Error: Failed to connect to MySQL or execute query
ERROR 2002 (HY000): Can't connect to server on '10.66.93.79' (115)
~#

 

[learning_curve]

The 4-min edit was applied, so the edit to the above was:

FWIW 10.66.93.79 is called within the script:

16 # Modify the user (-u), password (-p) and IP (-h) with the specific values for the remote database server.
17 mariadb -uroot -pPa$$word -h10.66.93.79 -e "$QUERY" > "$TEMP_FILE" 2>&1
18 #mariadb -uroot -pPa$$word -h10.11.22.33 -e "$QUERY" > "$TEMP_FILE" 2>&1
19 #mariadb -e "$QUERY" > "$TEMP_FILE" 2>&1

So it "might" be a restriction within our own config, or, the script needs a further revision

 

[Sebahat.hadzhi]

I should have explained that in more details, sorry about that. If the issue you are encountering with the database names is on the local database server, please comment out lines 17 and 18 and uncomment line 19 instead. If you do have a remote MySQL server configured where the issue is present, you need to replace the credentials with your actual server's details. I hope that makes more sense.

The noted in the script are a bit confusing, because there's an additional line (#17) that shouldn't have been there. I have updated it now.

 

[learning_curve]

I should have explained that in more details, sorry about that. If the issue you are encountering with the database names is on the local database server, please comment out lines 17 and 18 and uncomment line 19 instead. If you do have a remote MySQL server configured where the issue is present, you need to replace the credentials with your actual server's details. I hope that makes more sense.

The noted in the script are a bit confusing, because there's an additional line (#17) that shouldn't have been there. I have updated it now.

Downloaded the latest script version, which also contains very clear edit instructions to suit the db location(s), ran that script after our own edit, followed by flush privileges and this time it's operated exactly as originally expected. No operational errors any way and there's nothing to do now re: "fixing" the Plesk upgrade. Perfect! Thanks @Sebahat.hadzhi

 

[Hangover2]

Maybe a small annotation: if you’re affected by both bugs (duplicated entries and unescaped entries), you need to run the script twice. The first run will generate the required SQL DELETE statements; the second run will generate the UPDATE statements. In short, run it repeatedly and execute the commands it outputs in your MySQL database until no issues are reported.