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

% mysql -u root mysql mysql> DELETE FROM user

-> WHERE User = user name and Host = host name ; mysql> FLUSH PRIVILEGES;

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

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

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

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

grant all on samp db.* to fredl?%snake .net identified BY cocoa

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

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

% mysql -U root mysql

mysql> DELETE FROM user where User= ; raysql> FLUSH PRIVILEGES;

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

Ведение файлов журналов

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

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

Журнал обновлений. Этот файл содержит запросы, изменяющие базу данных. Несмотря на название, этот журнал содержит записи не только операторов UPDATE, но и многих других, используемых для изменения базы данных, например, DELETE, INSERT, REPLACE, CREATE TABLE, DROP TABLE, GRANT И REVOKE. Содержимое журнала обновлений представлено в виде операторов SQL. Форма записи этих операторов позволяет использовать их для ввода в mysql. В комбинации с резервированием этот журнал становится эффективным средством восстановления таблиц после сбоя. Достаточно восстановить базу данных из файлов архива, а затем запустить повторно все запросы на изменение базы данных с момента последней архивации, используя записи журнала обновлений в качестве ввода для mysql. Эти действия позволят восстановить таблицы в состояние, в котором они находились перед самым сбоем.

Для активизации процесса регистрации используются опции --log и --log-update. Первая приводит к созданию и ведению общего журнала, вторая - журнала обновлений. Эти опции можно определить в командной строке при запуске сценариев mysqid, safe mysqld или mysql. server, а также в фуппе [mysqid] конфигурационного файла. При активизации регистрации файлы журналов по умолчанию записываются в каталоге данных сервера.

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

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

Ротация файлов журналов выполняется следующим образом. Предположим, файл журнала имеет имя log. На первом этапе он переименовывается в log. О, и сервер приступает к записи нового файла log. На втором этапе файл log. О переименовывается в log. 1, файл log - в log. О, а сервер приступает к записи нового файла log. В этом случае каждому файлу последовательно присваиваются имена log. О, log.l и т.п. По достижении определенного этапа файл стирается.

Журналы обновлений и операторы load data

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

Резервирование системы

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

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

Частота ротации файлов и число старых журналов определяется, в первую очередь, загруженностью сервера (активные серверы генерируют значительно больще информации регистрации) и наличием свободного пространства. При ротации общих журналов можно указать серверу, чтобы он закрывал текущий файл журнала и открывал новый с помощью команды mysqladmin flush-logs.

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

#! /bin/sh datadir=DATADIR

d $datadir

mv $base.5 $base.6

mv $base.4 $base.5