резервное копирование большой базы данных с большим объемом данных за небольшой промежуток времени с последующим восстановлением за небольшой промежуток времени? [закрыто]
mylvmbackup является инструментом для того, чтобы быстро создать резервные копии MySQL файлы данных сервера. Для выполнения резервного копирования mylvmbackup получает чтение, соединяют все таблицы, и сбрасывает все кэши сервера к диску, создает снимок объема, содержащего каталог данных MySQL, и разблокировал таблицы снова. Процесс снимка берет только небольшое количество времени. Когда это сделано, сервер может продолжить нормальное функционирование, в то время как фактическое резервное копирование файлов продолжается.
-
1
Было бы хорошо знать то, что ОС мы имеем дело с, но предполагаем, что это - недавний дистрибутив Linux, Ваш лучший выбор будет использовать снимки LVM. Сеть полна соответствующих рецептов и инструментов, вот одна ссылка, которая перечисляет самые популярные:
Поместите базу данных по аппаратным средствам система RAID, которая позволяет зеркально отражать.
Для резервного копирования просто отключите зеркальное отражение. Это даст Вам две точных копии базы данных. Сохраните одно "живое". Выполните восстанавливание на другой одном (для чистки возможно непоследовательного состояния путем "выключения его") и затем обратно его. Можно не торопиться, так как живой DB все еще отвечает на запросы.
Позвольте зеркалу вытянуть в любых обновлениях, которые произошли, в то время как Вы сделали резервное копирование.
Для восстановления также отключите зеркало и восстановление в "мертвую" часть. После того, как восстановление закончилось, включите зеркало снова таким способом, которым "живая" база данных перезаписывается с восстановлением. У Вас будет несколько секунд времени простоя для сервера БД в этой точке, так как необходимо выключить "живой" DB и указать на сервер на восстановленный DB. Существует одна проблема для знания: Будут потеряны любые изменения, внесенные в живую базу данных. Обычно, это - совсем не проблема, хотя: необходимо сделать восстановление, потому что база данных повреждена.
Таким образом, у Вас или нет живой базы данных вообще, или необходимо выполнить его в состоянии "только для чтения" или чем-то. Если база данных не абсолютно повреждена, можно восстановить данные в третий и просто скопировать несколько таблиц, Вы нуждаетесь (или используете "мертвую" часть зеркала как пространство фрагмента).
Этот подход дает Вам наименее возможную сумму времени простоя.
-
1Но необходимо быть уверены, что состояние базы данных допустимо, чтобы быть скопированным, в то время как DB работает. – Martin Beckett 6 October 2009 в 16:27
-
2@mgb: That' s задание системы RAID. Это должно удостовериться, что две копии данных всегда являются тем же. Поэтому DB всегда находится в том же состоянии на обеих копиях. – Aaron Digulla 6 October 2009 в 18:34
-
3да, диски находятся в том же состоянии. но база данных не находится в СОГЛАСОВАННОМ СОСТОЯНИИ при использовании нетранзакционного механизма базы данных, такого как myisam. – longneck 6 October 2009 в 18:48
-
4@longneck: It' s последовательный в живой копии. В отдельной зеркальной копии необходимо выполнить восстанавливание, но начиная с этого doesn' t влияют на живую копию, клиенты won' t уведомление. Затем можно сделать резервное копирование. Это может занять время, но снова, живая копия isn' t затронутый. – Aaron Digulla 6 October 2009 в 18:59
-
5
если Вы хотите полную копию всего mysql экземпляра сервера с самым маленьким временем простоя с помощью только функции, существующие в mysql сервере, то сделайте следующее:
- отправьте ТАБЛИЦЫ СБРОСА С БЛОКИРОВКОЙ ЧТЕНИЯ, чтобы закрыть все дескрипторы таблицы и мешать новым быть созданными.
- сделайте копию всем mysql каталогом данных с помощью функций копии ОС или утилиты резервного копирования.
- отправьте РАЗБЛОКИРОВАЛИ ТАБЛИЦЫ.
при использовании файловой системы, которая поддерживает снимки объема, то можно заменить № 2 снимком вместо этого.
-
1
-
2Это будет хорошо работать с таблицами InnoDB, если Вы используете снимок файловой системы. – MarkR 6 October 2009 в 16:30
Используйте снимок файловой системы своего Innodb database*. Вы получите последовательную копию файлов на восстановлении, после того, как InnoDB закончил откатывать любые транзакции, которые происходили и т.д.
Для резервного копирования Вы должны будете:
- Возьмите снимок файловой системы ИЛИ если Ваша файловая система не поддерживает его, возьмите снимок блочного устройства
- При необходимости смонтируйте фс или снимок блочного устройства, позволяющий в течение некоторого времени ремонта файловой системы в случае необходимости (дб все еще будет онлайн в этой точке),
- Создайте резервную копию смонтированного снимка с помощью нормальных резервных инструментов
- Размонтируйте и/или удалите снимок по мере необходимости.
Для восстановления его закройте mysql, вытрите старые файлы данных, затем восстановите файлы в mysql каталог данных. При перезапуске mysql экземпляра он восстановится с любых транзакций, которые происходили во время резервного копирования (путем отката их), затем подходят обычно. Это может требовать времени, конечно.
*, конечно, у Вас будут некоторые таблицы MyISAM в "mysql" системной базе данных. Удостоверьтесь, что они не изменяются во время снимка.