Resolved MariaDB Backup issue

[Quinten]

Server operating system version

Ubuntu 22.04.1 LTS

Plesk version and microupdate number

Plesk Obsidian Version 18.0.49 Update #2

Hello,

Since a week ago there seems to be an issue with my backups on one of my servers

The backup is incomplete with a bunch of these same message.
I looked up the error and found some topics on ehre but none of the solutions seem to work for me.
I attached my 50-server.cnf and the my.cnf are there any other relevant files to look at?

Help would be much appriciated

 

[Peter Debik]

It seems that skip-name-resolve = 1 has been added to your my.cnf lately? In that case, name resolution that is required to resolve "localhost" does not work. If there is no specific reason for that line, please remove it or comment it, then restart the database server, then try the backup again. It should then work as before without errors.

 

[Quinten]

It seems that skip-name-resolve = 1 has been added to your my.cnf lately? In that case, name resolution that is required to resolve "localhost" does not work. If there is no specific reason for that line, please remove it or comment it, then restart the database server, then try the backup again. It should then work as before without errors.

Hi Peter thank you for your reply.
I have removed the skip-name-resolve = 1 from my.cnf

However i now seem to have a different error:

 

[Quinten]

But it is only 1 error this time and that user does exist so its strange

 

[Quinten]

Anyone have any idea? because the user does exist but im not fully sure what the error means

 

[Peter Debik]

Have you seen this KB article?

https://support.plesk.com/hc/en-us/articles/213409469

 

[Quinten]

Have you seen this KB article?

https://support.plesk.com/hc/en-us/articles/213409469

Hello Peter, i have seen it but the user does exist
(i did just notice that i cannot delete the user, is this normal?)

 

[Peter Debik]

Maybe some misunderstanding here. You'll need to check users in the database itself, not in the frontend. A user record that looks similar might exist, but is it really exactly the same with the global % wildcard permissions as the error says? There could be an entry for localhost or 127.0.0.1 or another specific IP, too. You need the exactly right entry. You could add such an entry to your users table in the database.

Another option could be to remove the view from the database that the definer is associated with and re-add it later.
1. First get the exact view definition (for later restore). Doing something wrong in this however could result in loss of the view, so please handle with care.
> SELECT VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'dbname' AND TABLE_NAME = 'viewname';
This will output a "select" statement that is the view definition. Store all that information.
2. Drop the view
> DROP VIEW dbname.viewname;
3. Recreate the view using the output you got from above ("select ..."):
> CREATE VIEW dbname.viewname AS select ...

 

[Quinten]

How can i check for the entry on localhost or 127.0.0.1 or not?

Also for the view i really dont want to do anything wrong here.
What is the viewname i put there in the query?

 

[Quinten]

I seem to have solved the problem by just unchecking the global privileges on the user...