Страница 1 из 1

инкрементное бэкапирование БД?

Добавлено: 2018-01-21 17:17:30
tull
Имеется БД mysql где-то на 5 Гб.
По ночам делается полный бэкап, но очень хотелось бы еще делать промежуточные бэкапы каждый час или даже 20-30 минут.
Разумеется, хотелось бы сохранять абсолютно все изменения, произошедшие с момента полного бэкапа.
Что посоветуете?

Вообще это база данных форума. Основная часто обновляемая инфа это: собственно сообщения на форуме (самое важное), внутренняя почта, сами юзеры. Ну и еще по мелочи кое-что (правда этих мелочей таблиц на 15).
По идее для инкрементных бэкапов можно делать селекты из этих таблиц, для записей с временем изменения больше, чем время начала полного бэкапа. Правда, не для всех таблиц есть такое время, например в таблице юзеров есть только время добавления юзера, а не время его изменения. Но это либо можно прикрутить, либо вообще забить на это, т.к. изменения профиля юзера происходят довольно редко, и к тому же они не так существенны.
Но это получается довольно много возни и доработок.

Нет каких-то готовых решений, позволяющих реализовать грамотное инкрементное бэкапирование БД? (в которой не только появляются новые записи, но и иногда изменяются старые).

Да, на всякий случай: некоторые таблицы в InnoDB (сообщения, внутрення почта), некоторые в Myisam
БД на самом деле MariaDB 10.

инкрементное бэкапирование БД?

Добавлено: 2018-01-23 0:40:56
FiL
на сколько я знаю - нет.
Но есть снапшоты на уровне сисемы и есть бинарные логи на уровне базы данных. Это не совсем то, что спрашивали, но задачу решает.

инкрементное бэкапирование БД?

Добавлено: 2018-01-25 21:33:35
Alex Keda
я так понимаю, бэкап работе мешает? или какие показания к тому что не хочется делать его целиком?
поднимать репликацию, и бэкапить на другом сервере, снова целиком, с любой периодичностью.

инкрементное бэкапирование БД?

Добавлено: 2018-01-26 1:21:33
FiL
ну, если 5 гигов бакапить каждые 30 минут и держать хотя-бы месяц бакапов, то это набегает.
Собственно, даже если реплику в 5 гигов каждые пол часа бакапить, то ей может весьма грустно стать. А если база нагруженная, то и реплика будет нагруженная... А если оно вырастет до 50 гиг? Не, решать через реплику - это тупиковый путь.
Другое дело, что при наличии реплики может бакапы часто делать не надо будет, хватит раз в сутки. Это другое дело.

инкрементное бэкапирование БД?

Добавлено: 2018-01-27 18:54:20
tull
Включил bin-log
Теперь когда делается бэкап, выполняю PURGE BINARY LOGS BEFORE NOW()
Только я чего-то не могу сообразить, это надо делать до, того как начал выполняться mysqldump, или когда он уже отработал?
Во время снятия дампа LOCK TABLES не делается, форум работает, т.е. могут происходить любые изменения, появляться новые записи

З.Ы. Вообще с LOCK TABLES все было очень плохо, форум не мог при этом нормально работать, поэтому поначалу на время снятия дампа я вообще отключал работу форума, и выдавал что-то вроде "ведутся технические работы, подождите пару минут". Потом сделал механизм, когда при снятии бэкапа выставляется флаг, форум смотрит наличие этого флага, и не пропускает UPDATE, INSERT, REPLACE для значимых вещей (добавление поста, регистрация юзера и т.п.) выдавая "подождите минутку", а для незначимых (изменение статуса "кто онлайн" и прочая не принципиальная муть) просто игнорирует такие запросы.
В результате во время снятия дампа форум прекрасно работал на чтение, 99.99% посетителей вообще ничего не замечали.
А сейчас и этот механизм не использую, таблицы в InnoDB, БД - MariaDB, все и так хорошо работает при снятии дампа без LOCK TABLES.
Это я просто делюсь опытом, может кому пригодится...

инкрементное бэкапирование БД?

Добавлено: 2018-01-29 4:21:54
FiL
при снятии большого дампа без lock tables дамп может оказаться нехорошим.
Пример. Начали дамп. Слили все посты. В это время кто-то сносит одну тему. И после этого дамп сливает таблицу с темами.
Потом при восстановлении у части постов не будет темы, к которой прицепиться. В зависимости от структуры это может дать ошибку восстановления.
Или обратная ситуация - и при восстановлениии тема будет, а постов в ней - нет.
Ну и так далее... В общем, лучше-бы всю базу лочить на время бакапа. И делать это на реплике.
Но это все зависит от того на сколько это все важно. Может оно вообще пофик. не бабло в банке.

инкрементное бэкапирование БД?

Добавлено: 2018-01-30 12:41:42
tull
FiL писал(а):Пример. Начали дамп. Слили все посты. В это время кто-то сносит одну тему. И после этого дамп сливает таблицу с темами.
Ничего страшного не произойдет. У меня давно сделано, что ничего никогда не удаляется, вместо этого посту ставится флаг "del". Аналогично с личкой.
Я не могу вспомнить ни одного действия, которое может произвести юзер, в результате которого удалится какая-то запись из БД...
Админ (не модер!) теоретически может выполнить полное удаление юзера или что-то подобное, но этим никто не пользуется, тем более в 3 утра, когда снимается бэкап. Хотя можно сделать защиту от этого: когда выставлен флаг снятия дампа, отключаются админские ф-ии.

FiL писал(а):Но это все зависит от того на сколько это все важно. Может оно вообще пофик. не бабло в банке.
Если пропадет 1-2 поста, этого вообще не заметят. Если пропадут посты за несколько часов, народ побузит, повозмущается, и успокоится к следующему дню.


Еще про бинлоги хотел спросить. Я сейчас сделал так: перед началом снятия дампа делается FLUSH LOGS, после чего начинается новый файл. А затем "PURGE BINARY LOGS BEFORE NOW()", очищая все старые.
Но проблема в том, что "PURGE BINARY LOGS" надо делать от root, а я не хочу прописывать в скрипте бэкапа пароль рута.
Можно вместо PURGE просто тупо удалять через rm все файлы mysql-bin.000XX, кроме последнего?