# Backup issue in percona server 5.0 on centos 6.6 Final **URL:** \ **Category:** Other MySQL® Questions\ **Created:** [November 9, 2015, 12:12am UTC](https://forums.percona.com/t/backup-issue-in-percona-server-5-0-on-centos-6-6-final/4502 "2015-11-09T00:12:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Subodh](https://avatars.discourse-cdn.com/v4/letter/s/46a35a/32.png) [@Subodh](https://forums.percona.com/u/Subodh)\ **Post date:** [November 9, 2015, 12:12am UTC](https://forums.percona.com/t/backup-issue-in-percona-server-5-0-on-centos-6-6-final/4502/1 "2015-11-09T00:12:50Z")
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. ---
**Author:** ![scott.nemes](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/scott.nemes/32/5_2.png) [@scott.nemes](https://forums.percona.com/u/scott.nemes)\ **Post date:** [November 9, 2015, 9:49am UTC](https://forums.percona.com/t/backup-issue-in-percona-server-5-0-on-centos-6-6-final/4502/2 "2015-11-09T09:49:13Z")
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 ---
**Author:** ![Subodh](https://avatars.discourse-cdn.com/v4/letter/s/46a35a/32.png) [@Subodh](https://forums.percona.com/u/Subodh)\ **Post date:** [November 9, 2015, 11:25am UTC](https://forums.percona.com/t/backup-issue-in-percona-server-5-0-on-centos-6-6-final/4502/3 "2015-11-09T11:25:20Z")
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 ---
**Author:** ![Subodh](https://avatars.discourse-cdn.com/v4/letter/s/46a35a/32.png) [@Subodh](https://forums.percona.com/u/Subodh)\ **Post date:** [November 16, 2015, 4:05am UTC](https://forums.percona.com/t/backup-issue-in-percona-server-5-0-on-centos-6-6-final/4502/4 "2015-11-16T04:05:38Z")
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.