Назад | Перейти на главную страницу

Проблема горячего резервного копирования Percona-xtrabackup с MyIsam Engine

Мы работаем с движком MyIsam, и Percona-xtrabackup выдает следующую ошибку, поскольку движок inndb пропускается [my.cnf skip-innodb]. Как я могу решить эту проблему, не включив движок 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:

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.

Нет смысла использовать innobackupex при установке только MyISAM. Вот почему.

innobackupex предназначен для создания согласованных резервных копий из работающей базы данных; так называемые «горячие резервные копии». Это работает без прерывания только для табличных пространств InnoDB, поскольку MyISAM требует, чтобы вы выполнили READ LOCK для таблиц, которые необходимо постоянно резервировать, и это вызывает сбой в работе службы, пока блокировка не снимается.

Чем больше у вас данных MyISAM, тем больше времени innobackupex придется заблокировать ваши таблицы. Имея только данные MyISAM, нет смысла использовать инструмент - он будет таким же, как

mysql> FLUSH TABLES WITH READ LOCK
shell> cp -a /path/to/datadir/of/mysql /path/to-backup/dir
когда закончите mysql> UNLOCK TABLES.

В то время как для InnoDB innobackupex просто начинает копирование, а затем применяет журнал транзакций при подготовке обновления некоторое время спустя (--apply-log), офлайн / независимо.

есть ли причина его использовать? в любом случае он просто заблокирует таблицы миазмов для дампа. это действительно инструмент для таблиц innodb, который может делать миазмы, но блокирует их. Можно также просто заблокировать сервер и скопировать все файлы.

Если вы сопротивляетесь переходу на InnoDB, потому что считаете этот процесс сложным, вот что я использую:

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

Вы можете исключить и включить базы данных с регулярным выражением, например, только базы данных, начинающиеся со строчной буквы в моем примере выше.

Конечно, изменения заблокируют таблицы, но затем вы можете использовать xtrabackup оттуда.

Я столкнулся с этой же проблемой при запуске innobackupex во вновь созданной базе данных с skip-innodb включен. Похоже, что innobackupex должен иметь работающий механизм хранения InnoDB, даже если он не используется, и он выдает ошибку при попытке создать его для вас.

После того, как я запустил базу данных один раз с #skip-innodb закомментировал в моем /etc/my.cnf (и мне пришлось удалить файл ibdata1, созданный сценарием резервного копирования, поскольку он был поврежден), затем выключил его и раскомментировал skip-innodb строка, сценарий резервного копирования работал должным образом.

Я предполагаю, что люди больше не сталкиваются с этим, поскольку редко кто-то все еще использует базы данных только для MyISAM.