Как организовать горячее резервное копирование MySQL?
Есть сервер на котором крутится средних размеров БД (около 1Гб), во время деплоя перед миграциями делается бэкап базы (mysqldump), что весьма серьезно тормозит время разворачивания новой версии сайта.
Имеет ли смысл разворачивать Percona Xtrabackup для быстрого резервного копирования базы данных и в случае чего быстрого восстановления к прежнему состоянию? Какие результаты по времени резервного копирования, восстановлению по сравнению с mysqldump?
По-моему, самый простой способ в данном случае — организовать master-slave репликацию. Перед релизом репликацию останавливать, делать бэкап со slave. Если что-то во время релиза пошло не так на master — переключать все запросы на slave.
используем mysql с базой на zfs партишене. если downntime в демяток секунд не критичен, в подобных ситуациях быстрее и надежнее выполнять следующее:
1. остановить mysql
2. снять zfs снэпшот партишена с базой (атомарная операция, выполняется моментально)
3. старотовать mysql
восстановление такое же, вместо п.2 — rollback, также атомарная операция
script88, поясните, пожалуйста, почему Вы так считаете.
для zfs работа что на партишене без снэпшотов, что со снэпшотами, никак не отличается ввиду особенностей самой файловой системы (copy-on-write). операция создания снэпшота атомарна, скорость не зависит от объемов файловой системы. внесение изменений в базу после создания снэпшота будет вместо перезаписи существующих блоков (которые не обязательно перезаписываются на месте) создавать новые блоки, только и всего. после того, как точка отката будет не нужна, удаление снэпшота просто освободит блоки на файловой системе, которые уже не нужны.
потому описанная операция, применительно к mysql (настроенному по всем рекомендациям «mysql на zfs») не будет «заметна».
eugene_t, поясняю
Если БД большая по объему, то остановка и запуск mysql может продолжатся довольно таки долго, я бы даже сказал очень долго, иной раз может затянутся на пару часов. По поводу снепшотов нареканий нет :)
Средний
