11. Облачные вычисления (Cloud computing)

Сегодня бурно начинают развиваться так называемые облачные вычисления (Cloud computing). Эта технология очень привлекательна для пользователей, т.к. они легко и недорого могут запросить через Интернет и получить во временное пользование некоторый сервис для хранения и обработки данных. Например, можно заказать компьютер с заданным объемом памяти, дисков, количеством процессоров, с предустановленными ОС и СУБД или другими пакетами ПО и работать с ним из своего офиса, хотя физически и оборудование, и ПО располагаются и обслуживаются в удаленном чужом ЦОД. Можно заказать нужный дисковый ресурс и хранить на нем свои файлы.

Примерами Cloud Computing являются сервисы хранения (Amazon S3), вычислительные сервисы (Google App Engine, Amazon EC2) и сервисы данных (Amazon SimpleDB, Microsoft SQL Server Data Services, Google’s Datastore).

СУБД должны уметь работать в такой среде и использовать эту среду (например, ее систему хранения) для создания и хранения файлов и backup. Работа в среде cloud computing предъявляет повышенные требования к СУБД с точки зрения защиты данных и разграничения доступа (ведь данные размещаются на чужих компьютерах), с точки зрения масштабируемости (декларируется, что пользователь сервиса может заказать машину большой мощности и с большим количеством процессоров). Поскольку управление системой идет через Интернет, да и вообще сам подход подразумевает минимальные усилия по управлению как инфраструктурой, так и самой СУБД, то очевидно понадобится еще больше совершенствовать средства администрирования и повысить самоуправляемость СУБД.

12. Машины баз данных

В последнее время широко развивается направление хранилищ данных. Поскольку объемы данных огромны (сотни терабайт) и продолжают расти, а специальные алгоритмы традиционных СУБД уже не могут обеспечить хорошее время отклика для задач анализа и построения корпоративной отчетности, появляются специальные вычислительные системы с массивно-параллельной архитектурой. Наиболее известным примером такой архитектуры является NCR/Teradata. Это сплав оборудования и специального ПО. Такие архитектуры позволяют распараллелить обработку данных и вынести часть обработки с уровня СУБД на уровень ячеек хранения, которые сами имеют свои небольшие компьютеры.

Обычно при росте объема БД узким местом становятся каналы передачи данных между сервером БД и устройствами хранения. Возможность увеличить количество и пропускную способность таких каналов, а также снизить объем передаваемых данных за счет выполнения части операций по просмотру и выборке данных на уровне ячеек хранения, позволяет снять проблему каналов передачи. Такая связка оборудования и специального ПО, называемая машина баз данных, давно описана в литературе. Примеры – Netezza, Datallegro, Teradata.

Но обычно такие машины баз данных использовали специальное ПО и требовали специальной квалификации для разработки приложений. Они не использовали широко распространенные универсальные СУБД, а универсальные СУБД не поддерживали такую архитектуру. Сейчас началось движение универсальных коммерческих СУБД в сторону машин баз данных. Первый коммерческий пример – совместная машина баз данных Oracle и HP с ячейками хранения Exadata. Она обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных в десятки раз (до 70 раз) без переписывания приложений.

Oracle–HP Database Machine представляет из себя единый преднастроенный компьютер (с ячейками Exadata и кластером БД). Очень важна для таких архитектур сбалансированность компонент, т.е. размера памяти, дисков, числа процессоров, скорости каналов ввода/вывода и т.д.

В том же направлении сейчас движется Microsoft, которая купила DATAllegro и интегрирует ее с MS SQL Server. Машина баз данных не только ускоряет обработку, но и упрощает разработку хранилищ данных, так как многим вопросам настройки СУБД, требовавшим создания индексов, материализованных представлений, секционирования таблиц и индексов, кластеризации данных и настройки областей памяти, ввода/вывода и т.д., теперь можно уделять меньше внимания. За счет очень высокой скорости и распараллеливания выполнения самых тяжелых операций СУБД – full scan, проекция и join, даже не очень хорошо спроектированная БД работает очень быстро. Так что, очевидно, вскоре все коммерческие СУБД, работающие в области хранилищ данных, станут работать в архитектуре машин баз данных.

1.5.5. Заключение

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

2. Эксплуатация баз данных

2.1. Настройка и администрирование СУБД

2.1.1. Администрирование MySQL

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

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

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

Обзор задач администрирования

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

Сервер MySQL. Сервер mysqld выполняет все операции с базами данных и таблицами. Для запуска сервера, мониторинга его работы и перезапуска в случае сбоя применяется программа safe_mysqld (демон)

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

mysql. Интерактивная программа, позволяющая отправлять SQL-запросы на сервер и просматривать результаты их выполнения.

mysqladmin. Административная программа, позволяющая выполнять такие операции, как завершение работы сервера, создание и удаление баз данных. Эту же программу можно применять для проверки состояния сервера, если что-то в его работе не так.

isamchk или myisamchk. Утилиты, предназначенные для анализа и оптимизации таблиц, а также восстановления их в случае повреждения.

mysqldump. Средство резервирования баз данных или их копирования на другой сервер.

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

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

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

Общее администрирование

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

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

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

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

Резервирование и копирование баз данных. Резервирование баз данных — исключительно важная операция, позволяющая в случае необходимости восстановить работу системы после сбоя. Желательно, конечно, чтобы имелась возможность восстановить базы данных до того состояния, в котором они находились перед сбоем. В этом случае потеря данных будет минимальной. Заметьте, однако, что резервирование баз данных отличается от резервирования информации всей системы, выполняемой, например, с помощью UNIX-программы dump. В процессе активной работы сервера файлы таблиц базы данных, как правило, подвергаются изменениям. Восстановление файлов, зарезервированных в какой-то определенный момент времени, не позволит в полной мере восстановить базу данных, т.е. потеря определенной части данных неизбежна. Более полезными для восстановления базы данных являются файлы, сгенерированные программой mysqldump. С ее помощью можно выполнять резервирование без предварительного завершения работы сервера.

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

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

Установка нескольких серверов. В некоторых случаях возникает необходимость в запуске сразу нескольких серверов. Она может определяться желанием протестировать работу новой версии MySQL перед полным переходом на нее или обеспечить более высокий уровень защиты для отдельных групп и пользователей. (Последний вариант, в частности, относится к провайдерам интернет-услуг.) В таких ситуациях администратор должен знать, как установить и настроить несколько одновременно работающих инсталляций.

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

Безопасность

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

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

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

Отладка и поддержка баз данных

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

Восстановление после сбоя. Сбой может разрушить результаты даже самых успешных действий, поэтому администратор должен обязательно знать, как отладить и восстановить таблицы баз данных. Восстановление после сбоя — это процесс, выполняемый весьма редко. Однако он очень неприятен и, как правило, сопровождается пребыванием администратора в стрессовом состоянии (которое может еще более усугубляться постоянными звонками и стуком в дверь.) Для восстановления применяются средства проверки и восстановления - isamchk и myisamchk. Необходимо обязательно научиться восстанавливать информацию из резервных файлов и использовать записи регистрационных журналов для восстановления всех изменений, внесенных с момента последнего резервирования.

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

Защита новой инсталляции MySQL

На этапе инсталляции MySQL необходимо обязательно установить пароль для MySQL-пользователя root, поскольку сразу после установки права сервера не защищены. Предполагается, что каталог данных и база данных mysql с таблицей разрешений уже инициализированы. На компьютерах с UNIX для их инициализации достаточно запустить сценарий mysql_install_db. На компьютерах, работающих под управлением Windows, каталог данных и база данных mysql инициализируются посредством запуска программы Setup в дистрибутиве сервера. Итак, каталог и основная база данных пронициализированы, и сервер запущен.

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

Авторизоваться в качестве основного пользователя root с локального компьютера можно без пароля. Пользователь root обладает всеми возможными правами (включая административные), может выполнять любые операции. (Кстати, совпадение имен суперпользователей MySQL и UNIX не является закономерностью Они никак друг на друга не влияют.)

Права анонимного доступа предоставляются всем пользователям, подключающимся с локального компьютера к базе данных test или любой другой базе данных, имя которой начинается со слова test. Анонимные пользователи могут выполнять любые операции с такими таблицами, но не обладают привилегиями администратора. Для подключения к серверу с локального компьютера можно определить как имя главного компьютера localhost, так и его реальное имя. Например, если сервер размещается на компьютере pitviper.snake.net, клиент этого компьютера может подключиться без пароля к серверу для работы с базой данных test с помощью одной из двух следующих команд:

% mysql -h localhost test

% mysql -h pit-viper.snake.net test

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

В версиях MySQL 3.22 и выше установить пароль можно с помощью команды mysqladmin. Для этого достаточно ввести следующую команду, заменив ее часть "my password" реальным паролем:

mysqladmin -u root password "my password"

Во всех остальных версиях MySQL для этих целей можно воспользоваться программой mysql и непосредственно обновить таблицу разрешений grant в базе данных mysql:

mysql> -u root mysql

mysql> UPDATE user SET Password=PASSWORD("my password") WHERE User="root";

Команда mysql и оператор update применяется в старых версиях MySQL, а также во всех бесплатно распространяемых версиях под Windows.

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

% mysqladmin -u root status

Если сервер все еще позволяет подключаться в качестве пользователя root без пароля, укажите ему перезагрузить таблицы, введя следующую команду:

% mysqladmin -u root reload

После определения пароля пользователя root (и перезагрузки таблиц разрешений) самое время приступать к определению нового пароля для администратора.

Настройка процедур запуска и завершения работы сервера MySQL

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

Запуск представленных команд

В большинстве примеров этой лекции такие программы, как mysqladmin, mysqldump и им подобные, для краткости представлены без опций -h, -u и -р. Предполагается, что пользователи будут правильно вызывать эти программы, используя в случае необходимости подключения к серверу соответствующие параметры.

В версии MySQL 3.22.11 и выше перезагрузить таблицы можно с помощью команды mysqladmin flush-privileges и SQL-оператора FLUSH PRIVILEGES.

Запуск сервера MySQL непривилегированным пользователем

Прежде чем приступить к рассмотрению процедуры запуска сервера, давайте обсудим, какие пользователи могут выполнить подобный запуск. Сервер может запускаться вручную или автоматически. В первом случае сервер запускается в качестве пользователя, под именем которого зарегистрирован администратор, запускающий сервер (или другой сотрудник). Другими словами, если администратор зарегистрирован под именем пользователя paul и запускает сервер, то сервер будет работать с правами пользователя paul. Если затем администратор с помощью команды su авторизуется в качестве пользователя root и запустит сервер, сервер будет работать с правами пользователя root.

Однако всегда запускать сервер вручную весьма неудобно. Лучше всего настроить его на автоматический запуск во время загрузки системы. На UNIX-компьютерах процедура запуска выполняется системой с помощью UNIX-пользователя root, соответственно, все процессы, запускаемые во время этой процедуры, работают впоследствии с привилегиями пользователя root.

Администратору следует помнить о двух целях, преследуемых при настройке процедуры запуска сервера MySQL.

Желательно, чтобы сервер не обладал привилегиями пользователя root. В большинстве случаев рекомендуется ограничивать возможности всех процессов, не требующих прав доступа root. He нужны эти права и демону mysqld.

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

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

Выберите учетную запись, предназначенную для запуска сервера. Демон mysqld может работать от имени любого пользователя, однако лучше создать для него отдельную учетную запись. Можно также создать специальную группу для работы с MySQL. Предположим, что такой пользователь и группа уже созданы и имеют имена mysqladm и mysqlgrp. Пользователям, определившим другие имена для этих целей, придется подставлять их далее в примерах кода вместо mysqladm и mysqlgrp.

Если же MySQL был установлен под каким-либо пользователем, не обладающим специальными правами администратора, сервер наверняка будет запускаться под собственным именем этого пользователя. В этом случае необходимо заменить mysqladm и mysqlgrp соответствующим регистрационным именем и именем группы.

Если же система MySQL инсталлировалась под управлением ОС Linux Red Hat с помощью RPM-файла, в процессе установки автоматически создается учетная запись с именем mysql. Ее в последующих примерах этой лекции нужно применять вместо mysqladm.

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

Завершите работу сервера, если он работает.

Измените права доступом к каталогу данных, а также всех его подкаталогов и файлов, чтобы новым владельцем этих элементов оказался пользователь mysqladm. Например, чтобы сделать пользователя mysqladm владельцем каталога данных /usr/local/var, необходимо ввести следующие команды (авторизовавшись в качестве пользователя root).

# cd /usr/local/var. Переход в каталог данных.

# chown -R mysqladm.mysqlgrp.

Измените полномочия доступа к каталогу данных и всем его подкаталогам и файлам, чтобы работать с ними мог только пользователь mysqladm. Запретите доступ к данным всем остальным пользователям — это самая эффективная мера предосторожности. Если каталог данных размешается в директории /usr/local/var, определить права доступа на него для пользователя mysqladm можно с помощью следующих команд (авторизовавшись в качестве пользователя root).

# cd /usr/local/var. Переход в каталог данных.

# chmod -R go-rwx.

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

По завершении вышеприведенной процедуры следует убедиться в нормальном запуске сервера, предварительно авторизовавшись в качестве пользователя mysqladm или root. В последнем случае обязательно нужно определить опцию --user=mysqladm, чтобы пользователь мог переключить ID-номер своего компьютера на mysqladm (что также реализуется в процессе запуска системы).

Опция --user была добавлена в mysql в версии MySQL 3.22. В более ранних версиях для этих же целей можно использовать команду su, которая указывает системе, работающей под управлением пользователя root, что запускать сервер необходимо с учетной записью другого пользователя. Настоятельно рекомендуется заглянуть в справочное руководство и ознакомиться с синтаксисом команды su, поскольку он может видоизменяться для отдельных пользователей.

Методы запуска сервера

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

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

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

Вызов сценария mysql.server. Этот сценарий запускает сервер посредством запуска сценария safemysqld. Сценарий mysql.server предназначен для использования на компьютерах с системой запуска/завершения работы System V. Данная система включает несколько каталогов со сценариями, вызываемыми при входе или выходе с определенного уровня работы. С помощью соответствующих аргументов start и stop можно определить, что делать дальше: запустить сервер или остановить его работу.

Сценарий safemysqld располагается в подкаталоге bin каталога инсталляции MySQL. Его же можно найти в каталоге scripts дистрибутива MySQL. Сценарий mysql.server можно отыскать в подкаталоге share/mysql каталога инсталляции или каталоге support-files исходной дистрибуции MySQL. Для использования эти сценарии необходимо скопировать в соответствующие каталоги запуска.

В ОС BSD-UNIX довольно часто используются несколько специальных файлов, которые располагаются в каталоге /etc и инициируют службы во время запуска. Как правило, имена таких файлов начинаются с приставки "rc". Файл rc.local (или имеющий подобное название), например, предназначен специально для запуска локальных служб. Для запуска сервера в подобных системах необходимо добавить в файл rc.local следующие строки (подставив правильный путь к сценарию safe_mysqld):

if [ -x /usr/local/bin/safe_mysqld ]; then /usr/local/bin/safe_mysqld & fi

В системах System V для инсталляции сценария mysql.server достаточно разместить его в подкаталоге /etc каталога запуска. Это наверняка уже сделано, если Linux или MySQL инсталлировались с помощью RPM-файла. Если нет, инсталлируйте сценарий в основной каталог сценариев запуска и установите связи с ним в каталогах уровней запуска. Можно также сделать так, чтобы сценарии запускались только пользователем root.

Структура каталогов с файлами запуска может изменяться от системы к системе, поэтому рекомендуется внимательно просмотреть, как эти файлы организованы в используемом компьютере. Например, в системе LinuxPPC для запуска применяются каталоги /etc/rc.d/init.d и etc/rc.d/rc3.d. Соответственно, инсталляция сценария выполняется с помощью следующих команд:

# ср mysql.server /etc/rc.d/init.d

# cd /etc/init.d

# chmod 500 mysql.server

# cd /etc/rc.d/rc3.d

# ln -s ../init.d/mysql.server S99mysql

В ОС Solaris основной каталог сценариев — /etc/init.d, а каталог уровня запуска — /etc/rc2.d, поэтому набор команд инсталляции выглядит следующим образом:

# ср mysql.server /etc/init.d

# cd /etc/init.d

# chmod 500 mysql.server

# cd /etc/rc2.d

# ln -s ../init.d/mysql.server S99mysql

Эти команды обеспечивают автоматический запуск сценария S99mysql с аргументом start в процессе загрузки системы.

Если имеется возможность использования команды chkconfig (часто применяемой под управлением Linux), ее также можно применить для инсталляции сценария mysql.server. В этом случае от ручного ввода приведенных выше команд можно отказаться.

Определение опций запуска

Существует два способа определения дополнительных опций запуска, которые применяются при загрузке сервера. Во-первых, можно изменить используемый сценарий запуска (safemysqld или mysql.server) и задать параметры непосредственно в строке вызова сервера. Во-вторых, можно определить параметры собственно в конфигурационном файле. Профессионалы рекомендуют по возможности использовать для этих целей глобальные конфигурационные файлы. В системах UNIX и Windows этими файлами обычно являются /etc/my.cnf.

Однако есть информация, которую невозможно задать в конфигурационных файлах. Для ее определения необходимо изменить сценарий safemysqld. Так, например, если сервер неправильно считал установки временного пояса и возвращает значения времени в формате GMT (времени по Гринвичу), можно для подсказки установить переменную среды TZ. Если сервер запускается с помощью сценария safemysqld или mysql.server, установку временного пояса можно добавить в safemysqld. Отыщите строку запуска сервера и перед ней добавьте следующие команды:

TZ=US/Central

export TZ

Эти команды устанавливают часовой пояс центральной части Соединенных Штатов. Пользователям же необходимо аналогичным образом задать свой часовой пояс. Подобный синтаксис для переменной TZ применяется в системе Solaris. В других системах он может быть другим, например, таким:

TZ=CST6CDT

export TZ

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

Проверка таблиц во время запуска

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

Завершение работы сервера

Для самостоятельного завершения работы сервера применяется команда mysqladmin:

% mysqladmin shutdown

Автоматическое завершение работы сервера также не требует выполнения каких-либо специальных действий. В UNIX BSD работа служб обычно завершается посредством отправки процессам сигнала TERM. Службы либо соответствующим образом на него отвечают, либо просто закрываются. Сервер mysqld, например, на получение такого сигнала реагирует закрытием. В системах System V, запуск сервера в которых производится с помощью сценария mysql.server, процедура завершения работы реализуется посредством вызова этого же сценария, но с аргументом stop. При этом, конечно же, предполагается, что сценарий mysql.server инсталлирован.

Когда нельзя подключиться к серверу

В некоторых случаях возникает необходимость в самостоятельной перезагрузке сервера из-за невозможности подключения к нему. Честно говоря, получается какой-то парадокс, поскольку обычно для завершения работы сервера необходимо сначала подключиться к нему, а затем дать указание на остановку. Как же может возникнуть подобная ситуация? Во-первых, администратор может не знать пароля MySQL-пользователя root. Иногда это случается, когда при изменении пароля случайно введен лишний символ или пароль просто забыт.

Во-вторых, подключение к компьютеру localhost обычно осуществляется через сокет ОС UNIX, которым, как правило, является /tmp/mysql.sock. Удаление этого файла делает невозможным подключение клиентов. Такая ситуация, в свою очередь, может возникнуть после запуска процесса сron, который удаляет временные файлы из каталога /tmp.

Если подключиться нельзя из-за отсутствия файла разъема, проблему можно легко решить посредством простой перезагрузки сервера. В процессе запуска он пересоздаст этот файл. Проблема заключается в том, что использовать этот разъем для установления соединения с сервером нельзя. Для этого необходимо установить соединение TCP/IP. Например, если сервер запускается на компьютере с адресом viper.snake.net, подключиться к нему можно с помощью следующей команды:

% mysqladmin -p -u root -h pit-viper.snake.net shutdown

Если файл разъема удален в результате работы задания программы остановки, проблема может возникнуть снова. Чтобы избежать этого, настройте программу остановки на использование другого файла разъема. Это можно осуществить с помощью глобального конфигурационного файла. Так, например, если /usr/local/var — каталог данных, для перемещения в него файла разъема достаточно добавить следующие строки в файл /etc/my.cnf:

[mysqld]

socket=/usr/local/var/mysql.sock

[client]

socket=/usr/local/var/mysql.sock

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

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

Завершите работу сервера. Авторизовавшись как пользователь root на компьютере с сервером, администратор может завершить работу сервера с помощью команды kill. Используя команду ps, можно отыскать ID-номер процесса сервера. С этой же целью можно просмотреть PlD-файл, который обычно располагается в каталоге данных.

Лучше сначала попытаться завершить работу сервера с помощью обычной команды kill, чем сразу посылать серверу сигнал term и проверять, правильно ли он отреагировал на нее, завершив работу. В этом случае все таблицы и журналы будут обработаны и закрыты корректно. Если в работе сервера не все нормально и он не отвечает на сигнал завершения работы, можно воспользоваться командой kill -9 для принудительного закрытия. Однако к ее помощи следует прибегать в самую последнюю очередь, поскольку в этом случае существует риск оставить таблицы поврежденными.

Если работа сервера все же была завершена с помощью команды kill -9, настоятельно рекомендуется перед следующим запуском сервера проверить таблицы с помощью команд myisamchk и isamchk.

Перезапустите сервер с помощью параметра --skip-grant-tables. Это укажет серверу не использовать таблицы разрешений для проверки соединений и позволит подключиться с полномочиями пользователя root без пароля. После удачного подключения измените пароль пользователя root без пароля.

Используя команду mysqladmin flush-privileges, укажите серверу снова перезагрузиться, но с применением таблиц разрешений. Если используемая версия mysqladmin не поддерживает опцию flush-privileges, попробуйте воспользоваться командой reload.

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

Таблица разрешений	Содержимое
user	Подключающиеся к серверу пользователи и все их глобальные привилегии
db	Привилегии уровня базы данных
tables_priv	Привилегии уровня таблицы
columns_priv	Привилегии уровня столбца

Существует еще одна, пятая таблица разрешений (host), однако операторы grant и revoke не в состоянии ее обрабатывать.

Если оператор GRANT запускается для определенного пользователя, в таблице user для него создается новая запись. Если оператор определяет для пользователя какие-либо глобальные привилегии (привилегии администратора или привилегии, применяемые сразу ко всем базам данных), они также записываются в таблицу user. Права обработки базы данных, таблицы или столбца записываются соответственно в таблицы db, tables_priv и column_priv.

Применять операторы grant и revoke проще, чем непосредственно редактировать таблицы разрешений.

Роль этих таблиц действительно велика, и администратор должен понимать, каким образом их обрабатывают операторы GRANT и REVOKE.

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

Некоторые пользователи захотят также познакомиться со сценариями mysqlaccess и mysql_setpermission, которые являются частью дистрибуции MySQL. Они представляют собой Perl-сценарии и обеспечивают альтернативу оператору grant, поскольку применяются для установки пользовательских учетных записей. Для использования сценария mysql_setpermission требуется инсталляция поддержки DBI.

Создание новых пользователей и предоставление привилегий

Оператор GRANT имеет следующий синтаксис:

GRANT privileges (columns)

ON what

TO user IDENTIFIED BY "password"

WITH GRANT OPTION

Для успешного его выполнения обязательно нужно правильно определить следующую информацию:

privileges (привилегии). Привилегии присваиваются определенному пользователю. Используемые в операторе grant спецификаторы привилегий описаны в представленной ниже таблице.

Спецификатор привилегий	Разрешенная операция
user	Подключающиеся к серверу пользователи и все их глобальные привилегии
alter	Изменение таблиц и индексов
create	Создание баз данных и таблиц
delete	Удаление существующих записей из таблиц
drop	Удаление баз данных и таблиц
index	Создание и удаление индексов
insert	Вставка новых записей в таблицы
references	He используется
select	Извлечение существующих записей из таблиц
update	Изменение существующих записей таблиц
file	Чтение и запись файлов сервера
process	Просмотр информации о внутренних потоках сервера и их удаление
reload	Перезагрузка таблиц разрешений или обновление журналов, кэша компьютера или кэша таблицы
shutdown	Завершение работы сервера
all	Все операции. Аналог — all privileges
usage	Полное отсутствие привилегий

Спецификаторы привилегий, входящие в первую группу этой таблицы, применяются к базам данных, таблицам и столбцам. Спецификаторы второй группы определяют административные привилегии. Как правило, они применяются довольно редко, поскольку позволяют пользователю влиять на работу сервера. (Не каждому пользователю, например, необходима привилегия shutdown.) В третью группу входят два отдельных спецификатора: спецификатор ALL предоставляет "все привилегии", a USAGE означает "полное отсутствие привилегий". В последнем случае создается новый пользователь, не обладающий никакими правами;

columns (столбцы). Столбцы, к которым применяются определенные привилегии. Этот параметр необязателен и используется только при установке привилегий для столбцов. Имена нескольких столбцов отделяются друг от друга запятыми;

what (что). Уровень применения привилегий. Привилегии могут быть глобальными (применяемыми ко всем базам данных и их таблицам), уровня баз данных (применяемыми ко всем таблицам определенной базы данных) или уровня таблицы. Используя оператор columns, можно определить также привилегии уровня столбца;

user (пользователь). Пользователь, которому присваиваются привилегии. В некоторых версиях MySQL необходимо указывать как имя пользователя, так и компьютер, с которого он сможет подключаться. Такой способ задания легко позволяет определить двух пользователей с одинаковым именем, но подключающихся с разных компьютеров. Возможности MySQL позволяют их различать и наделять различными правами.

Имя пользователя в некоторых версиях MySQL представляет собой имя, используемое при подключении к серверу. Оно вовсе не обязательно должно быть связано с именем регистрации в ОС UNIX или Windows. Если имя пользователя MySQL не определено явным образом, клиентские программы по умолчанию применяют его в качестве регистрационного имени, однако это необязательно. Не существует также каких-либо особых требований, чтобы суперпользователь MySQL, обладающий максимальными правами, имел имя root. По желанию его можно изменить в таблицах разрешений на nobody, если для выполнения определенных операций требуются его полномочия;

password (пароль). Присвоенный пользователю пароль, который не является обязательным. Если для нового пользователя опустить выражение IDENTIFIED BY, пароль ему присвоен не будет (что не совсем разумно с точки зрения безопасности). Если же этот оператор задается для уже существующего пользователя, введенный пароль заменит используемый до настоящего момента. Старый пароль останется неизменным, если новый не будет определен. Строка пароля, задаваемая с помощью выражения IDENTIFIEDBY, должна представлять собой буквенную строку, которую при записи зашифрует оператор grant. Поэтому не следует применять функцию password(), применяемую с оператором SET password.

Оператор with grant option является необязательным. С его помощью можно предоставить пользователю все привилегии, определенные оператором GRANT для других пользователей. Этот оператор можно использовать для делегирования возможностей определенных категорий другим пользователям.

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

Чтобы определиться, какую же форму оператора GRANT применить, достаточно ответить на следующие вопросы.

Кто и откуда может подключаться к серверу?

Какой уровень привилегий должен иметь пользователь и на доступ к чему эти привилегии предоставляются?

Необходимо ли пользователю предоставлять административные привилегии?

Давайте попробуем ответить на эти вопросы и рассмотрим примеры оператора grant для создания учетных записей пользователей MySQL.

Кто и откуда может подключаться к серверу

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

GRANT ALL ON samp_db.* TO boris@localhost IDENTIFIED BY "ruby"

GRANT ALL ON samp_db.* TO fred@ares.mars.net IDENTIFIED BY "quartz"

GRANT ALL ON samp_db.* TO max@% IDENTIFIED BY "diamond"

Символ "%" заменяет все возможные значения адресов и выполняет те же функции, что и при сравнении с помощью оператора LIKE. В предыдущем примере его можно условно заменить фразой "любой компьютер". Установка символа "%" аналогична простому опусканию части, задающей компьютер. Другими словами, эквивалентными в данном примере выступят записи max и mах@%. Это самый простой и, в то же время, самый незащищенный способ создать пользователя.

В случае необходимости можно также разрешить пользователю подключаться с ограниченного числа компьютеров. Так, чтобы пользователь mаrу мог подключаться с компьютеров домена snake.net, достаточно воспользоваться спецификатором %.snake.net:

GRANT ALL ON samp_db.* TO mary@%.snake.net IDENTIFIED BY "topaz"

Для определения компьютера можно применять не только имена, но и IP-адреса. Эти адреса можно задавать явно либо с помощью вспомогательных символов. Кроме того, в версии MySQL 3.23 появилась возможность определять IP-адреса, задавая маску сети, устанавливая число разрядов в сетевом номере:

GRANT ALL ON samp_db.* TO joe@192.168.128.3 IDENTIFIED BY "water"

GRANT ALL ON samp_db.* TO ardis@192.168.128.% IDENTIFIED BY "snow"

GRANT ALL ON samp_db.* TO rex@192.168 .128.0/17 IDENTIFIED BY "ice"

Первый оператор определяет только один компьютер, с которого может подключиться пользователь joe. Второй определяет набор IP-адресов для подсети класса С 192.168.128. В третьем операторе часть 192.168.128.0/17 определяет 17-разрядный сетевой номер и соответствует любому компьютеру с адресом 192.168.128 в первых 17 разрядах IP-адреса.

Если MySQL отказывается принимать определенные пользовательские значения, попробуйте заключить их в кавычки (необходимо отдельно заключать в кавычки имя пользователя и компьютера):

GRANT ALL ON samp_db.president TO "my_friend"@"boa.snake.net"

Какой уровень привилегий должен иметь пользователь и на доступ к чему эти привилегии предоставляются

Администратор может предоставлять пользователям привилегии разных уровней. Наиболее мощными являются глобальные привилегии, применяемые ко всем базам данных. Так, например, чтобы предоставить пользователю ethel права суперпользователя, который может делать все, в том числе и предоставлять привилегии другим пользователям, необходимо запустить следующий оператор:

GRANT ALL ON *.* ТО ethel@localhost IDENTIFIED BY "coffee"

WITH GRANT OPTION

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

Некоторые привилегии (FILE, process, reload и shutdown) являются административными и могут присваиваться только с помощью спецификатора глобальных привилегий ON *.*. В случае необходимости их можно присваивать без предоставления привилегий на уровне базы данных. Так, например, приведенный ниже оператор создает пользователя flush, который обладает возможностью только выполнять операторы FLUSH. Это может оказаться полезным в административных сценариях, когда необходимо выполнить обновление журналов:

GRANT RELOAD ON *.* ТО flush@localhost IDENTIFIED BY "flushpass"

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

Привилегии уровня базы данных применяются ко всем таблицам определенной базы. Такие привилегии присваиваются с помощью предложения ON db name:

GRANT ALL ON samp_db.* TO bill@racer.snake.net IDENTIFIED BY "rock"

GRANT SELECT ON menagerie.* TO ro_user@% IDENTIFIED BY "dirt"

Первый из указанных операторов предоставляет пользователю bill все права для работы со всеми таблицами базы данных sampdb. Второй оператор создает пользователя rouser с ограниченными правами (только чтение), который может получать доступ к любой таблице базы данных menagerie, однако только для чтения. Другими словами, этот пользователь имеет возможность запускать только оператор select.

Как определить имя локального компьютера в таблице разрешений

Довольно часто пользователи не могут подключиться к серверу с основного компьютера (на котором инсталлирован сервер) из-за того, что вместо имени localhost указывают имя сервера. Эта проблема возникает по причине использования разных способов определения имен, записанных в таблицах разрешений и выдаваемых программам. Если процедура сервера выдает неполное имя, например, pit-viper, а в таблицах разрешений записано полное имя pit-viper.snake.net (или наоборот), то подключение становится невозможным.

Чтобы определить, существует ли такая проблема на используемом компьютере, попытайтесь подключиться к локальному серверу с помощью опции -h, устанавливающей имя компьютера. Затем загляните в общий учетный файл сервера. Какое имя компьютера в нем записано, полное или неполное? Неважно, какая форма применяется. Важно использовать для определения имени компьютера в операторе grant именно это имя.

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

GRANT SELECT, INSERT, DELETE, UPDATE ON samp_db.* TO jennie@%

IDENTIFIED BY "boron"

Для еще более детального управления доступом можно предоставлять привилегии отдельным таблицам или даже отдельным их столбцам. Привилегии столбцам оказываются особенно полезными, если определенную часть таблицы необходимо скрыть от пользователя либо предоставить возможность изменения только заданных столбцов. Предположим, что какая-то фирма нанимает на определенный период времени сотрудника, который будет выполнять роль секретаря. Администратор решает предоставить новому сотруднику права доступа только для чтения таблицы member, содержащей информацию о действующих членах общества, и привилегию update столбцу expiration (срок окончания членства) этой таблицы. При таком доступе новый секретарь вполне сможет изменять даты окончания членства организаций-участников, если они продолжают свое членство. Для создания такого пользователя MySQL можно использовать следующие операторы:

GRANT SELECT ON samp_db.member TO assistant@localhost IDENTIFIED

BY "officehelp"

GRANT UPDATE (expiration) ON samp_db.member TO assistant@localhost

Первый оператор предоставляет права на чтение всей таблицы member и определяет пароль. Второй оператор добавляет привилегию update, но только для столбца expiration. Поскольку пароль устанавливается первым оператором, во втором его определять повторно вовсе не обязательно.

Если необходимо присвоить привилегии для работы с несколькими столбцами, их имена следует разделить запятыми. Так, например, чтобы добавить привилегии UPDATE для полей адресов таблицы member для пользователя assistant, используется приведенный ниже оператор. При его выполнении новые привилегии будут добавлены к уже существующим привилегиям пользователя:

GRANT UPDATE (street,city,state,zip) ON samp_db.member

TO assistant@localhost

Как правило, пользователю не предоставляются большие привилегии, чем это нужно для работы. Иногда, тем не менее, возникает необходимость в предоставлении пользователям возможности создавать таблицы, чтобы заносить в них промежуточные результаты. Желательно, чтобы эти таблицы создавались не в рабочей базе данных, поскольку пользователи могут случайно изменить ее содержимое. Эту задачу можно решить посредством создания отдельной базы данных (назовем ее tmp) и предоставлению пользователям всех возможных привилегий для работы с ней.

Чтобы разрешить всем пользователям домена mars.net использовать базу данных tmp, достаточно ввести следующий оператор grant:

GRANT ALL ON tmp.* TO "@%.mars.net

После его выполнения пользователи смогут создавать и ссылаться на таблицы базы данных tmp с помощью имен типа tmp.tbl_name.

Нужны ли пользователю административные привилегии

Администратор может предоставить владельцу базы данных возможность управления доступом, предоставив ему все привилегии базы данных и определив опцию WITH GRANT OPTION. Например, чтобы разрешить пользователю alicia подключаться с любого компьютера домена bigcorp.com и предоставить ему административные привилегии для работы со всеми таблицами базы данных sales, необходимо использовать оператор grant следующего вида:

GRANT ALL ON sales.* TO alicia@%.big-corp.com IDENTIFIED BY "applejuice"

WITH GRANT OPTION

Фактически, предложение with grant OPTION позволяет администратору делегировать права разрешения доступа другому пользователю. Однако следует проявлять осторожность, поскольку два пользователя с привилегиями grant могут предоставлять другим пользователям свои права. Если предоставить одному пользователю только привилегию SELECT, а второму, помимо select, привилегию GRANT, второй пользователь легко может сделать первого "более сильным".

Отмена привилегий и удаление пользователей

Для отмены привилегий пользователя применяется оператор revoke. Его синтаксис очень похож на синтаксис оператора GRANT с той лишь разницей, что предложение ТО заменено на предложение FROM, а предложения IDENTIFIED BY и WITH GRANT OPTION отсутствуют вовсе:

REVOKE privileges (columns) ON what FROM user

Часть user этого оператора должна соответствовать части user исходного оператора GRANT для пользователя, привилегии которого отменяются. Часть privileges необязательно должна соответствовать ранее определенным привилегиям. Пользуясь оператором revoke, можно отменить только некоторые из привилегий, предоставленные оператором GRANT.

Оператор revoke применяется для отмены привилегий, но не для удаления пользователей. В таблице user все равно остается запись для пользователя, даже если все привилегии для него сняты. Это означает, что пользователь все еще имеет возможность подключаться к серверу. Для полного удаления пользователя необходимо явным образом удалить его запись из таблицы user. Для этих целей применяется оператор DELETE:

% mysql -u root mysql

mysql> DELETE FROM user WHERE User = "user_name" and Host = "host_name";

mysql> FLUSH PRIVILEGES;

Оператор delete удаляет запись пользователя, а оператор FLUSH указывает серверу перезагрузить таблицы разрешений. (Таблицы перезагружаются автоматически при использовании операторов GRANT и revoke. Однако этого не происходит при непосредственном изменении таблиц разрешений.) Из описанной в следующем разделе ситуации вы узнаете, почему иногда лучше отказаться от удаления записей таблицы user.

Головоломка с привилегиями

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

GRANT ALL ON samp_db.* TO fred@%snake.net IDENTIFIED BY "cocoa"

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

Такая ситуация возникает, если в таблице разрешений содержатся записи, по умолчанию инсталлированные сценарием инициализации mysql_install_db. Причина ее возникновения в том, что при попытке подключения пользователя fred к серверу большим приоритетом перед записью этого пользователя обладает одна из записей анонимного пользователя. Согласно этой записи, для подключения пароль не нужен, однако пользователь fred пытается его ввести. Важно заметить, что для устранения этой проблемы достаточно удалить запись анонимного пользователя из таблицы user. Оператор revoke для этих целей не подходит, поскольку он отменяет только привилегии. Удаление записи выполняется с помощью следующих команд:

% mysql -u root mysql

mysql> DELETE FROM user where User="";

mysql> FLUSH PRIVILEGES;

Сразу после удаления пользователь fred сможет успешно подключиться с локального компьютера.

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

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

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

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

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

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

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

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

Таблицы снабжены флагом, указывающим, изменилось ли содержимое таблицы с момента последней проверки. Инструкция CHECK TABLE пропустит неизмененные таблицы при наличии ключевого слова CHANGED. В утилите myisamchk соответствующий режим включается с помощью опции --check-only-changed. Особым образом помечаются также неправильно закрытые таблицы. Чтобы проверить только их, укажите флаг FAST (инструкция CHECK TABLE) или опцию --fast (утилита myisamchk).

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

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

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

mysql>CHECK TABLE courses;

+--------------+-------+-----------+---------------------------------------------+

| Table | Op | Msg_type | Msg_text |

+--------------+-------+-----------+---------------------------------------------+

| courses | check | error | Size of indexfile is: 1924 Should be: 2048 |

| test.courses | check | error | corrupt |

+--------------+-------+-----------+---------------------------------------------+

2 rows in set (0.00 sec)

mysql>REPAIR TABLE courses;

+--------------+--------+-----------+----------+

| Table | Op | Msg_type | Msg_text |

+--------------+--------+-----------+----------+

| test.courses | repair | status | ok |

+--------------+--------+-----------+----------+

1 row in set (0.08 sec)

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

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

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

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

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

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

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

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

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

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

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

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

Инструкции BACKUP TABLE и RESTORE TABLE копируют табличные файлы в указанный каталог. Естественно, серверный процесс должен иметь право записи в этот каталог. Программа MySQL копирует туда файлы с расширениями .frm и .MUD. Индексный файл (.MYI) можно воссоздать на основании первых двух, что позволит сэкономить место в архиве.

mysql>BACKUP TABLE dictionary TO '/tm/backup';

+-----------------+--------+-----------+------------------------+

| Table | Op | Msg_type | Msg_text |

+-----------------+--------+-----------+------------------------+

| test.dictionary | backup | status | ok |

+-----------------+--------+-----------+------------------------+

1 rows in set (0.27 sec)

Функции копирования файлов предоставляются операционной системой, поэтому данный способ создания резервных копий является самым быстрым. Таблица dictionary, содержит более 100000 записей, а файл данных занимает почти 3 Мбайт. Как видите, процедура архивирования такой таблицы заняла менее секунды.

Инструкция BACKUP TABLE самостоятельно заботится о блокировании таблиц и очистке табличных буферов. Это означает, что, в отличие от других методов резервного копирования, дополнительные инструкции не нужны.

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

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

mysql> RESTORE TABLE dictionary FROM '/tmp/backup';

+-----------------+---------+-----------+--------------------------+

| Table | Op | Msg_type | Msg_text |

+-----------------+---------+-----------+--------------------------+

| test.dictionary | restore | status | ok |

+-----------------+---------+-----------+--------------------------+

1 rows in set (1 min 22.24 sec)

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

mysql> REPAIR TABLE dictionary;

+-----------------+---------+-----------+-----------------------------------------+

| Table | Op | Msg_type | Msg_text |

+-----------------+---------+-----------+-----------------------------------------+

| state | repair | warning | number of rows changed from 0 to 104237 |

| test.state | repair | status | ok |

+-----------------+---------+-----------+-----------------------------------------+

2 rows in set (1 min 25.12 sec)

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

# mysqlhotcopy mysql /trap/hc

Locked 6 tables in 0 seconds.

Flushed tables(mysql.columns_priv, mysql.db, mysql.func, mysql.host,

mysql.tables_priv, mysql.user) in 0 seconds.

Copying 18 files…

Copying indices for 0 files…

Unlocked tables.

Mysqlhotcopy copied 6 tables |(18 files) in 1 second (1 seconds overall).

# ls /tmp/hc/mysql

columns_priv.MYD db.MYD func.MYD host.MYD tables_priv.MYD user.MYD

columns_priv.MYI db.MYI func.MYI host.MYI tables_priv.MYI user.MYI

columns_priv.frm db.frm func.frm host.frm tables_priv.frm user.frm

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

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

Для создания sql-образа таблицы предназначена утилита mysqldump. Она записывает текст инструкций в поток stdout, поэтому нужно перенаправить результаты ее работы в файл.

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

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

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

[/tmp]# mysqldump --verbose --tab=/tmp test dictionary

# Connecting to localhost...

# Retrieving table structure for table dictionary...

# Sending SELECT query...

# Disconnecting from localhost...

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

mysql> source /tmp/dictionary.sql

Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA INFILE '/tmp/dictionary.txt' INTO TABLE dictionary;

Query OK, 104237 rows affected (1 min 27.70 sec)

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

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

mysql> SELECT * FROM dictionary INTO OUTFILE 'tmp/dictionary.txt';

Query OK, 104237 rows affected (6.42 sec)

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

# mysqlbinlog --offset=1 --short-form red-bin.001

use freetime;

SET TIMESTAMP=991767105;

UPDATE session SET LastAction = now() WHERE ID='fNbbnOLBYYlqesqa';

use freetime;

SET TIMESTAMP=991767134;

UPDATE session SET LastAction = now() WHERE ID='fNbbnOLBYYlqesqa';

use freetime;

SET TIMESTAMP=991767134;

DELETE FROM project_view WHERE Project=2 AND User=2;

use freetime;

SET TIMESTAMP=991767135;

INSERT INTO project_view VALUES (2, 2, now());