percona xtrabackup: экспертные возможности (Алексей Копытов)

Post on 01-Jul-2015

3.606 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Percona XtraBackup:экспертные возможности

alexey.kopytov@percona.com

Свободная утилита для резервного копирования СУБД MySQL

5.05.1 + встроенная InnoDB

5.1 + InnoDB плагин5.5

5.05.15.5

5.1, 5.5 (стандартные

storage engines)

5.2, 5.3, 10.0(скоро)

Бэкап — копия данных

Чем плох cp/scp/rsync/mc?

Как работает InnoDB?

Восстановление после сбоя

Идея реализации

Подготовка к восстановлению

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

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

Инкрементальные бэкапы:плюсы и минусы

Нетранзакционные данные● .frm файлы● MyISAM, CSV, Archive, ...● информация о master/slave в репликации

(исправлено в MySQL 5.6)

Нетранзакционные данные

Требуют блокировки(FLUSH TABLES WITH READ LOCK)

XtraBackup

xtrabackup innobackupex

ibdata1, *.ibd,логи

.frm, MyISAM, CSV,FLUSH TABLES WITH

READ LOCK

Основные команды:● создать резервную копию

– innobackupex /mnt/data/backup

● подготовить к восстановлению– innobackupex --apply-log /mnt/data/backup

● восстановить– innobackupex --copy-back/mnt/data/backup

Потоковый режим

Компрессияinnobackupex --stream=tar . | gzip - > /data/backup/backup.tar.gz

Потоковый режим

Шифрованиеinnobackupex --stream=tar . | openssl des3 -salt -k “password” > backup.tar.des3

Потоковый режим

Копирование на другой хостinnobackupex --stream=tar . | ssh user@host "tar -xif - -C /data/backup"

Потоковый режим

Всё сразуinnobackupex --stream=tar . | gzip - | openssl des3 -salt -k "password" | ssh user@host "cat - > /data/backup.tar.gz.des3"

Производительность(минимизация overhead)

Минимизация overhead

Ресурсы

Свободно

Сервер

Ресурсы

Свободно

Сервер

XtraBackup

XtraBackup

I/O throttling--throttle=N

Ограничить скорость копирования до N МБ/с

xtrabackup --throttle=1 ...

readread writewrite readread writewrite

секунда 1

readread writewrite readread writewrite

секунда 2

readread writewrite readread writewrite

секунда 3

readread writewrite waitwait

секунда1

readread writewrite waitwait

секунда 2

readread writewrite waitwait

секунда 3

I/O throttling

Решение: потоковый режим + утилита pv:

$ innobackupex --stream=tar /tmp | pv -q -L1m | tar -xvf - -C /data/backup

Ограничение:--throttle работает только с таблицами InnoDB.

Оптимизация кэша

● кэш заполняется "холодными" данными● "горячие" данные могут уйти в swap

Дисковый кэш

Холодные данныеГорячие данные

Холодные данные

Горячие данные

XtraBackup

Оптимизация кэша

на Linux:

– posix_fadvise(POSIX_FADV_DONTNEED)

– данные не кэшируются

– работает автоматически

Параллельное копирование

● параллельное копирование в N потоков

● эффективное использование диска

● лучше всего заметно на SSD

● может ускорить копирование с/на HDD

Серверibdata1

actor.ibd

customer.ibd

film.ibd

Бэкап--parallel=4ibdata1

film.ibd

customer.ibd

actor.ibd

Параллельное копирование

$ innobackupex --parallel=4 --no-timestamp /data/backup...[01] Copying ./ibdata1 to /data/backup/ibdata1[02] Copying ./sakila/actor.ibd to /data/backup/./sakila/actor.ibd[03] Copying ./sakila/customer.ibd to /data/backup/./sakila/customer.ibd[04] Copying ./sakila/film.ibd to /data/backup/./sakila/film.ibd

● имеет смысл только с innodb_file_per_table=1

● в XtraBackup 1.6 не работало в потоковом режиме

● исправлено в XtraBackup 2.0

Блокировка сервера

Что делаетFLUSH TABLES WITH READ LOCK?● устанавливает глобальную блокировку на

запись– INSERT/UPDATE/DELETE/ALTER блокируются

● закрывает открытые таблицы– ждёт, пока все текущие запросы завершатся

● блокирует COMMIT

● при закрытии таблиц FTWRL ждёт, пока завершаться все текущие запросы

● SELECT * FROM BIG_TABLE может заблокировать XtraBackup

Проблема №1

Убивать длинные запросы до начала копирования

Решение:

● большие MyISAM таблицы● блокируют запись на время их копирования● пример: забытая временная таблица на 100GB

Проблема №2

innobackupex --rsync

– использует rsync для копирования нетранзакционных данных

– два этапа:● копирует основную часть до блокировки● копирует "дельту" внутри блокировки

– НЕ работает в потоковом режиме

Решение №1:

Пример --rsync

$ innobackupex --rsync /mnt/backup...120926 15:23:44 Starting rsync as: rsync -t "/var/lib/mysql" --files-from="/tmp/xtrabackup_rsyncfiles_pass1" "/mnt/backup/2012-09-26_15-23-36"120926 15:23:45 rsync finished successfully.120926 15:23:45 innobackupex: Finished a prep copy of .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSV, .CSM and .opt files...120926 15:23:55 innobackupex: All tables locked and flushed to disk120926 15:23:55 Starting rsync as: rsync -t "/var/lib/mysql" --files-from="/tmp/xtrabackup_rsyncfiles_pass2" "/mnt/backup/2012-09-26_15-23-36"120926 15:23:55 rsync finished successfully....120926 15:23:55 innobackupex: All tables unlocked

innobackupex --no-lock

– не выполняет FLUSH TABLES WITH READ LOCK

Решение №2:

--no-lock

● убедитесь, что во время создания бэкапа НЕ выполняются:– ALTER TABLE на любые таблицы;

– INSERT/UPDATE/DELETE на MyISAM таблицы

Статистика

Последовательная вставка

Случайная вставка

Фрагментация

xtrabackup --stats

table: tpcc/order_line, index: PRIMARY, space id: 25, root page: 3, zip size: 0 estimated statistics in dictionary: key vals: 32471816, leaf pages: 264267, size pages: 302592 real statistics: level 2 pages: pages=1, data=8406 bytes, data/pages=51% level 1 pages: pages=467, data=4756806 bytes, data/pages=62% leaf pages: recs=35116662, pages=264267, data=2410713870 bytes, data/pages=55%

Что делать?● перестроить фрагментированные индексы:

– OPTIMIZE TABLE для PRIMARY KEY

– DROP INDEX / CREATE INDEX для вторичных индексов (fast index creation!)

Частичноекопирование/восстановление

Экспорт

Полный бэкап

ibdata

actor.ibd

customer.ibd

film.ibd

экспорт

Сервер 2

ibdata

actor.ibd

customer.ibd

film.ibd

Сервер 1

ibdata

actor.ibd

customer.ibd

film.ibd

Бэкап

● проблема: восстановить отдельные таблицы InnoDB из полного бэкапа● innobackupex --export для подготовки● использовать improved table import в Percona Server для восстановления● innodb_file_per_table=1

ЭкспортПочему просто не скопировать .ibd файлы?

● метаданные:– InnoDB data dictionary (space ID, index ID, указатели на

корневые индексные страницы). Хранится в основном tablespace (ibdata1)

– служебные записи в .ibd файлах (space ID, LSN, trx ID, index ID и т.д.)

● innobackupex --export записывает метаданные в .exp файлы

● Percona Server использует .exp файлы для импорта

Экспорт$ innobackupex --apply-log --export --target-dir=/data/backup...xtrabackup: export metadata of table 'sakila/customer' to file `./sakila/customer.exp` (4 indexes)xtrabackup: name=PRIMARY, id.low=23, page=3xtrabackup: name=idx_fk_store_id, id.low=24, page=4xtrabackup: name=idx_fk_address_id, id.low=25, page=5xtrabackup: name=idx_last_name, id.low=26, page=6...

Импорт в Percona Server● Percona Server:

– поддерживает восстановление на другом хосте

1. (на другом хосте)CREATE TABLE customer(...);

2. SET FOREIGN_KEY_CHECKS=0;

3. ALTER TABLE customer DISCARD TABLESPACE;

4. копируем customer.ibd на другой хост

5. SET GLOBAL innodb_import_table_from_xtrabackup=1;

6. ALTER TABLE customer IMPORT TABLESPACE;

7. SET FOREIGN_KEY_CHECKS=1;

Импорт в MySQL● "обычный" MySQL:

– можно восстановить только на том же хосте

– не допускаются DROP/CREATE/TRUNCATE/ALTER между копированием и импортом

1. ALTER TABLE customer DISCARD TABLESPACE;

2. <копируем customer.ibd в директорию данных>

3. ALTER TABLE customer IMPORT TABLESPACE;

Частичное копирование● скопировать таблицы/базы, а не все данные

● InnoDB таблицы:

– требуют innodb_file_per_table=1

– процедура восстановления такая же (DISCARD TABLESPACE)

– те же ограничения в "обычном" MySQL

– нет ограничений в Percona Server innodb_import_table_from_xtrabackup=1

Как скопировать отдельные таблицы?

● --databases=”database1[.table1] ...”,пример: --databases=”employees sales.orders”

● --tables-file=filename, файл содержит database.table, по одной на строчку

● --include=regexp, пример: --include='^database(1|2)\.reports.*

Подготовка частичного бэкапа:$ innobackupex --apply-log --export /data/backup

...120407 18:04:57 InnoDB: Error: table 'sakila/store'InnoDB: in InnoDB data dictionary has tablespace id 24,InnoDB: but tablespace with that id or name does not exist. It will be removed from data dictionary....xtrabackup: export option is specified.xtrabackup: export metadata of table 'sakila/customer' to file `./sakila/customer.exp` (4 indexes)xtrabackup: name=PRIMARY, id.low=62, page=3xtrabackup: name=idx_fk_store_id, id.low=63, page=4xtrabackup: name=idx_fk_address_id, id.low=64, page=5xtrabackup: name=idx_last_name, id.low=65, page=6...

Восстановление из частичного бэкапа

● Не-InnoDB таблицы– можно просто скопировать файлы

● InnoDB (MySQL):– ALTER TABLE ... DISCARD/IMPORT TABLESPACE

– те же ограничения (тот же сервер, без ALTER/DROP/TRUNCATE после копирования)

● XtraDB (Percona Server):– xtrabackup --export при подготовке

– innodb_import_table_from_xtrabackup=1;

– ALTER TABLE ... DISCARD/IMPORT TABLESPACE

– нет ограничений

Отдельные партиции

reports

CREATE TABLE reports (d DATE, t TEXT)PARTITION BY RANGE (YEAR(d))( PARTITION p_2010 VALUES LESS THAN (2010), PARTITION p_2011 VALUES LESS THAN (2011), PARTITION p_2012 VALUES LESS THAN (2012), PARTITION p_cur VALUES LESS THAN (MAXVALUE));

Хочется:

● скопировать p_2010

● удалить p_2010

p_2011

p_2010

p_cur

p_2012

Как копировать отдельные партиции?

$ ls -1 /usr/local/mysql/data/test/reports*/usr/local/mysql/data/test/reports#P#p_2010.ibd/usr/local/mysql/data/test/reports#P#p_2011.ibd/usr/local/mysql/data/test/reports#P#p_2012.ibd/usr/local/mysql/data/test/reports#P#p_cur.ibd/usr/local/mysql/data/test/reports.frm/usr/local/mysql/data/test/reports.par

Как копировать отдельные партиции?

$ xtrabackup --backup --datadir=/usr/local/mysql/data/ --tables='reports#P#p_2010'

...

[01] Copying ./ibdata1 to /data/backup/ibdata1[01] ...done[01] Copying ./test/reports#P#p_2010.ibd to /data/backup/./test/reports#P#p_2010.ibd[01] ...done[01] Skipping ./test/reports#P#p_2011.ibd

[01] Skipping ./test/reports#P#p_2012.ibd

[01] Skipping ./test/reports#P#p_cur.ibd

Подготовка$ xtrabackup --prepare --export --target-dir=./

$ ls -1 test/

reports#P#p_2010.expreports#P#p_2010.ibd

Восстановление

● в MySQL можно восстановить только как отдельную таблицу:

mysql> CREATE TABLE reports_2010( d DATE, t TEXT);

mysql> ALTER TABLE reports_2010 DISCARD TABLESPACE;

Восстановление$ cp /data/backup/test/reports#P#p_2010.exp /usr/local/mysql/data/test/reports_2010.exp

$ cp /data/backup/test/reports#P#p_2010.ibd /usr/local/mysql/data/test/reports_2010.ibd

mysql> SET GLOBAL innodb_import_table_from_xtrabackup=1;

mysql> ALTER TABLE report_2010 IMPORT TABLESPACE;

● та же процедура для MyISAM (только без ALTER TABLE)

Point-in-time recovery

Point-in-Time Recovery

Бинарный лог

Бинарный лог

Координаты и XtraBackup● печатаются по завершении копирования:

innobackupex: Backup created in directory '/mnt/backup/full'innobackupex: MySQL binlog position: filename 'mysql-bin.000001', position 418155120925 17:22:16 innobackupex: completed OK!

● сохраняются в директории бэкапа в файле xtrabackup_binlog_info:

mysql-bin.000001 418155

Point-in-Time Recoverymysqlbinlog для проигрывания бинарного лога с момента последнего бэкапа до нужного момента времени:$ mysqlbinlog --start-position=418155 --stop-datetime="2012-10-21 13:50:00" mysql-bin.00001

Клонирование узлов в репликации

Копирование слейва

xtrabackup_slave_info● innobackupex --slave-info

– записывает позицию чтения бинарного лога на мастере для текущего слейва

– сохраняется в xtrabackup_binlog_info в виде команды CHANGE MASTER:

CHANGE MASTER TOMASTER_LOG_FILE='mysql-bin.00001'MASTER_LOG_POS=68212201;

Клонирование слейва

Пример: клонирование в потоковом режиме1. innobackupex --stream=tar /tmp --slave-info | ssh user@NEWSLAVE "tar xfi - -C /var/lib/mysql"

На новом слейве:

2. innobackupex --apply-log /var/lib/mysql

3. выполнить CHANGE MASTER из xtrabackup_slave_info

Добавление нового узлав Percona XtraDB Cluster:

Новые функции вXtraBackup 2.0

Новые функции вXtraBackup 2.0

● потоковые инкрементальные бэкапы● встроенная параллельная компрессия● xbstream● копирование/восстановление

InnoDB buffer pool

Потоковые инкрементальные бэкапы

● проблема: потоковые инкрементальные бэкапы не работали в XtraBackup 1.6– innobackupex использовал внешнюю утилиту для отправки

InnoDB файлов в поток

– xtrabackup не мог быть использован для сканирования файлов и вычисления инкрементальных дельт

● в XtraBackup 2.0:– xtrabackup сам умеет генерировать потоки в формате TAR

или XBSTREAM. Теперь можно делать:

innobackupex --stream=tar --incremental ... | ssh user@host

Встроенная компрессия● с дисковым местом всегда проблемы● компрессия внешними утилитами имеет

ограничения

Компрессия внешними утилитамиinnobackupex --stream=tar . | gzip - > /data/backup.tar.gz

● gzip/bzip2 однопоточны (1 ядро CPU!)● pigz (многопоточный вариант gzip) умеет

параллельную компрессию, но не декомпрессию

● нужно декомпрессировать весь бэкап, даже если нужно восстановить 1 таблицу

Встроенная компрессия● новая опция innobackupex --compress

● использует QuickLZ: http://quicklz.com/– “the world's fastest compression library, reaching 308

Mbyte/s per core”

– сочетает скорость с неплохим сжатием● другие алгоритмы (gzip/bzip2/...) будут добавлены позже

● каждый файл сжимается в отдельный "архив"

– не нужно декомпрессировать всё, если нужна только одна таблица

Встроенная компрессия● многопоточная (компрессия и декомпрессия)

● можно использовать вместе с параллельным копированием:innobackupex --parallel=4 --compress --compress-threads=8

Файлы

ibdata1

actor.ibd

customer.ibd

film.ibd

I/O threads Compressionthreads

1

2

3

4

1

8765432

Проблемы с tar● компрессия в потоковом режиме невозможна

● параллельное копирование невозможно

● инкрементальные бэкапы невозможны

.tar file format

headeractor.ibd.gzheader customer.ibd.gz header film.ibd.gz ...

File name

File mode

File size

Checksum

...

нужно знать размер файла додобавления нового => нужносначала писать во временный файл

Формат xbstream

...

actor.ibd.gz chunk #1

chunk header

chunk header

film.ibd.gz chunk #1

header

actor.ibd.gz chunk #2

actor.ibd.gz chunk #1actor.ibd.gz chunk #1

chunk header

chunk header

film.ibd.gz chunk #2

● можно отправлять в поток динамические данные

● можно отправлять несколько файлов параллельно

Утилита xbstream● используется для извлечения файлов из

потоков xbstream● tar-подобный интерфейс:

– xbstream -x [-C directory]прочитать поток со стандартного ввода и извлечь файлы в текущую или другую (-C) директорию

xbstream: пример

$ innobackupex --parallel=8 --compress --compress-threads=4 --stream=xbstream ./ | ssh user@host ”xbstream -x -C /data/backup”...xtrabackup: Starting 8 threads for parallel data files transfer[01] Compressing and streaming ./ibdata1[02] Compressing and streaming ./sakila/actor.ibd[03] Compressing and streaming ./sakila/address.ibd[04] Compressing and streaming ./sakila/category.ibd[05] Compressing and streaming ./sakila/city.ibd[06] Compressing and streaming ./sakila/country.ibd[07] Compressing and streaming ./sakila/customer.ibd

Восстановление InnoDB buffer pool● Percona Server:

page1 page2 page3 ...

InnoDB buffer poolmost recently used least recently used

ib_lru_dump

id id id id

Восстановление InnoDB buffer pool● XtraBackup 2.0:

– автоматически копирует ib_lru_dump

– buffer pool в "горячем" состоянии после восстановления из бэкапа!

– innodb_buffer_pool_restore_at_startup=1

Новые функции вXtraBackup 2.x

Быстрые инкрементальные бэкапы

Быстрые инкрементальные бэкапы● 2 решения:

– отслеживать модификации страницна стороне сервера

– архивировать транзакционные логи на сервере

Отслеживание модификаций● changed page tracking

(новая функция в Percona Server):datadir

ibdata1

actor.ibd

customer.ibd

film.ibd

ib_logfile0

ib_logfile1

отслеживаемзапись

bitmap изменений

ib_modified_log.*

инкр. бэкап

xtrabackup--backup--incremental-lsn

ibdata1.delta

actor.ibd.delta

customer.ibd.delta

film.ibd.delta

Архивирование логов на сервере● log archiving

(новая функция в Percona Server)datadir

ibdata1

actor.ibd

customer.ibd

film.ibd

ib_logfile0

ib_logfile1

log_archive_dir

ib_log_archive_LSN1

ib_log_archive_LSN2

ib_log_archive_LSN3

ib_log_archive_LSN...

...

копия

full backup

ibdata1

actor.ibd

customer.ibd

film.ibd

Компактные бэкапы● идея: исключать "несущественные" страницы

из бэкапа

1 5432 6 ibdata1...

страницы в данных

xtrabackup

421 page map file

страницы PKстраницыsecondary key

свободные страницы

страницы в бэкапе

Компактные бэкапы● Плюсы:

– меньше места на диске (иногда гораздо меньше)

– высвобождают неиспользованные страницы

● Минусы:– больше времени на --apply-log

Встроенное шифрование● многопоточное

● расшифровка/восстановление отдельных таблиц

ibdata1

actor.ibd

customer.ibd

film.ibd

I/O threads Encryptionthreads

1

2

3

4

1

8765432

libgcrypt.so

Итоги● Архитектура● Базовые возможности

– полные и инкрементальные бэкапы

– потоковый режим

● Производительность– I/O throttling

– оптимизация кэша

– паралелльное копирование

Итоги● Блокировка

– --no-lock

– --rsync

● Статистика● Частичное копирование и восстановление● Point-in-Time Recovery● Клонирование узлов в репликации

Итоги● Новые функции в XtraBackup 2.0:

– встроенная параллельная компрессия

– потоковые инкрементальные бэкапы

– xbstream

– копирование/восстановление состояния InnoDB buffer pool

● Новые функции в разработке:

– быстрые инкрементальные бэкапы

– компактные бэкапы

– встроенное шифрование

Ссылки● Документация:

http://www.percona.com/doc/percona-xtrabackup/

● Скачать:http://www.percona.com/software/percona-xtrabackup/downloads/

● Обсудить: http://groups.google.com/group/percona-discussion

● #percona IRC channel on Freenode

● Посмотреть в код:https://launchpad.net/percona-xtrabackup

● Баги:https://bugs.launchpad.net/percona-xtrabackup

Слайды:http://bit.ly/HL2012-XB

Вопросы?

top related