Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump

[[Red Dragon]]

[drakola]

а как сделать что бы база авт сохранялось например каждый 1час

[ZhukV]

а как сделать что бы база авт сохранялось например каждый 1час

Нужно использовать cron
Если Линукс, то должен быть здесь -- /etc/crontab
Если Виндовс, то там есть служба автозапуска

Относительно бекапов, я использую backup-manager for linux. Проблем с конфигами нет совсем! Отлично бекапит как всю БД, так и может бекапить ФС. Огромний плюс в том, что после бекапа она может заливать весь бекап на другой либо по ФТП либо по ССШ + еще много разных фич.

[TieLay]

Мне кстати всегда было интересно: при подаче команды на полный дамп БД умеет ли MySQL Demon отслеживать изменения в базе, с момента начала отдачи первого элемента и до окончания самого процесса с последующей отдачей накопившихся изменений.
К примеру:
- живой сервер онлайн на 10-20 человек, которые активно бегают бьют МОБ'ов, крафтят дуэлятся и прочее к тому же и сам сервер периодически скидывает кэш и оно приходится как раз на середину процесса копирования.
- запускаем снятие дампа
- операция длится 10 минут
- за эти 10 минут происходят изменения как в ещё не сохрянённых таблицах так и в уже сохрянённых
- как ведёт себя MySQL и таком случает?
- Можно ли дать команду javaServer - скинуть кэш и следом запустить создание дампа?
Вот Oracle, вроде, умеет по началу создания резервной копии открывать буфер и все операции по записи в базу складывает в него до окончания бэкапа или до достижения определённой наполненности буфера, а в 10й версии, вроде, может отслеживает какие из сохранённых в буфере запросов на запись можно применить т.к. эти таблицы уже сохранены и соответственно накладывает на базу в процессе.
Что имеем по итогу - действительный снимок базы на начало выполнения резервного копирования, а не винегрет из таблиц частично от начала резервирования и частично от изменённых в процессе записи.
З.Ы. Может кто просветит неуча, как с этим в MySQL?

[ZhukV]

На мой взляд нет.
Даже по логике действий МуСКЛ...
Любой дампер начинает считывать сначала БД, после того, переходит каждую БД и достает все таблицы и т.д. по цепочке.
Припустим есть две БД -- бд1, бд2, у нех есть куча таблиц.
Сначала читает бд1. Прочитал, создал бекап. Читает бд2. На это время, все, что будет подано в бд1, не будет в бекапе, поскольку бекап уже создан. Также происходит из таблицами.

Если нужно бекапить все бд, то лучше делать это крном, где-то в часом 5 утра, когда онлайна на сервере будет очень мало, и потери будут незначительные, тем более, лучше делать бекап прямо на сервере!!! Из-за того, что если делать с удаленного хоста, то огромные БД будут очень долго бекапится.
Был собственный пример.
На серве БД -- 148 МБ.
Друг бекапил из своего компа, зайняло приблизительно -- 10 мин.
Я бекапил при помощи -- backup-manager, и минуты не зайняло.

Добавлено через 11 часов 28 минут
Да, еще один совет.

В любой БД есть множество таблиц, записи которых давно уже не используются!!!
Желательно после бекапа производить чистку таблиц, чтобы они не засорялись и на время следующего бекапа не были по 1 Гб.
Сделать можно просто (только алгоритм):
1. Делаем бекап.
2. Проверям БД собственными скриптами, поскольку автоматизировать такой процес под всех не возможно. Припустим если у нас запись уже не будет использоватся, и она там стоит уже 1 месяц, так нах она.
3. Варианта два - Удаляем запись, либо переносим в резервное хранилище (таже копия БД, то в ней сохраняются старые записи)

В результате, старые записи будет удалены из активной БД, что ускорит работу БД + уменьшит нагрузку при более сложных запросах + в любой момент Вы сможете востоновить то или инное поле с резервной БД.

На заметку:
Если на сервере БД используются сложные запросы, то тогда нужно проставлять индексы в таблицах, что достаточно ускорит поиск. Дело в том, что если установлен первичный индекс, то при поиске [WHERE], если искомое поле совпадает с названием индекса, первоначально проверяются индексы, а аж потом вся таблица.
Для элементарного примера:
Некая таблица
id, iw, im
11 12 13
21 22 23
31 32 33
41 42 43

Предположим, что индекса нет, то при запросе типа -- SELECT * FROM table WHERE id=41 -- буду проверятся все ячейки по порядку (11 - 12 - 13 - 21 - 22 - 23 ...). А если записей милион, и полей 100?
Предположим, что индекс -- id. При таком же запросе, сначала проверится поле индекса так же по порядку (11 - 21 - 31 - 41), а потом, если уже не найдет, начнет искать далее.
--------------
ПРИ УСЛОВИИ, ЧТО ЕСТЬ НЕСКОЛЬКО ВЫБОРОК
--------------
Также следует знать, что есть замечательная фича, как Views.
Припустим в запросе Вы очень часто юзаете LEFT JOIN | RIGHT JOIN, либо делаете груповые запросы. Такие запросы дают нагрузку на серв, и иногда даже фатальную.
Виход. Создать вюшку (в инете есть документации), а потом обращатся к вюшке как к обычной таблице -- SELECT * FROM name_view WHERE `field` = '123123';
Когда вюшка создается она проверяет таблицы, достает результаты и формирует вюшку. Данные вюшки летят в кеш. После, при запросе, все берется с кеша, а не а активным таблицам. Также при создании вюшки создаються типа тригеры (в МуСКЛ они тоже есть, но не то) на редактирование таблиц, которые принадлежат вюшке. В результате, при редактировании одной из таблиц, кеш немного перезапишется (именно то что было поправлено).
Результат: При более сложных запросах и при их ОГРОМНОМ количестве, можно снизить нагрузку БД в 2, а то и более раз.

P.S.
С БД нужно быть немного острожным, поскольку на ней держится все -- сервер, сайт, фтп, квоты и т.д (кто что придумает). И если впадет мускула, можно сказать, УПАЛО ВСЕ!!!