Announcement

Announcement Module
Collapse
No announcement yet.

Fails to fully backup or prepare

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fails to fully backup or prepare

    Hi,

    I have a strange thing happening with some of our servers that I use xtrabackup on. First I run the command 'innobackupex --user=root --password=xxxxx /backups' and it does some backing up and file copying but the resulting files are only half the size of the database. Even if I 'rm -rf /backups/*' and run another backup its the same result.

    The second thing is I can never get the apply-log to work it gives an error that says 'This target seems to be not prepared yet' and 'InnoDB: Operating system error number 2 in a file operation.
    InnoDB: The error means the system cannot find the path specified.' and 'Fatal error: cannot find ./xtrabackup_logfile.'

    Anyone know whats going on here?

    John

  • #2
    Do you have multiple MySQL instances on the same server? The first issue sounds like it may be backing up another data folder that you are not intending.

    What is the command you are using for the apply-log step?

    Comment


    • #3
      No, none of these servers are running multiple mysql instances and the mysql versions are mysql-server-5.0.45-7.el5 on CentOS 5.2.

      We're using innobackupex to backup about 4 systems. Three of the systems are running xtrabackup-1.6.5-328.rhel5 and I tested xtrabackup-2.0.0-417.rhel5 on one.

      On 2 of the servers the the size of the backup folders matches the size of the database folders in mysql and the apply-log seems to have no problem.

      On 1 the sizes match but apply-log fails and on the last a 16GB database comes out in backup as 89M, a 6.5GB database on the same server is 4.8G

      All of the servers are configured the same and mysql lives in /var/lib/mysql

      Its almost as if some of these servers are stuck on doing only incremental backups, is there a setting somewhere to reset this?

      The error message on the failed servers during the apply-log phase says " xtrabackup: Fatal error: cannot find ./xtrabackup_logfile." On the servers that suceeded there are 5 files:

      xtrabackup_binary
      xtrabackup_binlog_info
      xtrabackup_binlog_pos_innodb
      xtrabackup_checkpoints
      xtrabackup_logfile

      on the failed ones there are only 3:

      xtrabackup_binary
      xtrabackup_binlog_info
      xtrabackup_checkpoints

      The apply-log command I'm using is 'innobackupex --apply-log /backups/2012-06-16_02-42-44/'

      Comment


      • #4
        Odd. What you are doing sounds pretty straight forward.

        You have to specifically specify incremental backups, so that should not be an issue.

        Are your configuration files similar on all servers in question? Particularly these options:

        innodb_data_home_dir=/var/data
        innodb_data_file_path=ibdata1:10M:autoextend
        innodb_log_group_home_dir = ./
        innodb_log_file_size = 512M
        innodb_log_files_in_group = 2

        Comment


        • #5
          The innodb sections match exacly across systems but then I noticed something. About the only difference is that Server2 which failed has log and log-bin enabled and server1 which worked has them disabled. So I disabled both on the server and now its working normally. Infact the offending entry that kills everything seems to be just the standard query log entry 'log'. Is this a bug and is log-bin supposed to be on or does it not matter?

          Heres how it looks now for clarification(this works):

          #log
          log-bin

          but(this fails):

          log
          log-bin

          Comment


          • #6
            Interesting. The "log" setting enables the general log, so I'm surprised that has any affect. Be careful when enabling that as it will use up a lot of disk space quickly if you have a lot of traffic hitting the database.

            You'll want to leave log-bin enabled for recovery purposes and you'll need it for replication if you have that / plan to have that.

            If you can reproduce the "log" setting issue I'd submit a bug on it as that definitely sounds like a bug to me.

            Comment

            Working...
            X