Резервирование и копирование баз данных
Восстановление данных из архивов
Повреждение данных может происходить по самым разным причинам и значительно варьироваться по масштабам. В наилучшем случае поврежденными оказываются одна-две таблицы (например, если работа компьютера была внезапно завершена из-за отключения электричества). В наихудшем — придется восстанавливать весь каталог данных (например, если сломался и не подлежит ремонту жесткий диск). Восстановление данных может потребоваться и в некоторых других ситуациях, например, когда пользователи случайно удалят базы данных или таблицы либо сотрут их содержимое. Независимо от причин повреждения, администратору немедленно нужно выполнить процедуру восстановления.
Если таблицы не утеряны, а лишь повреждены, попытайтесь отладить их с помощью команд myisamchk и issamchk. Вполне вероятно, что проблему можно решить с их помощью, и необходимость в восстановлении файлов архивов отпадет. Процедура отладки таблиц описывается в лекции 4, ""Поддержка и восстановление баз данных"" . Если же таблицы потеряны или не подлежат отладке, самое время приступить к их восстановлению.
Для восстановления используются два источника информации: файлы архива и журналы обновлений. Первые позволяют восстановить таблицы до состояния, в котором они были в момент выполнения резервирования. Однако зачастую таблицы значительно изменяются пользователями между моментами резервирования и сбоя. В такой ситуации эффективными оказываются журналы обновлений, содержащие все последние запросы на внесение изменений. Чтобы восстановить все эти изменения, достаточно запустить запросы журнала обновлений в mysql. (Именно по этой причине администратор должен обязательно включить регистрацию обновлений. Если она не активизирована, немедленно включите ее, и прежде чем читать далее, создайте новый архив базы данных.) Процедура восстановления может видоизменяться в зависимости от объема информации, подлежащей воссозданию. Фактически, легче восстановить всю базу данных, чем одну таблицу, поскольку в журнал обновлений заносятся запросы на изменение именно баз данных, а не таблицы.
Восстановление базы данных
Сначала, если речь идет о восстановлении базы данных mysql с таблицами разрешений, необходимо запустить сервер с опцией —skip-grant-tables. Иначе сервер выдаст сообщение о невозможности поиска таблиц разрешений. После восстановления таблиц разрешений выполните команду mysqladmin flush-privileges, чтобы заставить сервер загрузить и использовать таблицы разрешений.
-
Скопируйте содержимое каталога базы данных в другое место. Оно может потребоваться в будущем для изучения оставшихся данных поврежденных таблиц.
-
Загрузите базу данных, используя файлы самых последних архивов. Если эти файлы были созданы программой mysqldump, используйте их в качестве ввода в mysql. Если же восстановление информации выполняется из файлов, непосредственно скопированных из каталога базы данных (например, с помощью команд tar или ср ), скопируйте их обратно в каталог данных. В последнем случае перед копированием файлов необходимо временно приостановить работу сервера, а по завершении переноса — снова запустить.
-
Используя журналы обновлений, повторно запустите все запросы на изменение базы данных, которые были исполнены с момента последнего резервирования. Для этого содержимое журнала обновлений можно представить в качестве ввода для mysql. Если необходимо, определите опцию —one-database, чтобы сервер mysql исполнил запросы только к той базе данных, которая представляет интерес. Если для восстановления информации необходимо использовать все журналы обновлений, запустите в каталоге с этими журналами следующую команду:
%ls -t -r -l update.[0-9]*|xargs cat|mysq| —one-database db_name
Команда Is воспроизводит список файлов журналов обновлений, отсортированный сервером в порядке создания. (Об этом следует помнить, поскольку неаккуратное изменение имен файлов журналов может привести к восстановлению их запросов в неправильном порядке.)
В большинстве же случаев используются не все, а только часть журналов обновлений. Например, если запросы к базе данных, выполненные после последнего резервирования, хранятся в файлах с именами update.392, update.393 и т.д., повторно запустить их можно с помощью следующих команд:
% mysql —one-database db_name < update.392 % mysql -one-database db_name < update.393
Если процедура восстановления применяется для устранения результатов случайного выполнения операторов DROP database, drop table или delete, не забудьте перед запуском команды удалить эти операторы из журнала!
Восстановление отдельных таблиц
Восстанавливать отдельные таблицы сложней. Если для восстановления применяется файл архива, созданный утилитой mysqldump и содержащий данные для множества таблиц, администратору придется извлечь из него строки, соответствующие требуемой таблице, и использовать их в качестве ввода для mysql. Это самая легкая часть процедуры восстановления. После нее необходимо из журнала обновлений извлечь записи, соответствующие требуемой таблице. Для выполнения этой процедуры весьма полезной может оказаться утилита mysqlfindrows, возможности которой позволяют извлекать многострочные запросы из журнала обновлений. Еще один вариант — восстановить всю базу данных на другом сервере, а затем скопировать нужную таблицу в исходную базу данных. Эта процедура гораздо проще! Необходимо лишь убедиться, что работа сервера с исходной базой данных приостановлена в процессе копирования файлов в исходную базу.