бэкап lvm mysql

Я читал о резервном копировании mysql с помощью lvm. Я понимаю, что вы создаете раздел lvm и выделяете определенный размер для mysql, оставляя достаточно места для снимков.

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

Есть ли подводные камни, на которые стоит обратить внимание, или недостатки?

Спасибо


mysql lvm
person Thomas    schedule 06.02.2012    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Запуск с включенным моментальным снимком LVM может привести к снижению производительности ввода-вывода до 6 раз.

http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-performance-in-snapshot-mode/

Я предлагаю использовать Percona XtraBackup как гораздо лучший инструмент горячего резервного копирования (отказ от ответственности: я работаю на Перкона).

person Bill Karwin    schedule 06.02.2012
comment
Спасибо за статью. Такого не встречал. Очень интересно. Что касается резервного копирования, я сейчас ищу что-нибудь бесплатное. - person Thomas; 07.02.2012
comment
@Thomas, Percona XtraBackup бесплатна, распространяется под лицензией GNU Public License. Перкона является сторонником бесплатного программного обеспечения с открытым исходным кодом. - person Bill Karwin; 07.02.2012
comment
Привет Билл. Извините за мой латовый комментарий. Виноват. Обязательно рассмотрю ваше решение. Спасибо еще раз - person Thomas; 07.02.2012
comment
Без проблем! Я понимаю, почему вы могли подумать, что я рекомендую коммерческий продукт. :) - person Bill Karwin; 07.02.2012
comment
@BillKarwin Я рассматривал возможность использования этого для системных тестов - создание моментального снимка в начале, а затем возвращение к нему после каждого набора тестов (в настоящее время таблицы усекаются и повторно заполняются вручную, что кажется менее чем идеальным). Будет ли Percona хорошим выбором для такого случая использования, когда будет много восстановлений за короткий промежуток времени, или мне лучше продолжать просто удалять и заполнять все заново? - person Thor84no; 04.01.2013
comment
@ Thor84no, если бы я создавал инфраструктуру для тестирования системы, я бы сохранил чистую копию каталога данных с исходным состоянием данных. После каждого набора тестов закрывайте mysqld и деструктивно копируйте чистый каталог данных поверх рабочего каталога данных, а затем перезапускайте mysqld. Это легко сделать с помощью команд оболочки, таких как rsync, но вы можете дополнительно использовать для этого XtraBackup: ">percona.com/doc/percona-xtrabackup/innobackupex/ - person Bill Karwin; 04.01.2013
comment
Или, если у вас уже есть репликация, вы можете сделать моментальный снимок LVM на подчиненном устройстве, и в этом случае вам не нужно беспокоиться о замедлении. - person rinogo; 28.12.2016
comment
@rinogo, да, это правда, если вы уверены, что раб - настоящая копия. - person Bill Karwin; 29.12.2016

arrow_upward
2
arrow_downward

Снимки LVM очень пугают InnoDB при определенных обстоятельствах. Почему?

Если у вас отключено innodb_file_per_table, ibdata1 будет есть все и его бабушка в нем. Что живет в ibdata1? Четыре вещи:

  • Страницы данных
  • Индексные страницы
  • Метаданные (например, список идентификаторов TableSpave)
  • Данные MVCC

Если вы пытаетесь создать моментальные снимки LVM в среде с интенсивной записью БД с выключенным innodb_file_per_table, вы можете выстрелить себе в ногу. Для моментального снимка LVM необходимо, чтобы файл ibdata1 был заранее хорошо объединен.

Недавно я провел следующий эксперимент:

У клиента в хостинговой компании моего работодателя возникли следующие проблемы с настройкой MySQL:

  • innodb_file_per_table выключен
  • 1,4 ТБ данных1
  • только 29 ГБ свободно в ibdata1
  • файловая система ext3 (ограничение размера одного файла 2 ГБ, гадость)

Я хотел настроить ведомое устройство MySQL, перенаправив папку /var/lib/mysql на другой сервер БД. Когда rsync был выполнен на ibdata1 без простоя, это заняло 42 часа. Вторая rsync для ibdata1 заняла 84 часа, обнаружила только 220 ГБ изменений и была выполнена едва ли на 15%. Я прервал эту миссию.

Моментальный снимок LVM может работать намного лучше, чем rsync. Тем не менее, любой моментальный снимок LVM, включающий очень большой ibdata1, будет подвержен тем же проблемам.

Если вы используете моментальный снимок LVM, используйте следующие параметры:

  • ВАРИАНТ 01) Используйте innodb_file_per_table. Снимки LVM понравятся вам за это, потому что они будут иметь дело с файлами меньшего размера. Вы также можете безвозвратно сжать ibdata1.
  • ВАРИАНТ 02) Используйте репликацию MySQL и делайте снимки LVM на ведомом устройстве.

С подчиненным сервером репликации MySQL вы можете

  • STOP SLAVE; (если у вас есть --skip-slave-start в my.cnf)
  • service mysql stop
  • выполнить снимок LVM
  • service mysql start
  • START SLAVE; (если у вас есть --skip-slave-start в my.cnf)

Таким образом, эти проблемы со снимками LVM никогда не увидят свет на Мастере производства.

Попробуйте и получайте удовольствие от этого !!!

person RolandoMySQLDBA    schedule 06.02.2012
comment
Я думал, что весь смысл моментальных снимков LVM в том, что ведомое устройство (или ведущее устройство) никоим образом не нужно останавливать. Просто все таблицы сбрасываются на диск с блокировками чтения, после чего можно сделать снимок LVM и снять блокировки чтения. Не так ли, Роландо? - person rinogo; 28.12.2016