Pull to refresh

Comments 52

большое спасибо за статью, интересно!
К сожалению, ваша статья не гуглится. Поэтому в своё время я её на нашел.
*в смысле первая приведенная вами
Свежие комментарии — свежие мысли. Всегда хорошо.
Простой скрипт, заодно реализующий и шифрование:

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

добавить бы сюда ещё --master-data=2 (или 1, если настроена репликация) — тогда можно будет в экстренных случаях или при экстренном переносе данных с одного сервера на другой (без репликации на последнем) накатить бэкап, а не него — бинлоги с точки, которая запишется в файл
Sypex Dumper отличная, кстати, штука. Простая, как газета Гудок.
В особенности выручает на всяких недохостингах, где SSH не доступен.
Реплика мастер-мастер и группы слейвов покрывают 99% потерь данных. Криворукость администраторов никто пока не отменял.
Использую репликацию на сервер бекапов и уже оттуда снимаю бэкап раз 2 в часа и храню последнюю неделю :) для моих нужд достаточно :)
Ну раз уж тут реплику рассматривали, то стоило бы упомянуть и бинлоги, которые позволяют откатывать базу с ювелирной точностью (вплоть до секунд), при условии, что бинлоги введутся как минимум с момента последнего бэкапа. Даже howto по восстановлению есть (:
Однако, стоит помнить, что бинлоги так же не являются полноценным бэкапом как минимум потому, что он должен ввестись на удалённом хосте.
поддерживаю! Отличная софтина, прекрасно выполняет бэкап в очень короткое время по сравнению со стандартными средствами!
UFO landed and left these words here
Обычно в связке с mysqldump для импорта созданного бекапа я использую стандартный консольный клиент mysql: mysql dbname < dump.sql
В чём преимущества утилиты mysqlimport, о которой вы упомянули?
ну или
mysql> \. /path/to/file.sql
если файл на том же сервере

mysqlimport вам нужен если вы импортите с csv, например. По сути это интерфейс для LOAD DATA INFILE INTO TABLE
к стати, никогда не использовал никакие GUI-дамперы — они мне просто не нужны, когда есть консольные тулзы
mysql
mysqlimport
mysqldump

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

например на дешевых/бесплатных хостингах
Все-равно не понятно. Вы с ssh не путаете случайно? Хостер может не предоставлять ssh-доступ, но почему я при помощи утилиты mysql не могу подрубиться к серверу? Шелл-то для этого не нужен…
потому что адрес базы localhost, пароль — root
может потому что мускуль слушается чаще всего либо через сокет либо локально либо по жестким ограничениям
Ещё очень удобно дамп на другой сервак лить с помощью mysqldump и mysql через пайп.
mysqlhotcopy это совсем не тоже самое что mysqldump, это как раз реализация вашего варианта номер один. Сбрасываем и блокируем таблицы и копируем файлы.
Разве snapshot файловой системы гарантирует консистентность data-файлов DB?
разумеется нет. необходимо базу либо остановить, либо «заморозить». первый вариант проще и может применятся, например, в комбинации с репликой — реплику переодически стопать и делать снапшот.
Статья из разряда «добавлю в закладки».
Спасибо, буду реализовывать через недельку.
кстати, наличие снапшота вовсе не обязательно влечет за собой падение перформанса. все зависит от реализации снапшотов.
а есть какие-то утилиты, чтобы сделать diff двух баз, не выгружая перед этим в текстовый формат?
Так можно прямо у гугла и спросить про mysqldiff. А вообще, насколько знаю, недавно mysqlidff добавили в инсталляцию MySQL Workbench.
я имел ввиду сравнение данных, а mysqldiff сравнивает, вроде, только структуру.
просто иногда возникает ситуация, когда хотелось бы узнать, насколько сломана репликация (и вычислять кем).
наверно уже не актуально, но отвечу для тех кто придёт сюда из гугла: сравнить чексуммы таблиц можно с помощью утилиты pt-table-checksum, которая входит в состав набора percona-toolkit.
Храниться бэкапы должны точно не на том же диске, что и живая база, и не на том же сервере. На случай пожаров и прочих катаклизмов лучше всего арендовать пару юнитов в соседнем дата-центре.

Арендовать юниты для бэкапов? Может экономически выгоднее взять один ВДС в соседнем ДЦ, так как производительность процессора и объём ОЗУ здесь для задачи совершенно неважен?
Ну если на этом ВДС вам выделят пару зеркалированных терабайт под бэкапы, то почему нет? (Ну я рассматриваю нормальных размеров проекты. Понятно что бложик с двумя сотнями спамкомментов можно хоть карандашом на бумажку бэкапить)
Нормальных размеров проекты — не занимаются арендой чужого оборудования. А ставят на колоь свои сервера. Экономически выгоднее, imho…
Я про это и говорил, когда писал «арендовать пару юнитов». Имелись в виду места в стойках.
Установка своего сервера на коллокейшн обычно окупается за 8-12 месяцев (по сравнению с арендой такого же железа у хостера).
В большинстве «живых» проектов регулярное выключение сервера БД на длительное время неприемлемо.


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

4. PROFIT!
innodb hot backup и mysqlhotcopy это ни в коем случае не «через текстовые файлы».
innodb hot backup — практически то же самое, что и percona xtrabackup.
mysqlhotcopy — просто копирует MYD/MYI файлы
не понятен смысл этого поста
автор открыл Америку чтоли?
Со связкой php-mysql в силу её простоты часто работают люди, которые всё изучают в стиле «погугли», то есть вместо нормального последовательного обучения от азов к суровым вещам изучают всё по чуть-чуть. Для них статья вполне может стать и откровением. Но в любом случае, лишний раз заставить задуматься про необходимость бекапов не лишнее.
вряли тут для кого то откровение, а атких статей в нете куча, автор тупо пишет ниочем новом.
У меня может и несколько неэффективный способ, но проблем с ним не испытывал. Сразу скажу, что особенность такова, что к таблицам запрос на DELETE не идет. Все данные удаляют кроны по истечению «срока давности». На основном и резервном серверах в каждой таблице есть поле updated с аттрибутами on update current timestamp. php-скрипт-крон раз в определенный промежуток времени (в зависимости от частоты наполнения таблиц) тащит из резервной таблицы последний по значению updated и проверяет в основной базе все записи с большим значением этого поля. Если таковые имеются, добавляет в резервную через replace into. Очищают основная и резервная база каждая себя сама по одним и тем же алгоритмам и тоже используя поле updated. Способ, возможно, несколько кустарный, зато работает. И основное в нем преимущество — кроны можно запускать даже ежеминутно и ничего не приходится останавливать при этом.
Под Windows — пользуемся MySqlBackupFTP — надстройка над mysqldump с простым интерфейсом, FTP, шифрованием и подтверждениями по емайлу. Одна из полезных фишек – позволяет делать бэкапы через phpMyAdmin когда нет другого выхода.
> Общая схема действий такова: блокируются все таблицы, сбрасывается файловый кэш БД, делается снэпшот файловой системы, разблокируются таблицы. После этого файлы спокойно копируются из снэпшота, после чего он уничтожается.

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

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

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

Сообщите кто каким образом решает такие проблемы при бекапе mysql через файлы (снапшоты)?
Only those users with full accounts are able to leave comments. Log in, please.