Backup issue in percona server 5.0 on centos 6.6 Final

MySQL & MariaDB Other MySQL® Questions
1

I am trying to use mysqldump to take regular backup of mysql database. We have migrated to centos 6.6 but still use mysql5.0 for our application.
I am trying to take a dump by issuing command

MYSQLDUMP --user=root --password=‘****’ --host=localhost --verbose --master-data=2 --flush-logs --all-databases > $DUMPFILE

It runs for 8 hours but the statements on the dump file are

– MySQL dump 10.11

– Host: localhost Database:

– Server version 5.0.92-50-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;
/!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS /;
/!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION /;
/!40101 SET NAMES utf8 /;
/!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE /;
/!40103 SET TIME_ZONE=‘+00:00’ /;
/!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 /;
/!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 /;
/!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=‘NO_AUTO_VALUE_ON_ZERO’ /;
/!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 /;
/!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE /;
/!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS /;
/!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS /;
/!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT /;
/!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS /;
/!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION /;
/!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

– Dump completed on 2015-11-07 9:00:01

I have a total of 17 database but only get information_schema database dumped.

I can see that whenever I issue the dump command, a sleep is introduced for 8 hrs and when it finishes the dump command also exits.

Want to understand if the dump command has any issue or the options given while taking the dump sends it into sleep.

The above command works well and dump generated on Red Hat Enterprise Linux Server release 5.3

Any help for my understanding would be appreciated.

2

Hi Subodh;

Your mysqldump command looks fairly straight forward, so likely something else going on. When you migrated to Centos 6.6, do you mean you moved to an entirely new (updated) host, or upgraded the existing host in-place? I’d start by trying to connect to MySQL manually using the same username/password as the mysqldump command is using and do a “show databases” to make sure the user can still see all of the necessary databases. If that all looks good, then I’d try dumping just a single database (explicitly specify it instead of --all-databases) and see if that works. That will at least narrow it down to see if mysqldump is just not working at all, or if it’s an issue with --all-databases. Also run a mysqldump --version to see what version of mysqldump that you are using. The upgrade could have resulted in a new mysqldump being used that is not working correctly with the older MySQL version.

-Scott

3

Hi Scott,
Thanks for taking a look at it. The server is not migrated but it’s a new server with new libraries but I am using the same version of percona server that I have been using i.e 5.0.92.

The issue is due to the option --flush-logs.

If I don’t use that option then I get the whole dump. I am using the same credentials I have been using.

Thanks,
Subodh

4

ISSUE SOLVED There was issue with the log-error file to which I was suppose to log mysql errors. I had this line in my.cnf

log-error=/var/lib/mysqld.log Due to permission issue mysql was not able to create this log file nor an error was thrown suggesting the same.Ideally mysql should have thrown an error stating can’t create log-error file or not present. This would have helped to fix the problem
I selectively removed and toggled the settings which helped me reach to the problem.