Комментарии 37
Центосы админите, а скрипты пишете в Винде? Поправьте символы конца строки.
Не знаю кто минусанул автору. Думаю данный пост очень хороший пример организации резервного копирования.
из разряда — прочитал-повторил-профит.
Спасибо за статью. На базе этого «скелета» можно делать свои варианты автоматизации бэкапа.
из разряда — прочитал-повторил-профит.
Спасибо за статью. На базе этого «скелета» можно делать свои варианты автоматизации бэкапа.
mysqldump прошлый век, взгляните на www.percona.com/software/percona-xtrabackup
П.С. да, этим инструментом сразу не получишь .sql dump, но зато на больших объемах данных, нагрузки на IO в разы меньше. Да и по времени бекап делается быстрее.
П.С. да, этим инструментом сразу не получишь .sql dump, но зато на больших объемах данных, нагрузки на IO в разы меньше. Да и по времени бекап делается быстрее.
Это решение мы тоже используем.
Описали пока именно старый и проверенный метод, используемый много лет.
Описали пока именно старый и проверенный метод, используемый много лет.
Напишите мануал как восстановить такой бекап «с нуля». Я нагуглил много чего, но по факту так и не смог восстановить. Базу не видно после рестарта. Наверно упускаю что-то очевидное.
Что имеется в виду под восстановлением «с нуля»?
Расскажите подробнее, пожалуйста.
Расскажите подробнее, пожалуйста.
Бекапим:
/usr/bin/innobackupex-1.5.1 --use-memory=1G --user=USER --password=PASS /db_backup/mysql --no-timestamp
/usr/bin/innobackupex-1.5.1 --use-memory=1G --user=USER --password=PASS --apply-log /db_backup/mysql
Если Вам нужно вытащить sql то вот:
mysql_install_db --basedir=/usr/local/mysql --datadir=/tmp/data
mysqld --basedir=/usr --datadir=/tmp/data/ -P 3307 &
echo $! > mysql.pid
mysql -uroot -P 3307
mysqlcheck -P 3307 --user root --all-databases
mysqldump -uroot -P 3307 an_app > dump.sql
kill `cat mysql.pid`
Eсли нужно сразу восстановить все базы, без генерации sql, то после apply-log, перемещаете директорию в /var/lib/ (либо в директорию которая прописана в конфиге mysql — datadir)
/usr/bin/innobackupex-1.5.1 --use-memory=1G --user=USER --password=PASS /db_backup/mysql --no-timestamp
/usr/bin/innobackupex-1.5.1 --use-memory=1G --user=USER --password=PASS --apply-log /db_backup/mysql
Если Вам нужно вытащить sql то вот:
mysql_install_db --basedir=/usr/local/mysql --datadir=/tmp/data
mysqld --basedir=/usr --datadir=/tmp/data/ -P 3307 &
echo $! > mysql.pid
mysql -uroot -P 3307
mysqlcheck -P 3307 --user root --all-databases
mysqldump -uroot -P 3307 an_app > dump.sql
kill `cat mysql.pid`
Eсли нужно сразу восстановить все базы, без генерации sql, то после apply-log, перемещаете директорию в /var/lib/ (либо в директорию которая прописана в конфиге mysql — datadir)
Посмотрите внимательно код — там есть поддержка xtrabackup.
Не проще ли было бы дать ссылку на GitHub-репозиторий с этими скриптами? Например, я хочу воспользоваться вашим решением. Мне копировать и собирать скрипты в ручную из поста? Не самое удобное решение, мягко говоря.
Извините, в репо этого скрипта нет.
Как только разместим — сообщу.
Как только разместим — сообщу.
Такие решения обычно простым копированием себе в проект не портировать. Это не готовый набор скриптов которые взял и поставил. Поэтому как ни крути, придется кусками копировать к себе с полным разбором, а что делают приведенные строки.
Оригинальный скрипт можно скачать тут sourceforge.net/projects/automysqlbackup
Зашёл сказать, что первая картинка замечательна.
Интересно, почему все (ну хорошо, большинство) мучаются с бекапами MySQL на продакшене? Таблицы лочат и занимаются прочей противоестественной деятельностью, ведущей к деградации производительности на сервере.
Ведь есть вполне нормальный способ: поднимаем связку master-slave, и уже со slave делаем бекапы. Все довольны: и производительность не страдает, и в процессе бекапа с сервером можно делать что угодно и как угодно и на худой случай всегда имеем «горячую копию» в виде этого самого слейва…
Ведь есть вполне нормальный способ: поднимаем связку master-slave, и уже со slave делаем бекапы. Все довольны: и производительность не страдает, и в процессе бекапа с сервером можно делать что угодно и как угодно и на худой случай всегда имеем «горячую копию» в виде этого самого слейва…
К сожалению, не всегда есть возможность поднять репликацию.
Когда она есть — то, конечно, используется slave для бэкапа.
Когда она есть — то, конечно, используется slave для бэкапа.
Вы не поверите, но иной раз попадаются клиенты, которые могут заказать екоммерс за пару млн, а когда дело доходит до архитектуры и серверах, они начинают выпучивать глаза и говорить — «а зачем нам 3 сервера?»
А это уже дело исполнителя — рассказать клиенту, что он в итоге получит и сколько ему встанет отсутствие 3го сервера. Обычно такие люди очень неплохо бабло считают. А вот ИТшники очень редко умеют говорить что-то кроме «надо больше серверов» :)
Для слэйва и слабенькой виртуалки достаточно. А на нормальном продакшене не реально дампами пользоваться.
Требования разные бывают. Причин, по которым нельзя задерживать сервер БД для бэкапа совсем мало, и у многих таких причин нет. Ночью, как правило, сервер простаивает и задержка в работе БД никого не побеспокоит. Тем более, лок делается только на запись, а чтение выполняется как обычно.
А держать слейв ради бэкапов — это хоть и мелкая, но деградация производительности мастера, дополнительные затраты на еще один сервер и его обслуживание, плюс обеспечение не только того, чтобы бэкапы делались правильно, но и того, чтобы мастер-слейв корректно реплицировался и не разваливался. Для всех (ну хорошо, большинства :) такая морока не оправдана.
А держать слейв ради бэкапов — это хоть и мелкая, но деградация производительности мастера, дополнительные затраты на еще один сервер и его обслуживание, плюс обеспечение не только того, чтобы бэкапы делались правильно, но и того, чтобы мастер-слейв корректно реплицировался и не разваливался. Для всех (ну хорошо, большинства :) такая морока не оправдана.
Когда дело доходит до бэкапа своих баз, каждый изобретает свой велосипед.
Давно ищу комплексное решение для бэкапа БД на linux сервере. Хочется, чтобы все удобно настраивалось и работало из коробки.
Резервное копирование с помощью вороха самописных bash-скриптов не вызывает у меня доверия.
Резервное копирование с помощью вороха самописных bash-скриптов не вызывает у меня доверия.
>tar -czvf "$1.tgz". 2>&1
>tar -cjvf "$1.tbz2". 2>&1
tar давно умеет понимать тип сжатия по расширению, с помощью -a
tar -cavf "$1.tgz". 2>&1
tar -cavf "$1.tbz2". 2>&1
итд
>tar -cjvf "$1.tbz2". 2>&1
tar давно умеет понимать тип сжатия по расширению, с помощью -a
tar -cavf "$1.tgz". 2>&1
tar -cavf "$1.tbz2". 2>&1
итд
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бекап баз данных – есть ли он?