инкрементное бэкапирование БД?
Модератор: terminus
Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
-
- ефрейтор
- Сообщения: 51
- Зарегистрирован: 2008-02-23 19:02:38
инкрементное бэкапирование БД?
Имеется БД mysql где-то на 5 Гб.
По ночам делается полный бэкап, но очень хотелось бы еще делать промежуточные бэкапы каждый час или даже 20-30 минут.
Разумеется, хотелось бы сохранять абсолютно все изменения, произошедшие с момента полного бэкапа.
Что посоветуете?
Вообще это база данных форума. Основная часто обновляемая инфа это: собственно сообщения на форуме (самое важное), внутренняя почта, сами юзеры. Ну и еще по мелочи кое-что (правда этих мелочей таблиц на 15).
По идее для инкрементных бэкапов можно делать селекты из этих таблиц, для записей с временем изменения больше, чем время начала полного бэкапа. Правда, не для всех таблиц есть такое время, например в таблице юзеров есть только время добавления юзера, а не время его изменения. Но это либо можно прикрутить, либо вообще забить на это, т.к. изменения профиля юзера происходят довольно редко, и к тому же они не так существенны.
Но это получается довольно много возни и доработок.
Нет каких-то готовых решений, позволяющих реализовать грамотное инкрементное бэкапирование БД? (в которой не только появляются новые записи, но и иногда изменяются старые).
Да, на всякий случай: некоторые таблицы в InnoDB (сообщения, внутрення почта), некоторые в Myisam
БД на самом деле MariaDB 10.
По ночам делается полный бэкап, но очень хотелось бы еще делать промежуточные бэкапы каждый час или даже 20-30 минут.
Разумеется, хотелось бы сохранять абсолютно все изменения, произошедшие с момента полного бэкапа.
Что посоветуете?
Вообще это база данных форума. Основная часто обновляемая инфа это: собственно сообщения на форуме (самое важное), внутренняя почта, сами юзеры. Ну и еще по мелочи кое-что (правда этих мелочей таблиц на 15).
По идее для инкрементных бэкапов можно делать селекты из этих таблиц, для записей с временем изменения больше, чем время начала полного бэкапа. Правда, не для всех таблиц есть такое время, например в таблице юзеров есть только время добавления юзера, а не время его изменения. Но это либо можно прикрутить, либо вообще забить на это, т.к. изменения профиля юзера происходят довольно редко, и к тому же они не так существенны.
Но это получается довольно много возни и доработок.
Нет каких-то готовых решений, позволяющих реализовать грамотное инкрементное бэкапирование БД? (в которой не только появляются новые записи, но и иногда изменяются старые).
Да, на всякий случай: некоторые таблицы в InnoDB (сообщения, внутрення почта), некоторые в Myisam
БД на самом деле MariaDB 10.
Услуги хостинговой компании Host-Food.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/
Тарифы на виртуальные сервера (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/
-
- ст. лейтенант
- Сообщения: 1374
- Зарегистрирован: 2010-02-05 0:21:40
инкрементное бэкапирование БД?
на сколько я знаю - нет.
Но есть снапшоты на уровне сисемы и есть бинарные логи на уровне базы данных. Это не совсем то, что спрашивали, но задачу решает.
Но есть снапшоты на уровне сисемы и есть бинарные логи на уровне базы данных. Это не совсем то, что спрашивали, но задачу решает.
- Alex Keda
- стреляли...
- Сообщения: 35437
- Зарегистрирован: 2004-10-18 14:25:19
- Откуда: Made in USSR
- Контактная информация:
инкрементное бэкапирование БД?
я так понимаю, бэкап работе мешает? или какие показания к тому что не хочется делать его целиком?
поднимать репликацию, и бэкапить на другом сервере, снова целиком, с любой периодичностью.
поднимать репликацию, и бэкапить на другом сервере, снова целиком, с любой периодичностью.
Убей их всех! Бог потом рассортирует...
-
- ст. лейтенант
- Сообщения: 1374
- Зарегистрирован: 2010-02-05 0:21:40
инкрементное бэкапирование БД?
ну, если 5 гигов бакапить каждые 30 минут и держать хотя-бы месяц бакапов, то это набегает.
Собственно, даже если реплику в 5 гигов каждые пол часа бакапить, то ей может весьма грустно стать. А если база нагруженная, то и реплика будет нагруженная... А если оно вырастет до 50 гиг? Не, решать через реплику - это тупиковый путь.
Другое дело, что при наличии реплики может бакапы часто делать не надо будет, хватит раз в сутки. Это другое дело.
Собственно, даже если реплику в 5 гигов каждые пол часа бакапить, то ей может весьма грустно стать. А если база нагруженная, то и реплика будет нагруженная... А если оно вырастет до 50 гиг? Не, решать через реплику - это тупиковый путь.
Другое дело, что при наличии реплики может бакапы часто делать не надо будет, хватит раз в сутки. Это другое дело.
-
- ефрейтор
- Сообщения: 51
- Зарегистрирован: 2008-02-23 19:02:38
инкрементное бэкапирование БД?
Включил bin-log
Теперь когда делается бэкап, выполняю PURGE BINARY LOGS BEFORE NOW()
Только я чего-то не могу сообразить, это надо делать до, того как начал выполняться mysqldump, или когда он уже отработал?
Во время снятия дампа LOCK TABLES не делается, форум работает, т.е. могут происходить любые изменения, появляться новые записи
З.Ы. Вообще с LOCK TABLES все было очень плохо, форум не мог при этом нормально работать, поэтому поначалу на время снятия дампа я вообще отключал работу форума, и выдавал что-то вроде "ведутся технические работы, подождите пару минут". Потом сделал механизм, когда при снятии бэкапа выставляется флаг, форум смотрит наличие этого флага, и не пропускает UPDATE, INSERT, REPLACE для значимых вещей (добавление поста, регистрация юзера и т.п.) выдавая "подождите минутку", а для незначимых (изменение статуса "кто онлайн" и прочая не принципиальная муть) просто игнорирует такие запросы.
В результате во время снятия дампа форум прекрасно работал на чтение, 99.99% посетителей вообще ничего не замечали.
А сейчас и этот механизм не использую, таблицы в InnoDB, БД - MariaDB, все и так хорошо работает при снятии дампа без LOCK TABLES.
Это я просто делюсь опытом, может кому пригодится...
Теперь когда делается бэкап, выполняю PURGE BINARY LOGS BEFORE NOW()
Только я чего-то не могу сообразить, это надо делать до, того как начал выполняться mysqldump, или когда он уже отработал?
Во время снятия дампа LOCK TABLES не делается, форум работает, т.е. могут происходить любые изменения, появляться новые записи
З.Ы. Вообще с LOCK TABLES все было очень плохо, форум не мог при этом нормально работать, поэтому поначалу на время снятия дампа я вообще отключал работу форума, и выдавал что-то вроде "ведутся технические работы, подождите пару минут". Потом сделал механизм, когда при снятии бэкапа выставляется флаг, форум смотрит наличие этого флага, и не пропускает UPDATE, INSERT, REPLACE для значимых вещей (добавление поста, регистрация юзера и т.п.) выдавая "подождите минутку", а для незначимых (изменение статуса "кто онлайн" и прочая не принципиальная муть) просто игнорирует такие запросы.
В результате во время снятия дампа форум прекрасно работал на чтение, 99.99% посетителей вообще ничего не замечали.
А сейчас и этот механизм не использую, таблицы в InnoDB, БД - MariaDB, все и так хорошо работает при снятии дампа без LOCK TABLES.
Это я просто делюсь опытом, может кому пригодится...
-
- ст. лейтенант
- Сообщения: 1374
- Зарегистрирован: 2010-02-05 0:21:40
инкрементное бэкапирование БД?
при снятии большого дампа без lock tables дамп может оказаться нехорошим.
Пример. Начали дамп. Слили все посты. В это время кто-то сносит одну тему. И после этого дамп сливает таблицу с темами.
Потом при восстановлении у части постов не будет темы, к которой прицепиться. В зависимости от структуры это может дать ошибку восстановления.
Или обратная ситуация - и при восстановлениии тема будет, а постов в ней - нет.
Ну и так далее... В общем, лучше-бы всю базу лочить на время бакапа. И делать это на реплике.
Но это все зависит от того на сколько это все важно. Может оно вообще пофик. не бабло в банке.
Пример. Начали дамп. Слили все посты. В это время кто-то сносит одну тему. И после этого дамп сливает таблицу с темами.
Потом при восстановлении у части постов не будет темы, к которой прицепиться. В зависимости от структуры это может дать ошибку восстановления.
Или обратная ситуация - и при восстановлениии тема будет, а постов в ней - нет.
Ну и так далее... В общем, лучше-бы всю базу лочить на время бакапа. И делать это на реплике.
Но это все зависит от того на сколько это все важно. Может оно вообще пофик. не бабло в банке.
-
- ефрейтор
- Сообщения: 51
- Зарегистрирован: 2008-02-23 19:02:38
инкрементное бэкапирование БД?
Ничего страшного не произойдет. У меня давно сделано, что ничего никогда не удаляется, вместо этого посту ставится флаг "del". Аналогично с личкой.FiL писал(а):Пример. Начали дамп. Слили все посты. В это время кто-то сносит одну тему. И после этого дамп сливает таблицу с темами.
Я не могу вспомнить ни одного действия, которое может произвести юзер, в результате которого удалится какая-то запись из БД...
Админ (не модер!) теоретически может выполнить полное удаление юзера или что-то подобное, но этим никто не пользуется, тем более в 3 утра, когда снимается бэкап. Хотя можно сделать защиту от этого: когда выставлен флаг снятия дампа, отключаются админские ф-ии.
Если пропадет 1-2 поста, этого вообще не заметят. Если пропадут посты за несколько часов, народ побузит, повозмущается, и успокоится к следующему дню.FiL писал(а):Но это все зависит от того на сколько это все важно. Может оно вообще пофик. не бабло в банке.
Еще про бинлоги хотел спросить. Я сейчас сделал так: перед началом снятия дампа делается FLUSH LOGS, после чего начинается новый файл. А затем "PURGE BINARY LOGS BEFORE NOW()", очищая все старые.
Но проблема в том, что "PURGE BINARY LOGS" надо делать от root, а я не хочу прописывать в скрипте бэкапа пароль рута.
Можно вместо PURGE просто тупо удалять через rm все файлы mysql-bin.000XX, кроме последнего?
-
- рядовой
- Сообщения: 27
- Зарегистрирован: 2012-01-31 13:18:33
- Откуда: Россия
- Контактная информация:
инкрементное бэкапирование БД?
Перенесите проект на 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