Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are running with the MyIsam Engine and Percona-xtrabackup is throwing the following error as the inndb engine is skipped [ my.cnf skip-innodb]. How could I resolve this issue with out enabling the inndb engine?

percona-xtrabackup-2.0.0/bin:# ./innobackupex-1.5.1 --user="root" --password=*** --defaults-file="/etc/my.cnf" --socket=<path>/mysql.sock1  --ibbackup=<path>/percona-xtrabackup-2.0.0/bin/xtrabackup <path>/testbackup/

Percona Log :

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex-1.5.1
           prints "completed OK!".

innobackupex-1.5.1: Using mysql  Ver 14.14 Distrib 5.1.57, for pc-linux-gnu (i686) using readline 5.1
innobackupex-1.5.1: Using mysql server version Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.

innobackupex-1.5.1: Created backup directory <path>/testbackup/2012-06-08_16-55-23
120608 16:55:23  innobackupex-1.5.1: Starting mysql with options:  --defaults-file='/etc/my.cnf' --password=xxxxxxxx --user='root' --socket='/data/mysql1/mysql.sock1' --unbuffered --
120608 16:55:23  innobackupex-1.5.1: Connected to database with mysql child process (pid=25611)
120608 16:55:25  innobackupex-1.5.1: Connection to database server closed

120608 16:55:25  innobackupex-1.5.1: Starting ibbackup with command: <path>/percona-xtrabackup-2.0.0/bin/xtrabackup  --defaults-file="/etc/my.cnf" --backup --suspend-at-end --target-dir=<path>/testbackup/2012-06-08_16-55-23
innobackupex-1.5.1: Waiting for ibbackup (pid=25618) to suspend
innobackupex-1.5.1: Suspend file '<path>/testbackup/2012-06-08_16-55-23/xtrabackup_suspended'

<path>/percona-xtrabackup-2.0.0/bin/xtrabackup version 2.0.0 for Percona Server 5.1.59 pc-linux-gnu (i686) (revision id: undefined)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /data/mysql1
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 5242880
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
120608 16:55:26  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
xtrabackup: Something wrong with source files...
innobackupex-1.5.1: Error: ibbackup child process has died at ./innobackupex-1.5.1 line 371.
share|improve this question

4 Answers 4

I ran into this same problem when running innobackupex on a newly-created database with skip-innodb enabled. It seems like innobackupex needs to have a functional InnoDB storage engine there, even if it isn't used, and it errors when trying to generate one for you.

After I started the database once with #skip-innodb commented out in my /etc/my.cnf (and I had to delete the ibdata1 file the backup script made, as it was corrupt), then shut it down and uncommented the skip-innodb line, the backup script worked as expected.

I would guess people don't run into this much anymore, as it is uncommon for someone to still be running MyISAM-only databases.

share|improve this answer

It does not make any sense to use innobackupex on a MyISAM-only installation. Here's why.

innobackupex is designed to create consistent backups from a running database; so-called "hot backups". This only works without interruption for InnoDB tablespaces as MyISAM requires you to perform a READ LOCK on the tables to be backed up consistently and this causes a disruption in the service as long as the lock isn't released.

The more MyISAM data you have, the more time innobackupex will have to lock your tables. Having MyISAM data only, it does not make sense to use the tool - it would be the same as

  1. mysql> FLUSH TABLES WITH READ LOCK
  2. shell> cp -a /path/to/datadir/of/mysql /path/to-backup/dir
  3. when finished mysql> UNLOCK TABLES.

Whereas for InnoDB innobackupex just starts copying and then applies the transactionlog when preparing the update some time later (--apply-log), offline/independently.

share|improve this answer

If you're resisting the change over to InnoDB because you think the process is difficult, here's what I use:

mysql -u root --password=<password> --database=db_name -B -N -e "SHOW TABLES" | awk '!/not_this_db/ && !/or_this_one/ && /^[a-z]/ {print "ALTER TABLE", $1, "ENGINE=INNODB;"}' | mysql -u root --password=<password> --database=db_name

You can exclude and include databases with the regex such as only dbs starting with a lowercase letter in my example above.

Of course the alters will lock the tables, but then you can use xtrabackup from there on out.

share|improve this answer

is there a reason to use it? it will just lock the myiasm tables anyway for dump. it is really a tool for innodb tables that can do myiasm but it locks them. Might as well just do a server wide lock and copy all the files.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.