Создание бекапа mysql-базы без остановки сервера
Для очень больших баз данных MySQL использование традиционных средств создания бекапов, таких как mysqldump, сопряжено с рядом трудностей:
1. По умолчанию таблицы лочатся на запись --- на время создания бекапа нельзя писать в базу. Для mission-critical приложений это неприемлимо. Однако, в случае таблиц InnoDB это ограничение можно обойти с помощью ключа mysqldump --single-transaction.
2. Создание дампа и восстановление из него занимает очень много времени. Так, для одной из баз, с которой мне приходилось сталкиваться, дамп размером 50ГБ создавался 5 часов (и это на совсем не слабом сервере - 256ГБ RAM, четыре 6-ти-ядерных CPU Xeon E7540 2.0GHz c HT). Вливание этого дампа назад в базу заняло бы примерно столько же времени.
Percona xtrabackup позволяет буквально двумя командами получить рабочую копию базы без какого-либо прерывания работы MySQL-сервера, причём намного быстрее, чем mysqldump. Пример:
# rpm -ivh xtrabackup-1.6-245.rhel5.x86_64.rpm
[admin@master] $ innobackupex /backups
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2011. All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
110623 11:59:51 innobackupex: Starting mysql with options: --unbuffered --
110623 11:59:51 innobackupex: Connected to database with mysql child process (pid=3685)
110623 11:59:57 innobackupex: Connection to database server closed
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
innobackupex: Using mysql Ver 14.14 Distrib 5.5.13, for Linux (x86_64) using readline 5.1
innobackupex: Using mysql server version Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
innobackupex: Created backup directory /backups/2011-06-23_11-59-57
110623 11:59:57 innobackupex: Starting mysql with options: --unbuffered --
110623 11:59:57 innobackupex: Connected to database with mysql child process (pid=3712)
110623 12:00:01 innobackupex: Connection to database server closed
110623 12:00:01 innobackupex: Starting ibbackup with command: xtrabackup_55 --backup --suspend-at-end --target-dir=/backups/2011-06-23_11-59-57
innobackupex: Waiting for ibbackup (pid=3724) to suspend
innobackupex: Suspend file '/backups/2011-06-23_11-59-57/xtrabackup_suspended'
xtrabackup_55 Ver 1.6 Rev 245 for 5.5.9 Linux (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 = 5242880
110623 12:00:01 InnoDB: Using Linux native AIO
>> log scanned up to (15576575786)
[01] Copying ./ibdata1
to /backups/2011-06-23_11-59-57/ibdata1
>> log scanned up to (15576821168)
>> log scanned up to (15576993781)
>> log scanned up to (15577223204)
>> log scanned up to (15577401335)
>> log scanned up to (15577646737)
>> log scanned up to (15577864382)
>> log scanned up to (15578032411)
>> log scanned up to (15578302721)
>> log scanned up to (15578496370)
>> log scanned up to (15578695368)
>> log scanned up to (15578966232)
>> log scanned up to (15579121683)
>> log scanned up to (15579340135)
>> log scanned up to (15579572684)
>> log scanned up to (15579801008)
>> log scanned up to (15579918009)
>> log scanned up to (15580129220)
>> log scanned up to (15580377234)
>> log scanned up to (15580543590)
>> log scanned up to (15580811908)
>> log scanned up to (15580992609)
>> log scanned up to (15581162267)
>> log scanned up to (15581314789)
>> log scanned up to (15581469774)
>> log scanned up to (15581662444)
>> log scanned up to (15581858152)
>> log scanned up to (15582046357)
>> log scanned up to (15583450833)
>> log scanned up to (15584545328)
>> log scanned up to (15584847700)
>> log scanned up to (15585508334)
>> log scanned up to (15587171262)
>> log scanned up to (15588573028)
[01] ...done
110623 12:03:15 innobackupex: Continuing after ibbackup has suspended
110623 12:03:15 innobackupex: Starting mysql with options: --unbuffered --
110623 12:03:15 innobackupex: Connected to database with mysql child process (pid=4879)
>> log scanned up to (15591908670)
110623 12:03:19 innobackupex: Starting to lock all tables...
>> log scanned up to (15597590433)
>> log scanned up to (15598452337)
110623 12:03:29 innobackupex: All tables locked and flushed to disk
110623 12:03:29 innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,
innobackupex: .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV and .opt files in
innobackupex: subdirectories of '/var/lib/mysql'
innobackupex: Backing up files '/var/lib/mysql/mysql/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (72 files)
innobackupex: Backing up files '/var/lib/mysql/performance_schema/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (18 files)
innobackupex: Backing up files '/var/lib/mysql/salesdb/*.{frm,MYD,MYI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (210 files)
>> log scanned up to (15598452487)
>> log scanned up to (15598452783)
110623 12:03:43 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt files
innobackupex: Resuming ibbackup
>> log scanned up to (15598452993)
xtrabackup: The latest check point (for incremental): '15594901984'
>> log scanned up to (15598452993)
xtrabackup: Stopping log copying thread.
xtrabackup: Transaction log of lsn (15574068024) to (15598452993) was copied.
110623 12:03:46 innobackupex: All tables unlocked
110623 12:03:46 innobackupex: Connection to database server closed
innobackupex: Backup created in directory '/backups/2011-06-23_11-59-57'
innobackupex: MySQL binlog position: filename 'mysql-bin.000009', position 537035213 mysql
110623 12:03:46 innobackupex: completed OK!Далее "приготавливаем" бекап путем обработки лога транзакций, который на этом этапе хранится в файле xtrabackup_logfile.
[admin@master] $ innobackupex --apply-log /backups/2011-06-23_11-59-57/
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Inc 2009-2011. All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
110623 12:31:28 innobackupex: Starting ibbackup with command: xtrabackup_55
--prepare --target-dir=/backups/2011-06-23_11-59-57
xtrabackup_55 Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
xtrabackup: cd to /backups/2011-06-23_11-59-57
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=27443200,start_lsn=(15574068024)
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 = 27443200
110623 12:31:28 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter
110623 12:31:28 InnoDB: The InnoDB memory heap is disabled
110623 12:31:28 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110623 12:31:28 InnoDB: Compressed tables use zlib 1.2.3
110623 12:31:28 InnoDB: Using Linux native AIO
110623 12:31:28 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
use innodb_read_io_threads and innodb_write_io_threads instead
110623 12:31:28 InnoDB: Initializing buffer pool, size = 100.0M
110623 12:31:28 InnoDB: Completed initialization of buffer pool
110623 12:31:28 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 15574068024
110623 12:31:28 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 15579310592 (21 %)
InnoDB: Doing recovery: scanned up to log sequence number 15584553472 (42 %)
InnoDB: Doing recovery: scanned up to log sequence number 15589796352 (64 %)
InnoDB: Doing recovery: scanned up to log sequence number 15595039232 (85 %)
110623 12:31:29 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 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
InnoDB: Doing recovery: scanned up to log sequence number 15598452993 (99 %)
110623 12:31:38 InnoDB: Starting an apply batch of log records to the
database...
InnoDB: Progress in percents: 0 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
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
110623 12:31:39 InnoDB: Waiting for the background threads to start
110623 12:31:40 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
log sequence number 15598452993
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 537035213, file name
./mysql-bin.000009
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
110623 12:31:40 InnoDB: Starting shutdown...
110623 12:31:44 InnoDB: Shutdown completed; log sequence number 15598454344
110623 12:31:44 innobackupex: Restarting xtrabackup with command:
xtrabackup_55 --prepare --target-dir=/backups/2011-06-23_11-59-57
for creating ib_logfile*
xtrabackup_55 Ver 1.6 Rev 245 for 5.5.9 Linux (x86_64)
xtrabackup: cd to /backups/2011-06-23_11-59-57
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
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 = 2
xtrabackup: innodb_log_file_size = 5242880
110623 12:31:44 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory
parameter)
110623 12:31:44 InnoDB: The InnoDB memory heap is disabled
110623 12:31:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110623 12:31:44 InnoDB: Compressed tables use zlib 1.2.3
110623 12:31:44 InnoDB: Using Linux native AIO
110623 12:31:44 InnoDB: Warning: innodb_file_io_threads is deprecated. Please
use innodb_read_io_threads and innodb_write_io_threads instead
110623 12:31:44 InnoDB: Initializing buffer pool, size = 100.0M
110623 12:31:44 InnoDB: Completed initialization of buffer pool
110623 12:31:44 InnoDB: Log file ./ib_logfile0 did not exist: new to be
created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110623 12:31:45 InnoDB: Log file ./ib_logfile1 did not exist: new to be
created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110623 12:31:46 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!
110623 12:31:46 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
110623 12:31:46 InnoDB: Waiting for the background threads to start
110623 12:31:47 Percona XtraDB (http://www.percona.com) 1.1.5-20.0 started;
log sequence number 15598454796
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 537035213, file name ./mysql-bin.000009
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
110623 12:31:47 InnoDB: Starting shutdown...
110623 12:31:52 InnoDB: Shutdown completed; log sequence number 15598455780
110623 12:31:52 innobackupex: completed OK!Скрипт для своей работы требует наличия опции datadir (обычно её значение "/var/lib/mysql") в конфигурационном файле my.cnf. В результате в директории /backups/2011-06-23_11-59-57 появляется полностью рабочая бинарная копия всех баз данных MySQL с данного сервера. В случае необходимости восстановления данных из созданного таким образом бекапа нужно остановить mysqld, скопировать содержимое директории /backups/2011-06-23_11-59-57 в /var/lib/mysql и вновь запустить mysqld.
От простого копирования содержимого директории с данными /var/lib/mysql данный подход отличается тем, что данные копируются особым образом, таким же, как с ними работает движок InnoDB и вместе с данными копируются лог-файлы. На 2-ом этапе подготовки (prepare) xtrabackup запускает встроенный в него слегка модифицированный InnoDB-движок и выполняет crash-recovery, используя информацию из лог-файлов. Этот шаг необходим, поскольку в процессе копирования mysql-сервер продолжает изменять базу и без него была бы нарушена целостность данных.
Пример из практики: база размером 80ГБ (du -sh /var/lib/mysql) первой командой копировалась 36 минут, вторая команда отрабатывала (там где --apply-log) 39 минут. По сети файлы переливались с master-а на slave 43 минуты. Итого на поднятие slave-сервера ушло 118 минут (2 часа). Как видно, в разы быстрее, чем было бы с mysqldump-ом и без какого-либо downtime.
Вот более удобный вариант использования, укоряющий перенос базы c master-а (с IP-адресом 10.11.12.12) на новый сервер, который будет slave-ом (с IP-адресом 10.11.12.13). Пакет xtrabackup должен быть установлен на обоих серверах.
[avz@slave] mkdir /tmp/db
[avz@master] innobackupex --defaults-file=/etc/my2.cnf --socket=/var/lib/mysql2/mysql.sock [email protected] --tmpdir=/tmp /tmp/db
[avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log --ibbackup=xtrabackup_55 /tmp/db/2011-06-23_12-52-23
[root@slave] service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] mv /tmp/db/2011-06-23_12-52-23 /var/lib/mysql
[root@slave] chown -R mysql.mysql /var/lib/mysql
[root@slave] service mysqld start
master> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.11.12.13' IDENTIFIED BY 'SomePassw';
slave> CHANGE MASTER TO MASTER_HOST='10.11.12.12', MASTER_PORT=3307, MASTER_USER='repl', MASTER_PASSWORD='SomePassw', MASTER_LOG_FILE='master-bin.001269', MASTER_LOG_POS=517948556;
slave> START SLAVE;
Команда во второй строке копирует данные и InnoDB-лог-файлы сразу на удалённый slave-сервер с адресом 10.11.12.13 в каталог /tmp/db с помощью scp. Параметры --defaults-file и --socket нужны в том случае, если на master-сервере несколько экземпляров mysqld – с помощью этих параметров явно указываем какой конфиг-файл использовать и к какому именно экземпляру нужно подключаться. Очень желательно настроить SSH-аутентификацию на ключах, чтобы можно было подключаться с master-а на slave без ввода пароля. На slave-сервере каталог /tmp/db должен быть создан предварительно. Команда в третьей строчке, запущенная уже на slave-сервере, выполняет восстановление базы на основе информации из log-файлов.
Параметр --ibbackup необходимо указать в том случае, если на момент запуска этой команды на slave-сервере еще не запущен mysqld. Она указывает какой именно бинарник xtrabackup использовать (в используемой на данной момент версии их три – xtrabackup, xtrabackup_51 и xtrabackup_55). Если же mysql-сервер на slave-сервере был запущен до того, как выполняется команда из строки 3, то версия нужного бинарника обычно определяется автоматически и использовать параметр --ibbackup нужды не возникает. После "innobackupex --apply-log ..." данные приобретают целостность и готовы к работе.
Желательно, чтобы под пользователем, который выполняет innobackupex, подключение к базе происходило без пароля. Иначе возникает необходимость добавить в 1-ую команду параметры --user и --password.
Значения для MASTER_LOG_FILE и MASTER_LOG_POS на 9-м шаге берутся из вывода команд на 2-м или 3-м шаге.
Еще пример из практики: суммарный размер файлов базы: 255ГБ (du -sh /var/lib/mysql), размер заархивированного gzip-ом SQL-дампа – 33ГБ. Первый этап (команда из 2-ой строки) выполнялся 7 часов 10 минут (сюда входит и передача по сети с помощью scp, к которой оба сервера подключены на скорости 1Гбит/сек). Второй этап (команда из 3-ей строки) занял 13 минут. После запуска mysqld на slave-сервере и команд "CHANGE MASTER TO..." + "START SLAVE" оказалось, что slave отстаёт от master-а примерно на пол-часа. Это отставание slave нагнал примерно за 7 минут. ИТОГО: весь процесс построения реплики со старта до получения рабочего slave-сервера с идентичными master-у данными занял 7 часов 30 минут. Конфигурация серверов в этом примере: 4 x Intel Xeon E7540 @2.00GHz (процессор 6-ти ядерный, в /proc/cpuinfo видно 48 ядер), RAM 256ГБ, диски 4x500ГБ SSD в RAID-10.
UPDATE от 04.09.2013.
В версии 2.1.4 уже всё немного поменялось (может и раньше, это просто первая из 2-й ветки, с которой я имел дело). Теперь процедура создания бекапа сразу на другом сервере выглядит так:
[avz@slave] mkdir /tmp/db
[avz@master] innobackupex --defaults-file=/etc/my2.cnf --socket=/var/lib/mysql2/mysql.sock --tmpdir=/tmp /tmp/db --compress --stream=xbstream ./ | ssh avz@slave "cd /tmp/db; xbstream -x"
[avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
[avz@slave] xtrabackup --prepare --target-dir=/tmp/db
[avz@slave] innobackupex --defaults-file=/etc/my2.cnf --apply-log /tmp/db
[root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] # mv /tmp/db/* /var/lib/mysql
[root@slave] # chown -R mysql.mysql /var/lib/mysql
[root@slave] # service mysqld start
Сетевой трафик - этап 1 (гигабитный интерфейс)
Для базы размером 135ГБ (du -sh /var/lib/mysql) длительность выполнения процедуры была следующей:
- команда в строке 2 выполнялась 67 минут;
- команда в строке 3 выполнялась 11 минут 12 секунд;
- команда в строке 4 выполнялась 1 минуту 10 секунд;
- команда в строке 5 выполнялась 5 секунд;
Также важно отметить, что сжатие с помощью опции --compress приводит к уменьшению размера ibd-файлов примерно в 2 раза.
Здесь конфигурация железа была следующей.
Master: CPU Intel Xeon E7540 @2.00GHz, RAM 256GB, RAID-10 на 4-x SSD-дисках INTEL SSDSA2CW600G3
Slave: CPU Intel Xeon E5-2650 0 @2.00GHz, RAM 256GB, RAID-10 на 4-x SSD-дисках EDGE Boost Pro
Утилиту qpress и сам xtrabackup удобнее всего брать в официальном репозитории Percona.
Данный инструмент распространяется по принципу open-source и является бесплатным, успешно протестирован мной в реальных условиях и замечательно работает как для простого резервного копирования, так и для копирования данных с целью поднятия slave-сервера для репликации. Поэтому я нахожу Percona xtrabackup весьма ценной штукой, учитывая что сам Oracle софт с аналогичной функциональностью предоставляет за деньги.
UPDATE от 2015-09-10.
Последний раз успешно поднял slave такой последовательностью команд:
[avz@slave] mkdir /tmp/db
[avz@master] innobackupex --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --tmpdir=/tmp --compress --compress-threads=8 --stream=xbstream --parallel=4 --lock-wait-timeout=120 --password=xxxxxx ./ | ssh avz@slave "xbstream -x -C /tmp/db"
[avz@slave] for bf in `find /tmp/db -iname "*\.qp"`; do echo "processing $bf" ; qpress -d $bf $(dirname $bf) && rm -f $bf; done
[avz@slave] innobackupex --defaults-file=/etc/my.cnf --apply-log --use-memory=190G /tmp/db
[root@slave] # service mysqld stop ; mv /var/lib/mysql /var/lib/mysql.old
[root@slave] # mv /tmp/db/* /var/lib/mysql
[root@slave] # chown -R mysql.mysql /var/lib/mysql
[root@slave] # service mysqld start
Версия MySQL: 5.6.23. Версия percona-xtrabackup: 2.2.12. Размер базы 240GB (по данным du -sh). Объем памяти на мастере и слейве - 192GB. Процесс занял часа 4. Lock таблиц на мастере продлился чуть более 5-ти минут:
150907 13:55:32 innobackupex: Executing FLUSH TABLES WITH READ LOCK...
150907 14:00:50 innobackupex: All tables unlocked
Параметр --lock-wait-timeout=120 означает, что xtrabackup будет ждать удобный момент для "FLUSH TABLES WITH READ LOCK", когда нет выполняющихся длинных запросов. Но ждать такой момент он будет не более 120 секунд. Если за 120 секунд не дождется, то отвалится с ошибкой. Если параметр не указать, то "удобный момент" выбираться не будет. Выдержка из официальной документации:
Waiting for queries to finish. Good moment to issue a global lock is the moment when there are no long queries running. But waiting for a good moment to issue the global lock for extended period of time isn’t always good approach, as it can extend the time needed for backup to take place. To prevent innobackupex from waiting to issue FLUSH TABLES WITH READ LOCK for too long, new option has been implemented: --lock-wait-timeout option can be used to limit the waiting time. If the good moment to issue the lock did not happen during this time, innobackupex will give up and exit with an error message and backup will not be taken. Zero value for this option turns off the feature (which is default).
UPDATE от 2016-07-15.
Если приходится иметь дело с MySQL версии 5.7.x, то нужно использовать пакет percona-xtrabackup-24 (а не percona-xtrabackup как было ранее). Есть все в том же репозитории.
