Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

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

..pdf
Скачиваний:
166
Добавлен:
24.05.2014
Размер:
10.41 Mб
Скачать

432 Глава 23. Администрирование баз данных

Подготовкаккатастрофе

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

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

Не забудьте протестировать средства восстановления данных. Инсталлируйте MySQL в другой системе и восстановите резервную копию на "пустом месте". Регу лярно проверяйте архивы, чтобы защитить себя от неприятныхсюрпризов.

О создании резервных копий и восстановлении таблиц будет рассказываться в главе 25, "Устранение последствий катастроф".

Поддержка пользователей

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

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

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

Разработка и внедрение стандартов 433

Зная текущие потребности и работы пользователей, несложно пред сказать их будущие запросы. Продумайте заранее возможное расширение системы. Если база данных каждый день увеличивается на 100 Мбайт, очень скоро понадобится покупать новый жесткий диск или же сбрасывать старые данные в архив. Довольно часто происходят изменения самой программы MySQL. Организуйте регулярное об новление версий программы. Разработчики MySQL всегда сообщают о том, насколько "стабилен" тот или иной выпуск, чтобы пользователи могли решить, стоит ли на него переходить. Следите за новыми возможностями программы, которые позволят повы сить эффективность работы с системой.

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

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

Разработка и внедрение стандартов

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

Как минимум, нужно стандартизировать процедуру доступа пользователей к базе данных. Желательно также описать правила именования таблиц и столбцов. Это

можно оформить в виде руководства по

пример которого приведен в прило

жении "Руководство по оформлению

 

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

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

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

ФИЗИЧЕСКОЕ

ХРАНЕНИЕ

ДАННЫХ

этой

Способ хранения таблиц и баз данных Выделенные разделы Типы таблиц Столбцы Блокировки таблиц Индексы Дескрипторы файлов Системная память Журнальные файлы

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

эффективных баз данных.

Способ хранения таблиц и баз данных

В MySQL таблице соответствует несколько файлов. Их имена совпадают с именем таблицы, а расширение определяет назначение файла. К примеру, файл с расшире нием содержит описание структуры таблицы. Что касается баз данных, то они являются подкаталогами основного каталога (по умолчанию это Имя подкаталога соответствует имени базы данных. Это означает, что имена баз данных и таблиц отвечают тем же требованиям, которые предъявляются к именам файлов в данной системе. Скажем, файловая система ext2 в Linux чувстви тельна к регистру символов, a FAT32 в Windows — нет.

Операционные системы налагают свои ограничения на максимальный размер файла. Обычно он составляет от 2 до 4 Гбайт. Для таблиц типа описываемо го ниже, все данные сохраняются в одном файле, следовательно, максимальный раз мер файла одновременно является максимальным размером таблицы.

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

436 Глава 24. Физическое хранение данных

Выделенные разделы

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

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

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

Типы таблиц

В MySQL версии 3.23.37 поддерживаютсясемь типов таблиц. Три из них — Gemini и —ориентированы на транзакции, а четыре — Heap, ISAM, Merge и — нет. Транзакции являются относительно новым понятием в MySQL, но ветствующие функции для таблиц Berkeley DB и InnoDB существуют уже достаточно давно, что позволило включить их в стандартные бинарные дистрибутивы. Подробнее об этом рассказывалось в главе 9, "Транзакции и параллельные вычисления".

Стандартным типом таблиц в MySQL является тип MylSAM. Он возник на основе более старого типа ISAM, который все еще существует, хотя использовать его не комендуется. Переопределить установку по умолчанию позволяет опция TYPE инст рукций CREATE TABLE и ALTER TABLE (см. главу 13, "Инструкции SQL").

DB

Проект Berkeley DB начался в Калифорнийскомуниверситете в Беркли. следствии его авторы сформировали компанию Software (www.sleepycat.com) и занялись распространением коммерческой версии СУБД. Многие утилиты до сих пор работают со старыми версиями (1.85 и 1.86), в то время как компания Sleepycat Software предлагает уже семейство версий 3.x и 4.x Эта СУБД свободно ся с исходными кодами, и ею можно пользоваться бесплатно, за исключением случаев, когда на ее основе планируется создавать приложения, не распространяемые на услови ях открытой лицензии.

Типытаблиц 437

BDB — это простая файловая СУБД, поддерживающая транзакции, но не распола гающая каким либо языком запросов. В MySQL эта СУБД нужна для того, чтобы мож но было работать с таблицами в режиме транзакций.

СWeb узла MySQL можно загрузить скомпилированную версию программы, в ко торую встроена поддержка BDB. Если впоследствии потребуется отключить эту под

держку, достаточно будет запустить демон с опцией На этапе компиляции MySQL поддержка BDB включается с помощью опции

Для MySQL нужна исправленная версия BDB, которая входит в исход ный дистрибутив MySQL.

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

Сфункциональной точки зрения таблицы BDB ведут себя аналогично таблицам

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

Сами транзакции реализуются посредством журнальных файлов, куда записыва ются сведения об изменении табличных данных. Когда происходит отмена транзак ции, функции библиотеки BDB читают журнальные файлы и делают "обратные" ис правления. Журнальные файлы носят именавида 0000000001 и располагаются в каталоге данных, хотя эту установку можно изменить с помощью опции указываемой при запуске сервера.

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

В BDB таблицы блокируются на уровне страниц. Страница — это совокупность по следовательно расположенных записей таблицы. Страничные блокировки необходи мы, когда MySQL сканирует таблицу, а также при удалении, вставке и обновлении за писей. В отличие от таблиц MylSAM, блокировки таблиц BDB могут приводить к воз никновению тупиков, т.е. взаимоблокировок. В подобной ситуации одна или несколько транзакций отменяется. Это следует учитывать при написании приложе ний. Инструкция, которая приводит к автоматической отмене транзакции, возвраща ет сообщение об ошибке. Транзакции отменяются также в случае нехватки места в файловой системе.

СУБД BDB не ведет подсчет записей в таблицах, но MySQL хранит собственный счетчик. Он используется модулем оптимизации объединений при выборе индексов. Значение счетчика может быть неточным, если произошел сбой базы данных, но счетчик можно сбросить с помощью инструкции ANALYZE TABLE или OPTIMIZE

TABLE. Ведение счетчика записей немного замедляет работу с таблицами BDB.

Табличные данные хранятся в виде двоичного дерева. Это более медленный ме тод, чем тот, который применяется для таблиц MylSAM. СУБД BDB оставляет в дере

438 Глава 24. Физическое хранение данных

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

В отличие от таблиц индексы в таблицах BDB не сжимаются, т.е. они за нимают больше места. Если в запросе участвуют столбцы одного индекса, обращение к табличным данным не так как в этом нет необходимости. С этой це лью BDB позволяет объединять первичный ключ со столбцами другого индекса (для таблиц MylSAM такая возможность не поддерживается).

Gemini

Функции работы с таблицами Gemini реализовали программисты компании (www.nusphere.com). Эта компания обеспечивает поддержку и обучение поль зователей MySQL. Бета тестирование таблиц Gemini началось в апреле 2001 г. и на момент написания книги ещепродолжалось.

В этих таблицах отсутствуют столбцы типа BLOB и TEXT. Количество

лей, которые могут одновременно работать с таблицами, по умолчанию равно 100. Данную установку можно изменить с помощью серверной переменной

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

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

Heap

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

Резидентные таблицы не располагают многими возможностями обычных таблиц. Они не могут иметь столбцы типа BLOB или TEXT. Нельзя использовать флаг AUTO_INCREMENT. Можно создавать индексы, но нельзя индексировать столбцы, до пускающие значения NULL. Индексы используются только в операциях и

Записи резидентных таблиц имеют фиксированную длину. Для столбцов типа VARCHAR сразу выделяется максимальное число байтов. Поскольку ограни ченный ресурс, можно задать предельное количество записей в резидентной таблице. Для этого предназначена опция инструкции CREATE TABLE. Серверная переменная задает максимальный объем памяти, занимаемой всеми резидентными таблицами.

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

Типы таблиц 439

СУБД InnoDB была разработана из компании финского производителя программного обеспечения, спе циализирующегося на технологии реляционных баз данных. InnoDB представляет собой исследований, проводимых Хейкки в университете Хельсинки. Под держка InnoDB появилась в MySQL версии 3.23.34а. Сама СУБД доступна на условиях открытой лицензии.

На Web узле InnoDB можно найти массу информации о деталях работы ядра этой СУБД. Ядро не существует само по себе, а является дополнением к MySQL. С Web узла MySQL можно загрузить скомпилированную версию программы, в которую встроена поддержка InnoDB. Если впоследствии потребуется отключить эту поддержку, доста точно будет запустить демон с опцией На этапе компиляции MySQL поддержка InnoDB включается с помощью опции Исходные коды InnoDB входят в исходный дистрибутив MySQL.

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

всоответствии с новыми установками файла. Журнальные фай лы InnoDB можно безопасно удалить после остановки сервера. При повторном запус ке сервера программа MySQL создаст журнальные файлы заново.

Влистинге 24.1 приведен пример опций, которые необходимо добавить в конфи

гурационный файл в группу чтобы активизировать таблицы InnoDB. Раз мер файлов здесь задан относительно небольшим, что вполне подходит для целей эксперимента. На практике используются файлы гораздо большего размера. Список опций и переменных демона mysqld был приведен в главе 14, "Утилиты командной строки".

innodb_data_home_dir

set variable

/disk2/innodb/log

set variable

set variable innodb_log_file_size=16M set variable

innodb_log_arch_dir /disk2/innodb/log innodb_log_archive=0

set variable

set variable

set variable innodb_file_io_threads=4

set variable lock wait

440 Глава 24. Физическое хранение данных

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

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

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

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

каталог таблиц, который не инструкцией DROP TABLE, этому каждую таблицу приходится удалять отдельно. Не разрешается индексировать префикс столбца, а также индексировать столбцы типа BLOB и TEXT. Максимальное количество столбцов в таблице— 1000. Флаг DELAYED в инструкции INSERT не под держивается.

ISAM

До версии 3.23 стандартным типом таблиц в MySQL был тип ISAM. Он необладает такими возможностями, как более новый тип поэтому в современных верси ях MySQL использовать его не рекомендуется.

Merge

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

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

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

Типы таблиц 441

Даже если дескрипторы индексных файлов совместно используются несколькими по

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

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

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

позволяющих манипулировать табличными файлами. Сюда

входят утилита

для проверки и восстановления таблиц и утилита

для созда

ния сжатых таблиц (см. главу 14, "Утилиты командной строки").

 

Таблицы MylSAM являются

Табличные файлы можно

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

MySQL хранит счетчик подключений к таблице MylSAM. Когда таблица закрыва ется, счетчик сбрасывается в нуль. Если сервер неожиданно завершает работу, чик остается положительным числом. В таком случае в процессе перезапуска сервер обнаружит проблему. Это не означает, что таблица повреждена, но подобная воз можность существует. Следует немедленно выполнить инструкцию CHECK TABLE или вызвать утилиту myisamchk. Можно также запустить демон с опцией чтобы заставить его восстанавливать все таблицы MylSAM с не нулевым значением счетчика.

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

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

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