Бекап mysql с percona xtrabackup

18.12.2011
 |  Комментариев нет

Добавляем ключ:

apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A

Узнаем версию linux

lsb_release -c

Добавляем в sources.list реппозитории (если релиз не wheezy то поменять строки на нужный)

nano /etc/apt/sources.list
deb http://repo.percona.com/apt wheezy main
deb-src http://repo.percona.com/apt wheezy main

Обновляем и устанавливаем

apt-get update && apt-get -y install percona-toolkit percona-xtrabackup netcat-openbsd

Создание бекапов

Xtrabackup создает копии файлов данных таблиц innoDB (xtraDB), а также текущего бинлог файла. Для начала нужно создать директорию для бекапов:

mkdir /home/backup/db

Для запуска процесса создания бекапа:

xtrabackup --defaults-file=/etc/mysql/my.cnf --datadir=/var/lib/mysql \
 --target-dir=/home/backup/db --backup

Некоторые пояснения:

--defaults-file — путь к конфигурационному файлу MySQL
    --datadir — путь к папке данных MySQL
    --target-dir — директория для бекапов

Спустя определенное время (зависит от размера данных), получим снимок в папке для бекапов, из которого можно восстановится:

xtrabackup  Ver 0.9 Rev 83 for 5.0.84 pc-linux-gnu (x86_64)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
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 = 134217728
xtrabackup: use O_DIRECT
>> log scanned up to (0 1283875749)
Copying ./ibdata1 
     to /home/backup/db/ibdata1
>> log scanned up to (0 1283877656)
>> log scanned up to (0 1283878467)
>> log scanned up to (0 1283880148)
>> log scanned up to (0 1283881355)
>> log scanned up to (0 1283883263)
>> log scanned up to (0 1283885187)
>> log scanned up to (0 1283887688)
        ...done
xtrabackup: The latest check point (for incremental): '0:1283888607'
>> log scanned up to (0 1283890956)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (0 1283872324) to (0 1283890956) was copied.
*

Восстановление из бекапов*

Для восстановления, необходимо выплнить команду с опцией «—prepare»:

xtrabackup --prepare --target-dir=/home/backup/db/ --datadir=/var/lib/mysql

xtrabackup  Ver 0.9 Rev 83 for 5.0.84 pc-linux-gnu (x86_64)
xtrabackup: cd to /home/backup/db
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(0 1284705008)
xtrabackup: Temporary instance for recovery is set 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 = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Log scan progressed past the checkpoint lsn 0 1284705008
090914 20:18:59  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 0 1284717711 (0 %)
090914 20:18:59  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
090914 20:19:00  InnoDB: Started; log sequence number 0 1284717711

[notice (again)]
  If you use binary log and don't use any hack of group commit,
  the binary log position seems to be:

xtrabackup: starting shutdown with innodb_fast_shutdown = 1
090914 20:19:00  InnoDB: Starting shutdown...
090914 20:19:01  InnoDB: Shutdown completed; log sequence number 0 1284717711

Команду восстановления данных нужно выполнить дважды, после чего будут созданы лог файлы для MySQL. После этого нужно скопировать лог файл и файл данных в папку MySQL (по умолчанию — /var/lib/mysql).

И задать права:

chown -R mysql.mysql /var/lib/mysql

Инкрементальные бекапы

Понятно, что делать полный бекап на больших объемах будет крайне ресурсоемко, поэтому XtraBackup обладает возможностью инкрементальных бекапов и восстановления. Для этого, Вам сначала необходимо сделать полный бекап, а затем в отдельную папку — т.н. дельта бекап:

xtrabackup --defaults-file=/etc/mysql/my.cnf --target-dir=/home/backup/dbdelta \
 --incremental-basedir=/home/backup/db --backup

Для восстановления нужно выполнить следующую команду:

xtrabackup --target-dir=/home/backup/dbdelta \
 --incremental-basedir=/home/backup/db --prepare

Если ругается на размер лога то:

Правильное изменение размера лога innodb (innodb_log_file_size)

Во время работы innodb записывает все измененные данные не сразу в файлы баз данных, а первоначально сбрасывает все в бинарный лог (опция innodb_log_file). Это позволяет повысить скорость работы, т.к. операция записи в файл таблицы более трудоемкая, чем в файл лога. К тому же ведение лога позволяет записывать в файл таблицы последовательными кусками данных, быстрее обслуживать клиентов mysql (данные принял, записал в лог, отчитался клиенту что все ОК)

При аварийном завершении сервера данный лог файл позволяет откатить поврежденные (незавершенные) транзакции. Чем больше лог файл — тем больше операций в нем хранится, и тем больше время для просмотра/анализа корректности последнего запершения работы необходимо innodb.

По-умолчанию бинарный лог-файл innodb имеео объем 5 Мб:

mysql -e "show variables like 'innodb_log_file_size'" 
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| innodb_log_file_size | 5242880 | 
+----------------------+---------+

Для изменения его объема необходимо выполнить следующие операции (от пользователя root):

1. Корректно останавливаем работу mysql сервера:

# для Debian (Ubuntu)
/etc/init.d/mysql stop

2. Изменяем/добавляем параметр в конфигурационном файле ( /etc/mysql/my.cnf — Debian (Ubuntu), /etc/my.cnf — CentOS):

[mysqld]
innodb_log_file_size = 64M

3. Важно! Переименовать существующие лог-файлы. Иначе при загрузке innodb будет рапортовать, что логфайл поврежден :

mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0_old
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1_old

4. Запустить mysql сервер.

# для Debian (Ubuntu)
/etc/init.d/mysql start

5. Проверить отсутствие ошибок в файле лога mysql демона:

# tail -n 100 /var/log/mysqld.log

…

130730 13:17:35  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 64 MB
InnoDB: Database physically writes the file full: wait...
130730 13:17:35  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 64 MB
InnoDB: Database physically writes the file full: wait...
130730 13:17:37 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!

Как видно по логу, innodb создал новые бинарные логи ib_logfile0 и ib_logfile1 нового объема.

Linux
Метки: ,