Резервное копирование данных в MySQL

[noittom]

большое спасибо за статью, интересно!

[Londain]

Спасибо. Повторение — мать учения:

Средства создания горячих BackUp`ов MySQL
habrahabr.ru/blogs/mysql/63394/

Удаленный шифрованный бэкап MySQL при помощи LVM snapshot
habrahabr.ru/blogs/personal/102738/

Много о LVM:

habrahabr.ru/search/?q=lvm

[vanxant]

К сожалению, ваша статья не гуглится. Поэтому в своё время я её на нашел.

[vanxant]

*в смысле первая приведенная вами

[Londain]

Свежие комментарии — свежие мысли. Всегда хорошо.

[sphinxy]

Простой скрипт, заодно реализующий и шифрование:

nice -n 10 mysqldump -v -u USERNAME -p«PASSWORD»
--add-drop-table --add-locks --create-options --single-transaction \
--disable-keys --extended-insert --quick DATABASENAME | \
gzip -c \
| openssl aes-128-cbc -salt -kfile /home/USERNAME/.aes_pass -out /home/sql-dumps/base_`date "+%Y-%m-%d_%H-%M-%S"`_full.sql.gz.aes

[pavel_manylov]

добавить бы сюда ещё --master-data=2 (или 1, если настроена репликация) — тогда можно будет в экстренных случаях или при экстренном переносе данных с одного сервера на другой (без репликации на последнем) накатить бэкап, а не него — бинлоги с точки, которая запишется в файл

[josser]

На не очень больших базах неплохая штука

[coocheenin]

Sypex Dumper отличная, кстати, штука. Простая, как газета Гудок.
В особенности выручает на всяких недохостингах, где SSH не доступен.

[pro100tak]

Реплика мастер-мастер и группы слейвов покрывают 99% потерь данных. Криворукость администраторов никто пока не отменял.

[5hr4M]

Использую репликацию на сервер бекапов и уже оттуда снимаю бэкап раз 2 в часа и храню последнюю неделю :) для моих нужд достаточно :)

[sledopit]

Ну раз уж тут реплику рассматривали, то стоило бы упомянуть и бинлоги, которые позволяют откатывать базу с ювелирной точностью (вплоть до секунд), при условии, что бинлоги введутся как минимум с момента последнего бэкапа. Даже howto по восстановлению есть (:
Однако, стоит помнить, что бинлоги так же не являются полноценным бэкапом как минимум потому, что он должен ввестись на удалённом хосте.

[mgyk]

Для горячего копирования InnoDB/XtraDB есть XtraBackup, бесплатный в percona-форке mysql.
http://www.percona.com/doc/percona-xtrabackup/

[sevmax]

поддерживаю! Отличная софтина, прекрасно выполняет бэкап в очень короткое время по сравнению со стандартными средствами!

[PQR]

Обычно в связке с mysqldump для импорта созданного бекапа я использую стандартный консольный клиент mysql: mysql dbname < dump.sql
В чём преимущества утилиты mysqlimport, о которой вы упомянули?

[So1]

ну или
mysql> \. /path/to/file.sql
если файл на том же сервере

mysqlimport вам нужен если вы импортите с csv, например. По сути это интерфейс для LOAD DATA INFILE INTO TABLE

[So1]

к стати, никогда не использовал никакие GUI-дамперы — они мне просто не нужны, когда есть консольные тулзы
mysql
mysqlimport
mysqldump

Про Sypex Dumper, упомянутый в статье, слышал, — установил даже как-то, посмотрел, удалил — консоль ближе.

[slider]

он выручает когда консоль недоступна

[pavel_manylov]

это когда? Опишите конкретные примеры ситуация.

[slider]

это когда консоль недоступна

например на дешевых/бесплатных хостингах

[So1]

Все-равно не понятно. Вы с ssh не путаете случайно? Хостер может не предоставлять ssh-доступ, но почему я при помощи утилиты mysql не могу подрубиться к серверу? Шелл-то для этого не нужен…

[slider]

потому что адрес базы localhost, пароль — root

[foxmuldercp]

может потому что мускуль слушается чаще всего либо через сокет либо локально либо по жестким ограничениям

[FB3]

Ещё очень удобно дамп на другой сервак лить с помощью mysqldump и mysql через пайп.

[SeriousDron]

mysqlhotcopy это совсем не тоже самое что mysqldump, это как раз реализация вашего варианта номер один. Сбрасываем и блокируем таблицы и копируем файлы.

[AnViar]

Разве snapshot файловой системы гарантирует консистентность data-файлов DB?

[japh]

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

[falke2]

Статья из разряда «добавлю в закладки».
Спасибо, буду реализовывать через недельку.

[japh]

кстати, наличие снапшота вовсе не обязательно влечет за собой падение перформанса. все зависит от реализации снапшотов.

[Shc]

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

[erop]

Так можно прямо у гугла и спросить про mysqldiff. А вообще, насколько знаю, недавно mysqlidff добавили в инсталляцию MySQL Workbench.

[Shc]

я имел ввиду сравнение данных, а mysqldiff сравнивает, вроде, только структуру.
просто иногда возникает ситуация, когда хотелось бы узнать, насколько сломана репликация (и вычислять кем).

[kiba]

наверно уже не актуально, но отвечу для тех кто придёт сюда из гугла: сравнить чексуммы таблиц можно с помощью утилиты pt-table-checksum, которая входит в состав набора percona-toolkit.

[bdmalex]

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

Арендовать юниты для бэкапов? Может экономически выгоднее взять один ВДС в соседнем ДЦ, так как производительность процессора и объём ОЗУ здесь для задачи совершенно неважен?

[vanxant]

Ну если на этом ВДС вам выделят пару зеркалированных терабайт под бэкапы, то почему нет? (Ну я рассматриваю нормальных размеров проекты. Понятно что бложик с двумя сотнями спамкомментов можно хоть карандашом на бумажку бэкапить)

[bdmalex]

Нормальных размеров проекты — не занимаются арендой чужого оборудования. А ставят на колоь свои сервера. Экономически выгоднее, imho…

[vanxant]

Я про это и говорил, когда писал «арендовать пару юнитов». Имелись в виду места в стойках.
Установка своего сервера на коллокейшн обычно окупается за 8-12 месяцев (по сравнению с арендой такого же железа у хостера).

[xa4a]

В большинстве «живых» проектов регулярное выключение сервера БД на длительное время неприемлемо.

1. Master-Slave репликация (вероятно с >1 слейвом)
2. Выключаем слейв
3. Делаем бекап со слейва
…
4. PROFIT!

[qmax]

надоже…
dev.mysql.com/doc/refman/5.6/en/replication-solutions-backups.html

[petropavel]

innodb hot backup и mysqlhotcopy это ни в коем случае не «через текстовые файлы».
innodb hot backup — практически то же самое, что и percona xtrabackup.
mysqlhotcopy — просто копирует MYD/MYI файлы

[vanxant]

Спасибо за поправки, внёс в статью.

[stanlee]

не понятен смысл этого поста
автор открыл Америку чтоли?

[sphinxy]

Со связкой php-mysql в силу её простоты часто работают люди, которые всё изучают в стиле «погугли», то есть вместо нормального последовательного обучения от азов к суровым вещам изучают всё по чуть-чуть. Для них статья вполне может стать и откровением. Но в любом случае, лишний раз заставить задуматься про необходимость бекапов не лишнее.

[stanlee]

вряли тут для кого то откровение, а атких статей в нете куча, автор тупо пишет ниочем новом.

[nikitay]

спасибо. отличная статья-overview

[RinNas]

MySQL database management — clean, import and export data (ещё одна надстройка над mysqldump, нацеленная на скорость работы)
code.google.com/p/mysql-backup/

[svetasmirnova]

Ещё поправочка: InnoDB HotBackup теперь называется MySQL Enterprise Backup.

[strelchook]

У меня может и несколько неэффективный способ, но проблем с ним не испытывал. Сразу скажу, что особенность такова, что к таблицам запрос на DELETE не идет. Все данные удаляют кроны по истечению «срока давности». На основном и резервном серверах в каждой таблице есть поле updated с аттрибутами on update current timestamp. php-скрипт-крон раз в определенный промежуток времени (в зависимости от частоты наполнения таблиц) тащит из резервной таблицы последний по значению updated и проверяет в основной базе все записи с большим значением этого поля. Если таковые имеются, добавляет в резервную через replace into. Очищают основная и резервная база каждая себя сама по одним и тем же алгоритмам и тоже используя поле updated. Способ, возможно, несколько кустарный, зато работает. И основное в нем преимущество — кроны можно запускать даже ежеминутно и ничего не приходится останавливать при этом.

[1andy]

Под Windows — пользуемся MySqlBackupFTP — надстройка над mysqldump с простым интерфейсом, FTP, шифрованием и подтверждениями по емайлу. Одна из полезных фишек – позволяет делать бэкапы через phpMyAdmin когда нет другого выхода.

[ComodoHacker]

> Общая схема действий такова: блокируются все таблицы, сбрасывается файловый кэш БД, делается снэпшот файловой системы, разблокируются таблицы. После этого файлы спокойно копируются из снэпшота, после чего он уничтожается.

А что происходит при восстановлении с незавершенными на момент снепшота транзакциями?

[Murz]

А подскажите, существует ли способ оперативно посмотреть (или получить sql-дамп) базы с файлов бекапа, созданных по методу «1. Копирование файлов базы»?

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

Мы имеем в распоряжении только файлы .FRM, .MYD, .MYI, которые если только подсовывать рабочему серверу, но для этого нужны рутовые права. Хотелось бы как-то конвертнуть эти файлы в sql-дамп, но софта такого не нашёл.

Сообщите кто каким образом решает такие проблемы при бекапе mysql через файлы (снапшоты)?