MySQL. Библиотека профессионала - Аткинсон Л

УСТРАНЕНИЕ

ПОСЛЕДСТВИЙ

КАТАСТРОФ

этой

•Проверка и восстановление таблиц

•Резервное копирование и восстановление

этой главе рассказывается о том, как предотвратить катастрофу и как устранить ее последствия, если все же случилось непоправимое. Рассматриваются вопро сы поиска повреждений в таблицах и их а также методы соз

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

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

Проверкаивосстановлениетаблиц

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

Существуют два способа проверки и восстановления таблиц. Первый из с помощью специальных инструкций, второй — с помощью утилиты Соот ветствующие инструкции называются CHECK TABLE, REPAIR TABLE и OPTIMIZE TABLE (см. главу 13, "Инструкции SQL"). Они достаточно удобны, поскольку выпол няются в рамках серверного процесса. В этом смысле они ничем не отличаются, к примеру, от инструкции SELECT. Утилита myisamchk обладает рядом дополнитель ных возможностей, которые в ряде ситуаций оказываются весьма удобными. Она бы ла описана в главе 14, "Утилиты командной строки".

454 Глава 25. Устранение последствий катастроф

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

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

при запуске сервера выполнялись инструкции проверки таблиц. Файл, содержащий такие инструкции, задается с помощью опции Если повреждения про изошли из за того, то сервер внезапно прекратил работу, они будут немедленно ис правлены.

Обработчики таблиц, для которых поддерживаются транзакции, содержат код, по зволяющий им восстанавливать таблицы на основании журнальных файлов при запуске сервера. На моментнаписания книги в MySQL не было средств ручной проверки и вос становления таблиц этих типов. MySQL добавят соответствующие функ ции позднее. А пока что, если возникает сомнение в целостности таблицы, необходимо остановить и повторно запустить сервер, хоть это и очень неуклюжий прием.

образом помечаются также неправильно закрытые таблицы. Чтобы проверить только их, укажите флаг FAST (инструкция CHECK TABLE) или опцию (утилита myisamchk).

По умолчанию утилита myisamchk ищет повреждения только в индексных фай лах. В инструкции CHECK TABLE этот режим включается с помощью флага QUICK. Са ма инструкция CHECK TABLE по умолчанию проверяет не только индексы, но и не правильные ссылки на удаленные записи. В утилите myisamchk этот режим включа

Табличные проверки занимают много времени в случае крупных таблиц, особенно если у них много ключей. Стандартные режимы проверки в обоих методах обеспечи вают вполне приемлемую производительность. Более быстрые проверки удобны, ко гда их нужно запускать регулярно, например по ночам. Расширенные проверки при ходят на помощь, если повреждение таблицы очевидно, но обычные проверки его все равно не находят.

Блистинге 25.1 иллюстрируется процедура проверки и восстановления таблицы.

Вданном случае я создал небольшую таблицу и сымитировал в ней повреждение, от редактировав табличные файлы в редакторе Как видите, таблицу удалось восста новить.

Проверка и восстановление таблиц 455

Таблицы можно проверять, когда сервер запущен. Программа MySQL не будет таться их восстановить. Но если обнаруживается поврежденная таблица, программа запрещает потокам обращаться к ней до тех пор, пока таблица не будет восстановле на. Для восстановления требуется получить монопольный доступ к таблице. В этой ситуации служебными инструкциями пользоваться удобнее, чем утилитой так как MySQL сможет заблокировать другие потоки на время восстановления таблицы. Утилита может работать таким образом, только если операци онная система поддерживает блокировку файлов. В Linux соответствующих функций нет, поэтому перед восстановлением таблиц нужно останавливать сервер.

Инструкция REPAIR TABLE устраняет повреждения в таблице. То же самое делает утилита myisamchk при наличии опции Программа MySQL поддержива ет три типа процедур восстановления: быстрая, обычная и безопасная. В первом слу чае устраняются лишь проблемы с индексами. Во втором случае исправляется также большинство ошибок в табличном файле. В безопасном режиме таблица проверяется строка за строкой, а индексный файл создается заново. Это наиболее длительная процедура.

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

Таблицы с записями переменной длины неизбежно оказываются Это происходит, когда обновляемая запись не помещается в отведенном для нее пространстве. В результате снижается производительность операций выбор ки, поскольку программа вынуждена искать запись в двух и более точках файла. Инст рукция TABLE удаляет из таблицы пустые участки и осуществляет пересор тировку записей. Аналогичные действия выполняет утилита myisamchk при наличии

456 Глава 25. Устранение последствий катастроф

Резервное копирование и восстановление

Резервная копия — это образ базы данных в конкретный момент времени. К этому образу можно вернуться в случае непредвиденной потери данных. Резервные копии можно создавать сколь угодно часто. Нужно лишь помнить о том, что это достаточно трудоемкий процесс, продолжительность которого зависит от размера базы данных и скоростных характеристик оборудования. В схеме репликации, которая описана в главе 29, "Распределенные базы данных", резервные копии создаются практически мгновенно.

Создание резервных копий требует от сервера значительных затрат ресурсов, вплоть до того, что работать с другими базами данных станет невозможно. Нужно спланировать этот процесс таким образом, чтобы он приходился на периоды мини мальной загруженности сервера. Если используется репликация, то резервные копии лучше создавать на подчиненном сервере.

Если резервная копия была создана в полночь, а сбой базы данных произошел в пол день, половина дневных изменений окажется утерянной. Тем ценнее значимость ичного журнала, о котором рассказывалось в главе 24, "Физическое хранение данных". В нем фиксируются все изменения базы данных. С помощью утилиты можно преобразовать содержимое этого файла в запросы к базе дан ных, которые позволят воссоздать ее состояние на момент сбоя. Таким образом, плани руя схему резервного копирования, не забудьте учесть ротацию и архивирование ичных журналов, чтобы они были си нхронизированы с копиями базы данных.

Помните общие правила обращения с резервными копиями. Если они хранятся в той же файловой системе, что и сама база данных, то данные не защищены от сбоев файловой системы. Отсюда правило: копии должны находиться на отдельном носи теле. Храните их на перезаписываемом магнитной ленте или другом жестком диске. Резервные копии могут храниться дома у начальника или администра тора компании. Их можно также пересылать по сети в другую систему. Сегодня, в эпоху Internet, это делать не сложно.

Впроцессе планирования необходимо предусмотреть тестирование копий и про верку возможности их восстановления на практике. Не ждите, пока случится катаст рофа и вам придется учиться восстанавливать архивы. Создайте тестовую среду и по тренируйтесь на ней. Можно попробовать восстановить архив во временную пустую базу данных или же воспользоваться более сложной методикой, например запустить еще один сервер MySQL на другом порту либо на другом компьютере.

ВMySQL существуют три основных способа архивирования данных. Первый — это

копирование табличных файлов, второй — создание SQL образов таблиц, третий — создание форматированных текстовых файлов. Первый способ является самым эко номным и быстродействующим. Но для таблиц тех типов, которые поддерживают транзакции, последние дваспособа являются более гибкими. Например, все таблицы хранятся в группе больших файлов, поэтому архивы нельзя будет сгруппиро вать по базам данных или таблицам.

Какой бы метод ни был выбран, не забудьте защитить таблицы от изменений на время резервного копирования. Если копируются табличные файлы, следует вить сервер. В остальных случаях достаточно поставить блокировки чтения с помо

щью инструкций LOCK TABLES и выполнить инструкцию FLUSH TABLES. Последняя необходима для того, чтобы все изменения индексов были записаны в таблицы. На

458 Глава 25. Устранение последствий катастроф

дать с помощью инструкции REPAIR TABLE. Предположим, таблица dictionary бы ла полностью утеряна. Процесс ее восстановления начнем с копирования обратно в каталог базы данных. Создать пустые файлы данных и индексов можно с помощью инструкции TRUNCATE TABLE. Затем необходимо скопировать старый файл данных поверх нового. После этого вводится инструкция REPAIR TABLE. В листин ге 25.4 показано, как программа MySQL обнаруживает расхождение в количестве за писей и перестраивает индексы.

mysql> REPAIR dictionary;

2 rows in set (1 23.41 sec)

Для безопасного создания резервных копий лучше пользоваться специальной про граммой, чем делать всевручную. С этой целью в дистрибутив MySQL входит Perl сценарий В листинге 25.5показано, как с его помощью создаются ко пии таблиц привилегий. Команда позволяет убедиться, что все файлы, в том числе индексные, наместе.

mysqlhotcopy /trap/he

6 tables in 0 seconds.

Flushed tables

in 0 seconds. Copying 18

Copying indices for 0 Unlocked tables.

mysqlhotcopy copied 6 tables (18 files) in 1 second (1 seconds

Параметры сценария mysqlhotcopy описывались в главе 14, "Утилиты командной строки". Он блокирует одновременно все таблицы базы данных, после чего очищает табличные буферы и копирует файлы. Сценарий можно запускать во время работы сервера, даже если в этот момент пользователи делают запросы к базе данных. Есте ственно, пока происходит копирование таблиц, пользователям будет запрещено вно сить в них изменения.

Формат табличных файлов понятен только программе MySQL. Если же создать SQL образы таблиц, то их можно будет перенести в другие СУБД. Кроме того, в неко торых ситуациях полезно просматривать такие SQL инструкции. Предположим, к

Резервное копирование и восстановление 459

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

Для создания таблицы предназначена утилита Она запи сывает текст инструкций в поток поэтому нужно перенаправить результаты ее работы в файл. Параметры этой утилиты были описаны в главе 14, "Утилиты мандной строки". В листинге 25.6 показан созданный этой утилитой образ таблицы

из базы данных Утилита была запущена с опцией которая включает режим оптимальных установок.

MySQL dump

Server version

Table structure for table

LOCK TABLES db WRITE;

INSERT INTO db VALUES

460 Глава 25. Устранение последствий катастроф

UNLOCK TABLES;

He забудьте заблокировать все таблицы для чтения, прежде чем запускать утилиту В противном случае целостность результатов не гарантируется. Предпо ложим, имеется приложение, которое хранит информацию о клиентах и их элек тронных адресах. Создание учетной записи нового клиента включает добавление за писи в таблицу и последующую вставку одной или нескольких записей в таб лицу email_address. Если параллельно с этим создавать резервную копию базы данных, то может оказаться, что в промежутке между созданием образов таблиц client и приложение попытается обновить обе эти таблицы. Дос туп к первой таблице будет запрещен, а ко второй — нет. В результате в архиве поя вятся адреса, не соответствующие ни одной записи таблицы клиентов.

Чтобы восстановить данные из такого архива, достаточно выполнить SQL сценарий в интерпретаторе Можно просто перенаправить сценарий на вход этой утилиты или же воспользоваться ее командой source. Интерпретатор выполнит все инструкции сценария так, как если бы они быливведены в командной строке.

Утилита mysqldump имеет режим создания текстового образа таблицы. В этом режиме для каждой архивируемой таблицы создаются два файла. Один из них имеет расширение и содержит соответствующую инструкцию CREATE TABLE. Второй файл имеет расширение и содержит записи таблицы, причем для разделения полей применяются символы табуляции. В листинге 25.7 показана команда, создаю щая текстовый образ таблицы dictionary в каталоге

Sending SELECT

Disconnecting from

Для восстановления данных из такого архива необходимо сначала создать табли цу, а затем выполнить инструкцию LOAD DATA INFILE, которая вставит записи в таблицу. Стандартный формат файла, создаваемого утилитой mysqldump, соответст вует тому формату, который по умолчанию распознается инструкцией LOAD DATA INFILE. В листинге 25.8 демонстрируется загрузка данных в таблицу dictionary в среде mysql.

Резервное копирование и восстановление 461

LOAD DATA

INTO TABLE dictionary;

Query OK, 104237 rows affected (1 27.70 sec)

Records: 104237 Deleted: 0 Skipped: 0 Warnings: 0

Создать файл, понимаемый инструкцией LOAD DATA INFILE, позволяет также инструкция SELECT с предложением INTO (листинг 25.9). Схему таблицы необходимо получить другим путем, например с помощью инструкции SHOW CREATE TABLE.

mysql> SELECT *

FROM dictionary INTO

Query OK, 104237 rows affected (6.42 sec)

Один из способов восстановления таблиц заключается в использовании двоичного журнала. Достаточно преобразовать его содержимое в SQL инструкции и выполнить их. Предварительно необходимо заблокировать все таблицы для записи или отклю чить всех клиентов от сервера. Преобразование двоичного журнала осуществляется с помощью утилиты (листинг 25.10). Результаты ее работы нужно напра вить в файл или интерпретатору Обратите внимание: инструкция SET меняет метку текущего времени сеанса, чтобы дата создания таблицы осталась неизменной.