сценарий mysql. server для завершения работы и сервера MySQL, данный сценарий обратится к PID-файлу. Это обрашение позволит определить, какому процессу отправить команду на завершение работы.

Таблица 10.3. Файлы состояния MySQL

Тип файла

Имя по умолчанию Содержимое файла

Ю-номер процесса Журнал ошибок

Общий журнал

HOSTNAME.pxd HOSTNAME, err

lD-номер процесса сервера

События запуска и завершения работы, а также записи об ошибках

HOSTNAME, log События подключения/отключения и информация о запросах

Журнал обновлений HOSTNAME, ппп Текст всех запросов, изменяющих

содержимое или структуру таблицы

Журнал ошибок создается сценарием safemysqld. Впоследствии именно в этот журнал перенаправляются все стандартные сообщения об ошибках сервера Другими словами, журнал содержит все сообщения, записываемые сервером в stderr, и сушествует, только если сервер запускается с помошью вызова сценария safe mysqld. (Это более предпочтительный метод запуска сервера, поскольку safe mysqld перезапускает сервер при сбое в работе из-за ошибки.)

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

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

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

990509

7:34:09

492 Connect

492 Query

492 Query

492 Field List

492 Field List

paul@localhost on test

show databases

show tables

tbl l

tbl 2

990509 7:34:22 492 Query CREATE TABLE my tbl (val INT)

990509 7:34:34 492 Query INSERT INTO my tbl VALUES(1)

990509 7:34:38 492 Query DROP TABLE my tbl

99U509 7:34:40 492 Quit

Отдельные столбцы общего журнала отражают дату и время события, Ш-номер сервера, тип события и относящуюся к нему специальную информацию

Тот же сеанс в журнале обновлений отобразится следующим образом:

use test;

CREATE TABLE my tbl (val INT); INSERT INTO my tbl VALUES(1); DROP TABLE my tbl;

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

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

# Time: 990509 7:43:42

# User(?Host: paul [paul] @ localhost [] use test;

CREATE TABLE my tbl (val INT);

# User(aHost: paul [paulj @ localhost [] INSERT INTO my tbl VALUES(1);

# Time: 990509 7:43:43

# UserlHost: paul [paul] (? localhost [1 DROP TABLE my tbl;

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

990509 7:47:24 4 Query UPDATE user SET Password=PASSWORD( secret )

WHERE user= root

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

% chmod 700 DATADIR

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

запретит другим пользователям доступ к каталогу данных (что и требуется), но также закроет базы данных для сервера (чего допустить ни в коем случае нельзя!).

Файлы состояния размещаются на верхнем уровне каталога данных вместе с каталогами баз данных. Поэтому иногда пользователи беспокоятся, что имена файлов состояния могут конфликтовать с именами баз данных (например, при выполнении сервером оператора SHOW DATABASES). Этого бояться Не СТОИТ Информация о событиях и состояниях хранится в файлах, а базы данных записаны в каталогах, что позволяет исполняемым программам легко отличить их, вызвав команду Stat О. (Именно таким образом их различает сервер.) Просматривая каталог данных с помощью опции Is -1, пользователь может отличить файлы состояния от каталогов баз данных, определив первую букву данных в режиме; - или d:

% Is -1 DATADIR total 31 drwxrwx-drwxrwx--rw-rw- -rw-rw-r -rw-rw- -rw-rw-r drwxrwx-drwxrwx-

1 mysqladm mysqlgrp 1024 May 8 13:22 bigdb

2 mysqladm mysqlgrp 1024 Dec 15 22:34 mysql 1 mysqladm mysqlgrp 64 May 9 20:11 pit-viper.001 1 mysqladm mysqlgrp 24168 May 9 20:11 pit-viper.err 1 mysqladm mysqlgrp 4376 May 9 20:11 pit-viper.log

1 mysqladm mysqlgrp 5 May 9 20:11 pit-viper.pid 7 mysqladm mysqlgrp 512 Sep 10 1998 sql-bench

2 mysqladm mysqlgrp 512 May 9 07:34 test

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

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

Перемещение содержимого каталога данных

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

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