Ключ к безопасному управлению базой данных делает регулярные резервные копии. В зависимости от Вашего объема данных, числа серверов MySQL, и рабочей нагрузки базы данных, можно использовать эти методы, одни или в комбинации: горячее резервное копирование с Резервным копированием MySQL Enterprise; холодное резервное копирование, копируя файлы, в то время как сервер MySQL выключен; физическое резервное копирование для быстрой работы (специально для восстановления); логическое резервное копирование с mysqldump для меньших объемов данных или записывать структуру объектов схемы.

Горячие Резервные копии

mysqlbackup команда, часть Резервного компонента MySQL Enterprise, позволяет Вам поддерживать рабочий экземпляр MySQL, включая InnoDB и MyISAM таблицы, с минимальным разрушением к операциям, производя непротиворечивый снимок базы данных. Когда mysqlbackup копирует InnoDB таблицы, чтения и записи обоим InnoDB и MyISAM таблицы могут продолжаться. Во время копирования MyISAM таблицы, чтения (но не записи) к тем таблицам разрешаются. Резервное копирование MySQL Enterprise может также создать сжатые файлы резервных копий, и поддержать подмножества таблиц и баз данных. В соединении с двоичным журналом MySQL пользователи могут выполнить восстановление момента времени. Резервное копирование MySQL Enterprise является частью подписки MySQL Enterprise. Для получения дополнительной информации см. Раздел 23.2, "Резервное копирование MySQL Enterprise".

Холодные Резервные копии

Если можно завершить работу своего сервера MySQL, можно сделать двоичное резервное копирование, которое состоит из всех файлов, используемых InnoDB управлять его таблицами. Используйте следующую процедуру:

Альтернативные Типы резервирования

В дополнение к созданию двоичных резервных копий как только описано, регулярно делайте дампы своих таблиц с mysqldump. Двоичный файл мог бы быть поврежден без Вас замечающий это. Выведенные таблицы сохранены в текстовые файлы, которые удобочитаемы, настолько определяющее табличное повреждение становится легче. Кроме того, потому что формат более прост, шанс для серьезного повреждения данных меньше. у mysqldump также есть a --single-transaction опция для того, чтобы сделать непротиворечивый снимок без блокировки других клиентов. См. Раздел 7.3.1, "Устанавливая Резервную Политику".

Репликация работает с InnoDB таблицы, таким образом, можно использовать возможности репликации MySQL сохранить копию Вашей базы данных на сайтах базы данных, требующих высокой доступности.

Выполнение Восстановления

Восстановить Ваш InnoDB база данных к подарку со времени, в которое было сделано двоичное резервное копирование, следует выполнить свой сервер MySQL с двоичным включенным журналированием, даже прежде, чем взять резервное копирование. Чтобы достигнуть восстановления момента времени после восстановления резервного копирования, можно применить изменения от двоичного журнала, который произошел после того, как резервное копирование было сделано. См. Раздел 7.5, "Момент времени (Инкрементное) Восстановление Используя Двоичный Журнал".

Чтобы восстановиться с катастрофического отказа Вашего сервера MySQL, единственное требование должно перезапустить это. InnoDB автоматически проверяет журналы и выполняет откат вперёд базы данных к подарку. InnoDB автоматически откатывает незафиксированные транзакции, которые присутствовали во время катастрофического отказа. Во время восстановления, mysqld дисплеи выводит что-то вроде этого:

InnoDB: Database was not shut down normally.InnoDB: Starting recovery from log files...InnoDB: Starting log scan based on checkpoint atInnoDB: log sequence number 0 13674004InnoDB: Doing recovery: scanned up to log sequence number 0 13739520InnoDB: Doing recovery: scanned up to log sequence number 0 13805056InnoDB: Doing recovery: scanned up to log sequence number 0 13870592InnoDB: Doing recovery: scanned up to log sequence number 0 13936128...InnoDB: Doing recovery: scanned up to log sequence number 0 20555264InnoDB: Doing recovery: scanned up to log sequence number 0 20620800InnoDB: Doing recovery: scanned up to log sequence number 0 20664692InnoDB: 1 uncommitted transaction(s) which must be rolled backInnoDB: Starting rollback of uncommitted transactionsInnoDB: Rolling back trx no 16745InnoDB: Rolling back of trx no 16745 completedInnoDB: Rollback of uncommitted transactions completedInnoDB: Starting an apply batch of log records to the database...InnoDB: Apply batch completedInnoDB: Startedmysqld: ready for connections

Если Ваша база данных становится поврежденной, или отказ диска происходит, следует выполнить восстановление, используя резервное копирование. В случае повреждения сначала найдите резервное копирование, которое не повреждается. После восстановления основного резервного копирования сделайте восстановление момента времени после двоичных файлов журнала, используя mysqlbinlog и mysql, чтобы восстановить изменения, которые произошли после того, как резервное копирование было сделано.

В некоторых случаях повреждения базы данных, это достаточно только, чтобы вывести, отбросить, и воссоздать одну или несколько поврежденных таблиц. Можно использовать CHECK TABLE SQL-оператор, чтобы проверить, повреждена ли таблица, хотя CHECK TABLE естественно не может обнаружить каждый возможный вид повреждения. Можно использовать Монитор Табличной области, чтобы проверить целостность управления файловым пространством в файлах табличной области.

В некоторых случаях очевидное повреждение страницы базы данных происходит фактически из-за операционной системы, повреждающей ее собственный кэш файла, и данные на диске могут быть хорошо. Это является лучше всего первым, чтобы попытаться перезапустить Ваш компьютер. Выполнение так может устранить ошибки, которые, казалось, были повреждением страницы базы данных. Если MySQL все еще испытывает затруднения, запускаясь из-за InnoDB проблемы непротиворечивости, см. Раздел 14.2.4.6, "Запускаясь InnoDB на Поврежденной Базе данных" для шагов, чтобы запустить экземпляр в диагностическом режиме, где можно вывести данные.