Not the answer you need?
Register and ask your own question!

Backup issue in percona server 5.0 on centos 6.6 Final

SubodhSubodh EntrantCurrent User Role Beginner
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 @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @[email protected]@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;
/*!40103 SET [email protected]_TIME_ZONE */;

/*!40101 SET [email protected]_SQL_MODE */;
/*!40014 SET [email protected]_FOREIGN_KEY_CHECKS */;
/*!40014 SET [email protected]_UNIQUE_CHECKS */;
/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;
/*!40101 SET [email protected]_COLLATION_CONNECTION */;
/*!40111 SET [email protected]_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.

Comments

  • scott.nemesscott.nemes MySQL Sage Current User Role Patron
    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
  • SubodhSubodh Entrant Current User Role Beginner
    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
  • SubodhSubodh Entrant Current User Role Beginner
    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.
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.