MySQL. Библиотека профессионала - Аткинсон Л
..pdf432 Глава 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 Эта СУБД свободно ся с исходными кодами, и ею можно пользоваться бесплатно, за исключением случаев, когда на ее основе планируется создавать приложения, не распространяемые на услови ях открытой лицензии.
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. Серверная переменная задает максимальный объем памяти, занимаемой всеми резидентными таблицами.
Доступ к резидентным таблицам имеют все пользователи. Эти таблицы уничтожа ются при выключении сервера.
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 содержат данные, а с расширением схему таблицы. Если индексный файл по какой то причине теряется, программа перестраивает индексы, используя информацию из