Problema de copy de security de Percona-xtrabackup con MyIsam Engine

Estamos ejecutando con el motor MyIsam y Percona-xtrabackup está lanzando el siguiente error como el motor inndb se omite [my.cnf skip-innodb]. ¿Cómo podría resolver este problema sin habilitar el motor inndb?

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' --unbuffenetworking -- 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. 

¿hay alguna razón para usarlo? sólo bloqueará las tablas de myiasm de todos modos para volcado. es realmente una herramienta para las tablas innodb que pueden hacer myiasm pero las bloquea. Podría también hacer un server de locking de ancho y copyr todos los files.

No tiene sentido utilizar innobackupex en una installation de MyISAM-only. Este es el por qué.

innobackupex está diseñado para crear copys de security consistentes desde una database en ejecución; las llamadas "copys de security en caliente". Esto sólo funciona sin interrupción en los espacios de tablas de InnoDB, ya que MyISAM requiere que realice un READ LOCK en las tablas para que se haga una copy de security de forma consistente y esto provoque una interrupción en el service siempre que no se libere el locking.

Cuantos más datos tenga MyISAM, más time innobackupex tendrá que bloquear sus tablas. Teniendo sólo datos MyISAM, no tiene sentido utilizar la herramienta – sería lo mismo que

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

Mientras que InnoDB innobackupex comienza a copyr y luego aplica el --apply-log transactions al preparar la actualización algún time después ( --apply-log ), sin connection / independientemente.

Si usted está resistiendo el cambio a InnoDB porque cree que el process es difícil, esto es lo que uso:

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

Puede excluir e include bases de datos con el regex, como sólo dbs que comienzan con una letra minúscula en mi ejemplo anterior.

Por supuesto los cambios bloquearán las tablas, pero entonces usted puede utilizar el xtrabackup de allí encendido hacia fuera.

Me encontré con este mismo problema al ejecutar innobackupex en una database recién creada con skip-innodb habilitado. Parece que innobackupex necesita tener un motor de almacenamiento InnoDB funcional allí, incluso si no se utiliza, y se equivoca al intentar generar uno para usted.

Después de haber iniciado la database una vez con #skip-innodb comentado en mi /etc/my.cnf (y tuve que borrar el file ibdata1 el script de copy de security hecho, ya que estaba dañado), luego apagarlo y skip-innodb el skip-innodb , el script de copy de security funcionó como se esperaba.

Supongo que la gente no se ejecuta en esto mucho más, ya que es raro que alguien todavía está ejecutando MyISAM sólo las bases de datos.