Каталог данных MySQL

Файлы состояния MySQL

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

Сервер записывает ID-номер своего процесса (Process ID — PID) в PID- файл при запуске и удаляет этот файл при завершении работы. Именно с помощью PID-файла сервер позволяет находить себя работающим процессам. Так, например, если во время завершения работы системы запустить сценарий mysql.server для завершения работы и сервера MySQL, данный сценарий обратится к PID-файлу. Это обращение позволит определить, какому процессу отправить команду на завершение работы.

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

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

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

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

990509  7:34:09     492 Connect 		paul@localhost on test 
	      		    492 Query 			show databases 
                    492 Query 			show tables 
                    492 Field List	 	tbl_l 
                    492 Field List	 	tbl 2
990509 	7:34:22		492 Query 		CREATE TABLE my_tbl (val INT) 
990509 	7:34:34		492 Query 		INSERT INTO my_tbl VALUE(A) 
990509 	7:34:38		492 Query 		DROP TABLE my_tbl 
990509 	7:34:40		492 Quit

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

use test; 
CREATE TABLE my_tbl (val INT); 
INSERT INTO my_tbl VALUE(A); 
DROP TABLE my_tbl;

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

# Time: 9905097:43:42 
# User@Host: paul [paul] @ localhost [] 
use test; 
CREATE TABLE my_tbl (val INT); 
# User@Host: paul [paul] @ localhost {] 
INSERT INTO my_tbl VALUE(A); 
# Time: 9905097:43:43 
# User@Host: paul [paul] 0 localhost П 
DROP TABLE my_tbl;

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

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