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

MySQL/PostgreSQL/SQLite/Oracle/M$SQL/....

Модератор: terminus

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
tull
ефрейтор
Сообщения: 51
Зарегистрирован: 2008-02-23 19:02:38

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

Непрочитанное сообщение tull » 2018-01-21 17:17:30

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

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

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

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

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

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

Непрочитанное сообщение FiL » 2018-01-23 0:40:56

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

Аватара пользователя
Alex Keda
стреляли...
Сообщения: 35454
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

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

Непрочитанное сообщение Alex Keda » 2018-01-25 21:33:35

я так понимаю, бэкап работе мешает? или какие показания к тому что не хочется делать его целиком?
поднимать репликацию, и бэкапить на другом сервере, снова целиком, с любой периодичностью.
Убей их всех! Бог потом рассортирует...

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

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

Непрочитанное сообщение FiL » 2018-01-26 1:21:33

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

tull
ефрейтор
Сообщения: 51
Зарегистрирован: 2008-02-23 19:02:38

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

Непрочитанное сообщение tull » 2018-01-27 18:54:20

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

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

FiL
ст. лейтенант
Сообщения: 1374
Зарегистрирован: 2010-02-05 0:21:40

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

Непрочитанное сообщение FiL » 2018-01-29 4:21:54

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

tull
ефрейтор
Сообщения: 51
Зарегистрирован: 2008-02-23 19:02:38

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

Непрочитанное сообщение tull » 2018-01-30 12:41:42

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


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

beraleevg
рядовой
Сообщения: 27
Зарегистрирован: 2012-01-31 13:18:33
Откуда: Россия
Контактная информация:

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

Непрочитанное сообщение beraleevg » 2018-06-27 12:56:03

Перенесите проект на postgresql. Вероятнее всего движок форума поддерживает postgresql сервер для хранения информации. На postgresql есть механизм непрерывного копирования. Можно ещё утилиту использовать pg_probackup. До кучи при инициализации кластера добавьте опцию --data-checksums. Это позволит делать очень компактные резервные копии.

Код: Выделить всё

============================================================================================================================================
 Instance    Version  ID      Recovery time           Mode    WAL      Current/Parent TLI    Time    Data   Start LSN    Stop LSN    Status 
============================================================================================================================================
 1c-ts       9.6      PAZ4NK  2018-06-27 05:08:36-04  PAGE    STREAM     1 / 0               972s   186MB  41/3B000028  41/3C0000F0  OK      
 1c-ts       9.6      PAWUYS  2018-06-25 23:34:46-04  PAGE    STREAM     1 / 0               406s   138MB  41/25000028  41/26111320  OK      
 1c-ts       9.6      PAVOGP  2018-06-25 08:36:05-04  PAGE    STREAM     1 / 0              1566s   212MB  41/1F000028  41/21DA0158  OK      
 1c-ts       9.6      PAV14E  2018-06-24 23:46:14-04  PAGE    STREAM     1 / 0                31s   126MB  41/7000028   41/80000F0   OK      
 1c-ts       9.6      PAQ2H6  2018-06-22 07:52:35-04  FULL    STREAM     1 / 0              1538s    28GB  41/5000108   41/50002B0   OK