Posts Tagged ‘MySQL’

Scheduled backups failing in Plesk 9.5

Saturday, October 27th, 2012

If you are using MySQL 5.5 with Parallels Plesk 9.5 then you might have noticed that scheduled backups using the built in backup utility have stopped working.

Backups manually initiated through the Parallels Plesk control panel interface run normally, but they don’t run automatically on the configured schedule. This is thanks to some compatibility issues between the Parallels “backupmng” tool and MySQL 5.5.

A quick fix for this is to adjust the “backup_day” column of the “BackupsScheduled” table in the “psa” database to change the type from “int(10) unsigned” to “int(11)” with the following SQL statement:

ALTER TABLE BackupsScheduled MODIFY COLUMN backup_day INTEGER;

Once this query has been run, you should be able to set up the scheduled backups as normal through the Parallels Plesk interface and they will run without problems or requiring manual intervention.

MySQL system tables and blank entries in the Host column

Thursday, April 15th, 2010

I discovered some interesting behaviour under MySQL 4.1 recently (I know it’s old, but it’s not within my power to upgrade it) whereby empty entries in the Host column of the users table under the mysql system database were causing all remote (i.e. TCP and not socket) connections to be refused with a message saying “Host ‘’ is not allowed to connect to this MySQL server” without even asking for login credentials.
Telneting to the server’s IP address on port 3306 received the same message straight away and then disconnected the session.

The solution to this was simple, but somewhat obscure – update the Host column in the user table of the mysql system database so that any blank records are changed to “localhost” (secure) or ‘%’ (safer) and then run “flush privileges”.
I have no idea how the blank records got in there in the first place, but I couldn’t find any reference to this being the cause of such behaviour anywhere on the MySQL site. Everywhere seems to suggest that this message indicated that you need to grant privileges to the user for them to be able to connect remotely – which would be true, if I was getting as far as supplying login credentials!