Bulk remove databases from subscriptions that no longer exists in the database server
As seen on https://stackoverflow.com/questions/77681371/are-there-any-methods-to-initiate-a-database-synchronization-process-in-plesk it should be possible to auto-remove databases from the Plesk configuration (psa table) that no longer exist in the database server.
Example: A user has removed databases with "drop database" in the database server shell directly. Such databases are still references in the psa database and are displayed as available databases to GUI users. Such orphants should be removed either automatically (e.g. by nighty maintenance) or by a user command.
-
HawaiianHope.org commented
Yes, I would vote for this 15 times If i could.
This cost me about 12 hours trying to do a server migration. Plesk kept giving us a "DNS" error during a migration of one server to another, and it turned out it had nothing to do with a DNS problem, but was in fact that a domain referenced a database and that database no longer existed. Every time I would retry the migration of our domain - the migration LOG screen would show that it failed to migrate the subscription and gave DNS as an error. "Failed to convert DNS records for subscription " See screen shot - "DNS-LIES.png" I am not exaggerating when I say that I spent HOURS trying to make DNS adjustments on the original server, resetting it, deleting it and recreating it..restart the migration again, (50+% of the time is waiting for it to redeploy the RPC program) I even deleted 4 domains from the subscription that i thought had DNS errors and were causing the issues. 6+ Hours on this.
Finally I saw the option for "Show debug messages" and turned that on. After reading through all of the debug messages, the REAL reason it seemed to be throwing an error was "MSSQL Database Not Found" - Apparently our domain said that it had an MSSQL Database, but Plesk could not find it. I went to the original server, looked at the domain and sure enough it said there was a database. So I deleted the database reference.
The migration worked perfectly the very next time - It was NOT a DNS error.
This also emphasizes (b) above, that even thought i told it to skip database migration, it still tried it and got hung up on it.