Книги, научные публикации
Pages: | 1 | ... | 4 | 5 | 6 | 7 | 8 | ... | 11 | мтт. ...
-- [ Страница 6 ] --Устанавливая права владения и режим для каталога данных и его содержимого, не забудьте просмотреть символические связи. Нужно обязательно переместиться в каталоги, на которые эти связи указывают, и изменить права доступа для их содержимого. На этом этапе могут возникнуть проблемы, если содержащий все связанные файлы каталог не принадлежит владельцу каталога данных. Единственный способ решения таких проблем Ч зарегистрироваться в качестве пользователя root. По завершении вышеприведенной процедуры следует убедиться в нормальном запуске сервера, предварительно зарегистрировавшись в качестве пользователя mysqladm или root. В последнем случае обязательно нужно определить опцию Чuser=mysqladm, чтобы пользователь мог переключить ID-номер своего компьютера на mysqladm (что также реализуется в процессе запуска системы). Опция --user была добавлена в mysql в версии MySQL 3.22. В более ранних версиях для этих же целей можно использовать команду su, указывающую системе, работающей под управлением пользователя root, что запускать сервер необходимо с учетной записью другого пользователя. Настоятельно рекомендуется заглянуть в справочное руководство и ознакомиться с синтаксисом команды su, поскольку он может видоизменяться для отдельных пользователей.
Часть III. Администрирование MySQL Методы запуска сервера После определения учетной записи, которая будет использоваться для работы сервера, можно приступать к выбору способа запуска. Сервер можно запускать вручную из командной строки или автоматически в процессе загрузки системы. Существуют три основных метода запуска сервера. Х Непосредственный вызов mysqld. Это, возможно, самый распространенный метод. Поэтому подробно рассматриваться далее он не будет. Достаточно лишь заметить, что в случае необходимости можно использовать команду mysqld Чhelp для определения опций, используемых с другими методами запуска. Х Вызов сценария saf e_mysqld. Этот сценарий в процессе своей работы пытается определить местоположение программы сервера и каталога данных, а затем запускает сервер с соответствующими опциями. Сценарий safe_mysqld записывает все сообщения об ошибках сервера в специальный файл ошибок, расположенный в каталоге данных. Кроме того, safejnysqld следит за нормальной работой сервера и в случае сбоя перезагружает его. Этот сценарий наиболее часто применяется в BSD-версиях UNIX. Х Вызов сценария mysql. server. Этот сценарий запускает сервер посредством запуска сценария safe_mysqld. Сценарий mysql. server предназначен для использования на компьютерах с системой запуска/завершения работы System V. Данная система включает несколько каталогов со сценариями, вызываемыми при входе или выходе с определенного уровня работы. С помощью соответствующих аргументов start и stop можно определить, что делать дальше: запустить сервер или остановить его работу. Сценарий safe_mysqld располагается в подкаталоге bin каталога инсталляции MySQL. Его же можно найти в каталоге scripts исходной дистрибуции MySQL. Сценарий m y s q l. s e r v e r можно отыскать в подкаталоге share/mysql каталога инсталляции или каталоге support-files исходной дистрибуции MySQL. Для использования эти сценарии необходимо скопировать в соответствующие каталоги запуска. В ОС BSD-UNIX довольно часто используются несколько специальных файлов, которые располагаются в каталоге /etc и инициируют службы во время запуска. Как правило, имена таких файлов начинаются с приставки "гс". Файл re.local (или имеющий подобное название), например, предназначен специально для запуска локальных служб. Для запуска сервера в подобных системах необходимо добавить в файл re. local следующие строки (подставив правильный путь к сценарию safe_mysqld):
if [ -x /usr/local/bin/safe_mysqld ];
then /usr/local/bin/safe_mysqld & fi Глава 11. Общее администрирование MySQL В системах System V для инсталляции сценария mysql. server достаточно разместить его в подкаталоге /etc каталога запуска. Это наверняка уже сделано, если Linux или MySQL инсталлировались с помощью RPMфайла. Если нет, инсталлируйте сценарий в основной каталог сценариев запуска и установите связи с ним в каталогах уровней запуска. Можно также сделать так, чтобы сценарии запускались только пользователем root. Структура каталогов с файлами запуска может изменяться от системы к системе, поэтому рекомендуется внимательно просмотреть, как эти файлы организованы в используемом компьютере. Например, в системе LinuxPPC для запуска применяются каталоги / e t c / r e. d / i n i t. d и e t c / r e. d / r c 3. d. Соответственно инсталляция сценария выполняется с помощью следующих команд:
# # # # # ср mysql.server /etc/re.d/init.d cd /etc/init.d chmod 500 mysql.server cd /etc/re.d/rc3.d In -s../init.d/mysql.server S99mysql В ОС Solaris основной каталог сценариев Ч / e t c / i n i t. d, а каталог уровня запуска Ч / e t c / r c 2. d, поэтому набор команд инсталляции выглядит следующим образом:
# # # # # ср mysql.server /etc/init.d cd /etc/init.d chmod 500 mysql.server cd /etc/rc2.d In -s../init.d/mysql.server S99mysql Эти команды обеспечивают автоматический запуск сценария S99mysql с аргументом start в процессе загрузки системы. Если имеется возможность использования команды chkconf ig (часто применяемой под управлением Linux), ее также можно применить для инсталляции сценария m y s q l. s e r v e r. В этом случае от ручного ввода приведенных выше команд можно отказаться. Определение опций запуска Существует два способа определения дополнительных опций запуска, которые применяются при загрузке сервера. Во-первых, можно изменить используемый сценарий запуска (safejnysqld или mysql. server) и задать опции непосредственно в строке вызова сервера. Во-вторых, можно определить опции собственно в конфигурационном файле. Профессионалы рекомендуют по возможности использовать для этих целей глобальные конфигурационные файлы. В системах UNIX и Windows этими файлами обычно являются / e t c / m y. c n f и C : \ m y. c n f соответственно. (Более детально об использовании конфигурационных файлов рассказывается в приложении Д, "Программы MySQL".) 486 Часть III. Администрирование MySQL Однако есть информация, которую невозможно задать в конфигурационных файлах. Для ее определения необходимо изменить сценарий safejnysqld. Так, например, если сервер неправильно считал установки временного пояса и возвращает значения времени в формате GMT (времени по Гринвичу), можно для подсказки установить переменную среды TZ. Если сервер запускается с помощью сценария safe_mysqld или mysql. server, установку временного пояса можно добавить в saf ejnysqld. Отыщите строку запуска сервера и перед ней добавьте следующие команды:
TZ=US/Central export TZ Эти команды устанавливают часовой пояс центральной части Соединенных Штатов. Пользователям же необходимо аналогичным образом задать свой часовой пояс. Подобный синтаксис для переменной TZ применяется в системе Solaris. В других системах он может быть другим, например, таким:
TZ=CST6CDT export TZ Следует помнить, что после повторной инсталляции MySQL (например, при обновлении версии) все внесенные в сценарий запуска изменения будут потеряны. В таком случае необходимо сперва скопировать сценарий в другую папку, а после инсталляции сравнить оба сценария (старый и вновь инсталлированный) и добавить отсутствующие опции. Проверка таблиц во время запуска Помимо настройки автоматического запуска сервера в процессе загрузки системы, можно также инсталлировать сценарий, который будет запускать утилиты myisamchk и isamchk. Это позволит проверять таблицы перед запуском сервера. В некоторых случаях перезагрузка сервера выполняется после сбоя, в результате которого таблицы могут оказаться поврежденными. Проверка таблиц перед запуском сервера Ч отличный способ предотвратить будущие проблемы. Более детально о создании и инсталляции такого сервера рассказывается в главе 13, "Поддержка и восстановление баз данных". Завершение работы сервера Для самостоятельного завершения работы сервера применяется команда mysqladmin:
% mysqladmin shutdown Автоматическое завершение работы сервера также не требует выполнения каких-либо специальных действий. В UNIX BSD работа служб Глава 11. Общее администрирование MySQL обычно завершается посредством отправки процессам сигнала TERM. Службы либо соответствующим образом на него отвечают, либо просто закрываются. Сервер mysqld, например, на получение такого сигнала реагирует закрытием. В системах System V, запуск сервера в которых производится с помощью сценария mysql. server, процедура завершения работы реализуется посредством вызова этого же сценария, но с аргументом stop. При этом, конечно же, предполагается, что сценарий m y s q l. server инсталлирован. Когда нельзя подключиться к серверу В некоторых случаях возникает необходимость в самостоятельной перезагрузке сервера из-за невозможности подключения к нему. Честно говоря, получается какой-то парадокс, поскольку обычно для завершения работы сервера необходимо сначала подключиться к нему, а затем дать указание на закрытие. Как же может возникнуть подобная ситуация? Во-первых, администратор может не знать пароля MySQL-пользователя root. Иногда это случается, когда при изменении пароля случайно введен лишний символ или пароль просто забыт. Во-вторых, подключение к компьютеру localhost обычно осуществляется через файл доменного разъема ОС UNIX, которым, как правило, является /trnp/mysql. sock. Удаление этого файла делает невозможным подключение клиентов. Такая ситуация, в свою очередь, может возникнуть после запуска процесса сгоп, который удаляет временные файлы из каталога /tmp. Если подключиться нельзя из-за отсутствия файла разъема, проблему можно легко решить посредством простой перезагрузки сервера. В процессе запуска он воссоздаст этот файл. Проблема заключается в том, что использовать этот разъем для установления соединения с сервером нельзя. Для этого необходимо установить соединение TCP/IP. Например, если сервер запускается на компьютере с адресом v i p e r. s n a k e. n e t, подключиться к нему можно с помощью следующей команды:
% 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 Часть III. Администрирование MySQL Как видите, имя файла и путь к нему одинаковы как для сервера, так и для клиентских программ, в результате чего все они используют один файл разъема. Можно определить новый путь только для сервера, благодаря чему клиентские программы будут искать этот файл по старому адресу. Перезапустите сервер после внесения изменений, чтобы создать файл разъема в новой позиции. Иногда администратор не может подключиться к серверу из-за того, что забыл пароль пользователя root или в процессе изменения случайно присвоил ему не то значение, которое предполагал. В этом случае необходимо восстановить контроль над сервером, чтобы заново установить пароль. Это можно сделать следующим образом Х Завершите работу сервера. Зарегистрировавшись как пользователь root на компьютере с сервером, администратор может завершить работу сервера с помощью команды kill. Используя команду ps, можно отыскать ID-номер процесса сервера. С этой же целью можно просмотреть PlD-файл, который обычно располагается в каталоге данных. Лучше сначала попытаться завершить работу сервера с помощью обычной команды k i l l, чем сразу посылать серверу сигнал TERM и проверять, правильно ли он отреагировал на нее, завершив работу. В этом случае все таблицы и журналы будут обработаны и закрыты корректно. Если в работе сервера не все нормально и он не отвечает на сигнал завершения работы, можно воспользоваться командой k i l l -9 для принудительного закрытия. Однако к ее помощи следует прибегать в самую последнюю очередь, поскольку в этом случае существует риск оставить таблицы поврежденными. Если работа сервера все же была завершена с помощью команды kill -9, настоятельно рекомендуется перед следующим запуском сервера проверить таблицы с помощью команд myisamchk и isamchk (см. главу 13, "Поддержка и восстановление баз данных"). Х Перезапустите сервер с помощью опции Чskip-grant-tables. Это укажет серверу не использовать таблицы разрешений для проверки соединений и позволит подключиться с полномочиями пользователя root без пароля. После удачного подключения измените пароль пользователя root Как это сделать, рассказывается в разделе "Защита новой инсталляции MySQL" ранее в этой главе. Х Используя команду mysqladmin flush-privileges, укажите серверу снова перезагрузиться, но с применением таблиц разрешений. Если используемая версия mysqladmin не поддерживает опцию flushprivileges, попробуйте воспользоваться командой reload.
Глава 11. Общее администрирование MySQL Управление пользовательскими учетными записями В обязанности администратора 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 проще, чем непосредственно редактировать таблицы разрешений. Однако для более полного понимания представленного здесь материала рекомендуется также прочитать главу 12, "Безопасность", в которой детально описываются таблицы разрешений. Роль этих таблиц действительно велика, и администратор должен понимать, каким образом их обрабатывают операторы GRANT и REVOKE. Далее в этом разделе рассказывается, как создавать учетные записи пользователей MySQL, присваивать или удалять их привилегии, а также полностью удалять пользователей из таблиц разрешений. В конце раздела описана также одна связанная с привилегиями "головоломка", которая может завести в тупик многих начинающих администраторов MySQL. 490 Часть III. Администрирование MySQL Некоторые пользователи захотят также познакомиться со сценариями inysqlaccess и mysql_setpermission, которые являются частью дистрибуции MySQL. Они представляют собой Perl-сценарии и обеспечивают альтернативу оператору GRANT, поскольку применяются для установки пользовательских учетных записей. Для использования сценария mysql_setpermission требуется инсталляция поддержки DBI. Создание новых пользователей и предоставление привилегий Оператор GRANT имеет следующий синтаксис:
GRANT privileges (columns) ON what TO user IDENTIFIED BY "password" WITH GRANT OPTION Для успешного его выполнения обязательно нужно правильно определить следующую информацию. Х privileges (привилегии). Привилегии присваиваются определенному пользователю. Используемые в операторе GRANT спецификаторы привилегий описаны в представленной ниже таблице. Спецификатор Разрешенная операция привилегий ALTER CREATE DELETE DROP INDEX INSERT REFERENCES SELECT UPDATE FILE PROCESS RELOAD Изменение таблиц и индексов Создание баз данных и таблиц Удаление существующих записей из таблиц Удаление баз данных и таблиц Создание и удаление индексов Вставка новых записей в таблицы He используется Извлечение существующих записей из таблиц Изменение существующих записей таблиц Чтение и запись файлов сервера Просмотр информации о внутренних потоках сервера и их удаление Перезагрузка таблиц разрешений или обновление журналов, кэша компьютера или кэша таблицы Глава 11. Общее администрирование MySQL SHUTDOWN ALL USAGE Завершение работы сервера Все операции. Аналог Ч ALL PRIVILEGES Полное отсутствие привилегий Спецификаторы привилегий, входящие в первую группу этой таблицы, применяются к базам данных, таблицам и столбцам. Спецификаторы второй группы определяют административные привилегии. Как правило, они используются довольно редко, поскольку позволяют пользователю влиять на работу сервера. (Не каждому пользователю, например, необходима привилегия SHUTDOWN.) В третью группу входят два отдельных спецификатора: спецификатор ALL предоставляет "все привилегии", a USAGE означает "полное отсутствие привилегий". В последнем случае создается новый пользователь, не обладающий никакими правами. columns (столбцы). Столбцы, к которым применяются определенные привилегии. Этот параметр необязателен и используется только при установке привилегий для столбцов. Имена нескольких столбцов отделяются друг от друга запятыми. what (что). Уровень применения привилегий. Привилегии могут быть глобальными (применяемыми ко всем базам данных и их таблицам), уровня баз данных (применяемыми ко всем таблицам определенной базы данных) или уровня таблицы. Используя оператор columns, можно определить также привилегии уровня столбца. user (пользователь). Пользователь, которому присваиваются привилегии. В некоторых версиях MySQL необходимо указывать как имя пользователя, так и компьютер, с которого он сможет подключаться. Такой способ задания легко позволяет определить двух пользователей с одинаковым именем, но подключающихся с разных компьютеров. Возможности MySQL позволяют их различать и наделять различными правами. Имя пользователя в некоторых версиях MySQL представляет собой имя, используемое при подключении к серверу. Оно вовсе необязательно должно быть связано с именем регистрации в ОС UNIX или Windows. Если имя пользователя MySQL не определено явным образом, клиентские программы по умолчанию используют его в качестве регистрационного имени, однако это необязательно. Не существует также каких-либо особых требований, чтобы суперпользователь MySQL, обладающий максимальными правами, имел имя root. По желанию его можно изменить в таблицах разрешений на nobody, если для выполнения определенных операций требуются его полномочия.
Часть III. Администрирование MySQL Х password (пароль). Присвоенный пользователю пароль, который не является обязательным. Если для нового пользователя опустить выражение IDENTIFIED BY, пароль ему присвоен не будет (что не совсем разумно с точки зрения безопасности). Если же этот оператор задается для уже существующего пользователя, введенный пароль заменит используемый до настоящего момента. Старый пароль останется неизменным, если новый не будет определен. Строка пароля, задаваемая с помощью выражения IDENTIFIED BY, должна представлять собой буквенную строку, которую при записи зашифрует оператор 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. В предыдущем примере его можно условно заменить фразой "любой компьютер". Установка символа "%" аналогична простому опусканию части, задающей компьютер. Другими словами, эквивалентными в данном приГлава 11. Общее администрирование MySQL мере выступят записи max и тах@%. Это самый простой и, в то же время, самый незащищенный способ создать пользователя. В случае необходимости можно также разрешить пользователю подключаться с ограниченного числа компьютеров. Так, чтобы пользователь тагу мог подключаться с компьютеров домена 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" Первый оператор определяет только один компьютер, с которого может подключиться пользователь j o e. Второй определяет набор 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 разрешено только с одного локального компьютера. Ограничение компьютеров, с которых может подключаться к серверу обладающий широкими правами пользователь, Ч весьма Часть III. Администрирование MySQL мудрое решение. В этом случае ограничивается и число компьютеров, с которых могут быть предприняты попытки взлома пароля. Некоторые привилегии (FILE, PROCESS, RELOAD и SHUTDOWN) являются административными и могут присваиваться только с помощью спецификатора глобальных привилегий ON *. *. В случае необходимости их можно присваивать без предоставления привилегий на уровне базы данных. Так, например, приведенный ниже оператор создает пользователя f l u s h, который обладает возможностью только выполнять операторы FLUSH. Это может оказаться полезным в административных сценариях, когда необходимо выполнить обновление журналов:
GRANT RELOAD ON *.* ТО flushSlocalhost 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" Первый из указанных операторов предоставляет пользователю b i l l все права для работы со всеми таблицами базы данных samp_db. Второй оператор создает пользователя ro_user с ограниченными правами (только чтение), который может получать доступ к любой таблице базы данных menagerie, однако только для чтения. Другими словами, этот пользователь имеет возможность запускать только оператор SELECT. Как определить имя локального компьютера в таблице разрешений Довольно часто пользователи не могут подключиться к серверу с основного компьютера (на котором инсталлирован сервер) из-за того, что вместо имени localhost указывают имя сервера. Эта проблема возникает по причине использования разных способов определения имен, записанных в таблицах разрешений и выдаваемых программам. Если процедура сервера выдает неполное имя, например, pit-viper, а в таблицах разрешений записано полное имя pit-viper.snake.net (или наоборот), подключение становится невозможным. Чтобы определить, имеет ли место такая проблема на используемом компьютере, попытайтесь подключиться к локальному серверу с помощью опции -ь, устанавливающей имя компьютера. Затем загляните в общий учетный файл сервера. Какое имя компьютера в нем записано, полное или неполное? Неважно, какая форма применяется. Важно использовать для определения имени компьютера в операторе GRANT именно это имя. При задании оператора GRANT можно задавать сразу несколько привилегий одновременно. Так, например, если необходимо предоставить пользователю возможность считывать и изменять содержимое сущестГлава 11. Общее администрирование MySQL вующих таблиц, но запретить создавать новые таблицы или удалять уже существующие, это можно сделать следующим образом:
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 5amp_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) и предоставлению пользователям всех возможных привилегий для работы с ней. 496 Часть 111. Администрирование MySQL Чтобы разрешить всем пользователям домена m a r s. n e t использовать базу данных tmp, достаточно ввести следующий оператор GRANT:
GRANT ALL ON tmp.* TO ""@%.mars.net После его выполнения пользователи смогут создавать и ссылаться на таблицы базы данных tmp с помощью имен типа tmp. tbl_name. (Часть 11 " в спецификаторе создает запись для анонимного пользователя, что позволяет каждому использовать эти привилегии.) Нужны ли пользователю административные привилегии Администратор МОЖе! предоставить ДЛаДеЛЬЦ> uajol да;
т^л a^oinvy/ivность управления доступом, предоставив ему все привилегии базы данных и определив опцию WITH GRANT OPTION. Так, чтобы разрешить пользователю alicia подключаться с любого компьютера домена bigcorp.com и предоставить ему административные привилегии для работы со всеми таблицами базы данных sales, необходимо использовать оператор GRANT следующего вида:
GRANT ALL ON sales.* TO alicia@%.big-corp.com WITH GRANT OPTION IDENTIFIED BY "applejuice" Фактически, предложение W I T H 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 все равно остается запись для пользователя, даже если все привилегии для него сняты. Это означает, что Глава 11. Общее администрирование MySQL пользователь все еще имеет возможность подключаться к серверу. Для полного удаления пользователя необходимо явным образом удалить его запись из таблицы 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" Назначение этого оператора Ч разрешить пользователю f red подключаться к серверу с любого компьютера домена snake.net и предоставить ему все привилегии для работы с базой данных samp_db. В результате пользователь f red получает возможность подключиться с любого компьютера, кроме собственно сервера! Попытка подключиться с сервера завершается выводом сообщения об отклонении доступа даже при предоставлении правильного пароля. Такая ситуация имеет место, если в таблице разрешений содержатся записи, по умолчанию инсталлированные сценарием инициализации mysql_install_db. Причина ее возникновения в том, что при попытке подключения пользователя f red к серверу большим приоритетом перед записью этого пользователя обладает одна из записей анонимного пользователя. Согласно этой записи, для подключения пароль не нужен, однако пользователь f red пытается его ввести. Еще одна причина этой проблемы рассматривается в разделе "Головоломка с привилегиями (продолжение)" главы 12, "Безопасность". Важно заметить, что для устранения этой проблемы достаточно удалить запись анонимного пользователя из таблицы user. Оператор REVOKE для этих целей не подходит, поскольку он отменяет только привилегии. Удаление записи выполняется с помощью следующих команд:
% mysql -u root mysql mysql> DELETE FROM user where User="";
raysql> FLUSH PRIVILEGES;
Сразу после удаления пользователь f red сможет успешно подключиться с локального компьютера.
Часть 111. Администрирование MySQL Ведение файлов журналов В процессе запуска сервер MySQL исследует опции командной строки и определяет, необходимо ли выполнять регистрацию. Если необходимо, сервер открывает соответствующие файлы журналов. Существует два основных типа журналов, которые может сгенерировать сервер по указанию администратора. Х Файл общего журнала. Он содержит информацию о подключениях клиентов, запросах и другого рода событиях. Этот файл исключительно полезен для отслеживания деятельности сервера: кто подключен, откуда и что делает. Х Журнал обновлений. Этот файл содержит запросы, изменяющие базу данных. Несмотря на название, этот журнал содержит записи не только операторов UPDATE, но и многих других, используемых для изменения базы данных, например, DELETE, INSERT, REPLACE, CREATE TABLE, DROP TABLE, GRANT И REVOKE. Содержимое Журнала обновлений представлено в виде операторов SQL. Форма записи этих операторов позволяет использовать их для ввода в mysql. В комбинации с резервированием этот журнал становится эффективным средством восстановления таблиц после сбоя. Достаточно восстановить базу данных из файлов архива, а затем запустить повторно все запросы на изменение базы данных с момента последней архивации, используя записи журнала обновлений в качестве ввода для mysql. Эти действия позволят восстановить таблицы в состояние, в котором они находились перед самым сбоем. Для активизации процесса регистрации используются опции --log и --log-update. Первая приводит к созданию и ведению общего журнала, вторая Ч журнала обновлений. Эти опции можно определить в командной строке при запуске сценариев mysqld, safe_mysqld или mysql. server, а также в группе [mysqld] конфигурационного файла. При активизации регистрации файлы журналов по умолчанию записываются в каталоге данных сервера. При первом запуске сервера MySQL рекомендуется активизировать оба типа регистрации. Впоследствии можно оставить только журнал обновлений, чтобы уменьшить объем занимаемого дискового пространства. Активизировав регистрацию, необходимо периодически проверять диск, чтобы он не заполнился огромным количеством регистрационной информации. Особенно это касается загруженных серверов, обрабатывающих большое число запросов. Рекомендуется периодически удалять и заменять файлы журналов, чтобы всегда иметь самую последнюю учетную информацию и в то же время не позволять файлам журналов разрастаться до огромных размеров. Глава 11. Общее администрирование MySQL Ротация файлов журналов выполняется следующим образом. Предположим, файл журнала имеет имя log. На первом этапе он переименовывается в log. О, и сервер приступает к записи нового файла log. На втором этапе файл log. О переименовывается в log. 1, файл log Ч в log. О, а сервер приступает к записи нового файла log. В этом случае каждому файлу последовательно присваиваются имена log. О, l o g. 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. Часть III. Администрирование MySQL mv Sbase.3 mv $base.2 mv $base.l mv Sbase.O mysgladmin 5base.4 $base.3 $base.2 Sbase.l flush-logs Лучше всего запускать этот сценарий под учетной записью mysqladm, поскольку именно этот пользователь является владельцем файлов журналов. Если параметры подключения хранятся в конфигурационном файле. m y. c n f, определять какие-либо параметры в команде mysqladmin этого сценария не нужно. В любом другом случае, возможно, имеет смысл создать пользователя с ограниченными привилегиями, который сможет только запускать команды FLUSH. Размещение пароля этого пользователя в сценарии не повлечет за собой большого риска. Такому пользователю следует присвоить только привилегию RELOAD. Так, для вызова пользователя f l u s h и присвоения ему пароля f l u s h p a s s воспользуйтесь следующим оператором GRANT:
GRANT RELOAD ON *.* TO flush@localhost IDENTIFIED BY "flushpass" Запуск процедуры заполнения в сценарии можно реализовать с помощью следующей команды:
mysqladmin -u flush -pflushpass flush-logs На компьютерах, работающих под управлением ОС Linux, лучше воспользоваться командой logrotate и инсталлировать сценарий mysqllog-rotate, входящий в состав дистрибуции MySQL, чем писать свой собственный сценарий. Если этот сценарий не инсталлирован по умолчанию RPM-файлом, поищите его в каталоге support-files дистрибуции MySQL. Ротация журналов обновлений немного отличается от ротации общих журналов, что объясняется своеобразным способом обработки сервером имен файлов журнала обновлений. Как уже отмечалось ранее, если администратор указывает серверу имя файла журнала обновлений без расширения, например, update, сервер автоматически генерирует имена журналов, согласно последовательности update. 001, update. 002 и т.п. Новый файл журнала создается каждый раз при запуске сервера или заполнении старого журнала. Если при активизации регистрации администратор вовсе не указывает имя файла для журнала, сервер генерирует такую же последовательность, выбирая в качестве основной части имени файла имя локального компьютера. Удалять сгенерированные таким образом файлы лучше бы, конечно, учитывая период их создания, а не порядковый номер имени. Основная причина такого подхода заключается в том, что администратор не в состоянии точно проследить, когда сервером выполняются команды flush-logs. Соответственно и невозможно подсчитать точно число журналов обновлений, сгенерированных за определенный период времеГлава 11. Общее администрирование MySQL ни. Так, например, файл журнала обновлений с новым именем создается каждый раз при резервировании таблиц с помощью команды mysqldump и опции --flush-logs. Сценарий последовательного удаления журналов обновлений с порядковыми именами, автоматически создаваемыми сервером, может выглядеть следующим образом: #! /bin/sh find DATADIR -name "update. [0-9]*" -type f -mtime +6 | xargs rm -f mysqladmin flush-logs Команда find находит и удаляет все файлы журналов обновлений, измененные более чем неделю назад. Очень важен ее аргумент -name, который проверяет цифровое расширение имени файла и позволяет избежать случайного удаления таблицы с именем update. В случае необходимости можно настроить сервер на использование постоянного имени файла журнала обновлений, для чего достаточно определить имя с расширением. В этом случае выполнять ротацию журналов обновлений можно так же, как и общих журналов. Так, например, запуск сервера с опцией Чlog-update=update. log приведет к использованию файла журнала с именем update.log. Сервер будет все закрывать и открывать файл журнала каждый раз при получении команды flush-logs, однако создаваться новый файл не будет. Соответственно, сценарий ротации журналов обновлений будет отличаться от сценария ротации общих журналов только именем файла. Для автоматической ротации и удаления лишних журналов можно воспользоваться командой с г on. Предположим, что сценарии ротации общих журналов и журналов обновлений называются rotate-logs и rotateupdate-logs и инсталлированы в каталоге /usr/users/mysql/bin. Зарегистрируйтесь в качестве пользователя mysqladm и выполните следующую команду редактирования файла crontab пользователя mysqladm: % crontab -e Эта команда позволяет отредактировать копию текущего файла crontab (который может быть вообще пустым, если ранее не редактировался пользователем). Добавьте в этот файл следующие строки: О 4 * * * /usr/users/mysqladm/bin/rotate-logs О 4 * * * /usr/users/mysqladm/bin/rotate-update-logs Эти команды указывают серверу автоматически запускать сценарии каждые сутки в 4 часа утра. Время и сутки в случае необходимости можно изменить. Рекомендуется ознакомиться с инструкциями по работе этого файла в справочном руководстве по системе.
Часть III. Администрирование MySQL Резервирование и копирование баз данных Администратор должен обязательно резервировать базы данных на случай повреждения или потери данных. Только благодаря резервированию все таблицы могут быть восстановлены в прежнее состояние в случае сбоя в работе системы. Кроме того, не исключен вариант, когда резервирование может оказаться единственным путем отступления, если какой-либо неопытный пользователь случайно выполнит операторы DROP DATABASE или DROP TABLE. Иногда сбой может произойти по вине собственно администратора MySQL. Так, автору этой книги известны случаи, когда администраторы разрушали файлы таблиц, пытаясь изменить их с помощью таких редакторов, как vi или emacs. Это далеко не самый лучший способ отредактировать таблицы! Существует два основных способа резервирования баз данных: использование программы mysqldump и непосредственное копирование файлов базы данных (с помощью команд ср, tar или cpio). Каждый метод имеет свои преимущества и недостатки. Х Программа mysqldump тесно взаимодействует с сервером MySQL. Методы непосредственного копирования являются внешними по отношению к серверу и требуют проверки, чтобы клиенты не пытались изменить таблицы баз данных в процессе копирования. Эта же проблема имеет место при использовании для резервирования баз данных средств резервирования файловой системы. Если в процессе резервирования кто-то из пользователей изменяет таблицы, их файлы окажутся несовместимыми и не подлежащими восстановлению. Разница между резервированием файловой системы и непосредственным копированием файлов заключается в том, что в первом случае имеется возможность управлять расписанием резервирования. Х Программа mysqldump медленней резервирует данные, чем методы непосредственного копирования. Х Программа mysqldump создает простые текстовые файлы, которые можно легко переносить на другие компьютеры, даже с другой аппаратной архитектурой. Копируемые вручную файлы не могут переноситься на другие компьютеры, если, конечно, не используется специальный формат хранения MylSAM. ISAM-таблицы могут копироваться только между компьютерами с подобной архитектурой. Так, например, копирование файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором SPARC будет успешным, чего нельзя сказать о копировании файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором Intel. ВперГлава 11. Общее администрирование MySQL вые появившийся в версии MySQL 3.23 формат хранения MylSAM решает эту проблему, поскольку является независимым от архитектуры компьютера. Соответственно, скопированные файлы можно легко переносить на другой компьютер с любой архитектурой в одном из двух случаев: на втором компьютере также запущена СУБД MySQL версии 3.23 и более поздней либо файлы таблиц представлены в формате MylSAM, а не ISAM. Независимо от выбранного метода резервирования существуют определенные принципы, которым необходимо следовать для достижения эффективных результатов. Х Регулярно выполняйте резервирование. На этапе планирования разработайте расписание и четко его придерживайтесь. Х Обязательно активизируйте регистрацию обновлений (как это сделать, рассказывается в разделе "Ведение файлов журналов", выше в этой главе). Журналы обновлений помогут восстановить базу данных после сбоя, вернее, после восстановления заархивированных файлов вернуть ее в состояние, в котором база данных находилась непосредственно перед сбоем. Для этого необходимо заново внести все изменения, сделанные с момента последнего резервирования, просто запустив запросы журнала обновлений. Согласно терминологии резервирования, заархивированные файлы баз данных представляют полный архив, а журналы обновлений Ч дополнительный. Х Используйте постоянную и легко понятную схему присвоения имен файлам архива. Имена типа backupl, backup2 и т.д. не несут никакой смысловой нагрузки. И когда приходит время восстанавливать информацию, много времени тратится на изучение их содержимого. Гораздо эффективней присваивать архивным файлам имена баз данных и дат резервирования. Например: % mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02 % mysqlduinp menagerie > /usr/archives/mysql/menagerie.1999-10-02 Иногда сразу после создания файлы архивов лучше сжать, ведь они занимают много места. Время от времени рекомендуется также удалять ненужные файлы архивов, так же как и файлы журналов, чтобы не заполнять жесткий диск ненужной информацией. Более детально эта процедура рассматривается в разделе "Ведение файлов журналов", ранее в этой главе. Описанные в ней способы можно применять и к файлам архивов. Х Резервируйте впоследствии архивные файлы MySQL с помощью средств резервирования файловой системы. В случае фатального сбоя операционной системы потерянным может оказаться не только каталог данных, но и вся остальная информация, находящаяся на жестком диске. Поэтому для большей надежности необходимо резервировать также файлы архивов и журналов обновлений. 504 Часть III. Администрирование MySQL Х Размещайте файлы архивов на отдельном диске. Это снизит вероятность переполнения этими файлами диска, содержащего каталог данных. Описанные выше методы резервирования баз данных оказываются эффективными и для копирования этих баз на другой сервер. Наиболее часто база данных переносится на другой сервер, работающий на отдельном компьютере, однако можно перенести ее в отдельный каталог для другого сервера, работающего на этом же локальном компьютере. Необходимость в этом может возникнуть после выхода новой версии MySQL, когда администратор захочет протестировать ее работу перед полным переходом, либо при установке нового более производительного компьютера, на который со временем планируется перенести все базы данных. Резервирование и копирование баз данных С ПОМОЩЬЮ Программы mysqldump При резервировании базы данных с помощью программы mysqldump создается файл, который состоит из создающих таблицы операторов CREATE TABLE и операторов INSERT с данными строк таблиц. Другими словами, в процессе работы программа mysqldump создает набор операторов, которые впоследствии можно отправить серверу mysql для воссоздания базы данных. Для резервирования целой базы данных в одном текстовом файле достаточно запустить следующую команду:
% mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10- В результате ее выполнения будет создан файл, начинающийся следующим образом:
# MySQL dump 6.О # # Host: localhost Database: samp_db _ Ч Ч # Server version 3.23.2-alpha-log # # Table structure for table 'absence' # CREATE TABLE absence( student_id int(lO) unsigned DEFAULT '0' NOT NULL, date date DEFAULT '0000-00-00' NOT NULL, PRIMARY KEY (student_id,date) );
# # Dumping data for table 'absence' # INSERT INTO absence VALUES (3,4999-09-03');
INSERT INTO absence VALUES (5,4999-09-03');
INSERT INTO absence VALUES (10,4999-09-06');
Глава 11. Общее администрирование MySQL Остальная часть файла также состоит из операторов CREATE TABLE и INSERT. Чтобы сразу после создания сжать файл архива, необходимо ввести вместо представленной выше следующую команду % mysqldump samp_db | gzip > /usr/archives/mysql/samp_db.1999-10-02.gz Результатом резервирования большой базы данных станет создание большого файла архива, с которым трудно работать. В таком случае можно зарезервировать отдельные таблицы, указав их имена после имени базы данных в строке команды mysqldump. Это приведет к созданию меньших, а следовательно, и более удобных для обработки файлов. Резервирование отдельных таблиц базы данных samp_db можно выполнить с помощью следующих команд: % mysqldump samp_db student score event absence > gradebook.sql % mysqldump samp_db member president > hist-league.sql Если создаваемые файлы архивов планируется использовать для периодического обновления содержимого другой базы данных, можно добавить В командную строку mysqldump ОПЦИЮ --add-drop-table. В этом случае в файл архива будут заноситься операторы DROP TABLE IF EXISTS. При загрузке файла архива с этими операторами в другой базе данных сообщения о существовании таблиц появляться не будут. Администраторы, управляющие двумя серверами, могут использовать этот способ для периодической загрузки данных из баз данных одного сервера в базы другого. Для переноса содержимого базы данных на другой сервер вовсе необязательно создавать файлы архива. Достаточно убедиться в существовании этой базы данных на другом компьютере, а затем создать канал (pipe), чтобы mysql смог напрямую считывать вывод команды mysqldump. Так, например, копирование базы данных с компьютера pit-viper.snake.net на boa. snake. net легко выполняется с помощью следующих команд:
% mysqladmin -h boa.snake.net create samp_db % mysqldump samp_db | mysql -h boa.snake.net samp_db Чтобы впоследствии обновить информацию базы данных на компьютере b o a. s n a k e. n e t, запустите только вторую команду, добавив опцию --add-drop-table во избежание ошибок записи в уже существующие таблицы: % mysqldump --add-drop-table samp_db | mysql -h boa.snake.net samp_db В строке команды mysqladmin можно использовать и другие полезные опции. Х Комбинация опций --flush-logs и Чlock-tables полезна для контроля состояния базы данных. Первая опция закрывает и повторно открывает файлы журналов обновлений, а вторая Ч 506 Часть III. Администрирование MySQL блокирует все резервируемые таблицы. Если сервер создает журналы обновлений с порядковыми именами, каждый новый журнал будет содержать все запросы на изменение базы данных с момента ее последнего резервирования. (Блокировка таблиц закрывает доступ к базе данных пользователям, пытающимся внести изменения.) Если опция --flush-logs применяется для согласования времени создания журнала обновлений и времени резервирования, лучше архивировать сразу всю базу данных. При резервировании отдельных таблиц довольно трудно синхронизировать журналы обновлений с файлами архивов. В процессе восстановления содержимое журнала обновлений обычно извлекается для каждой базы данных отдельно. Невозможно рассортировать эту информацию еще и по таблицам, поэтому администратору это придется делать самостоятельно. Х Команда mysqldump по умолчанию перед записью таблицы в архив считывает ее всю в память. В этом, однако, нет необходимости. Более того, подобная обработка больших таблиц вообще может привести к сбою. Поэтому администратор может воспользоваться опцией --quick, определяющей построчное считывание и запись информации. Чтобы еще больше оптимизировать процесс резервирования, вместо опции Чquick можно применить опцию Чopt. Она, в свою очередь, активизирует все остальные опции, ускоряющие считывание и резервирование данных. Выполнение резервирования с помощью опции --opt Ч наиболее распространенный (благодаря скорости) метод выполнения. Однако следует проявлять осторожность, поскольку опция Чopt оптимизирует процедуру резервирования, закрывая на время доступ к базе данных. Она блокирует все таблицы сразу, запрещая внесение каких-либо изменений. Эффект от применения этой опции заметить очень легко. Попробуйте запустить команду резервирования с этой опцией днем, во время наиболее частого использования базы данных. Пользователи не заставят себя долго ждать, и скоро телефон администратора начнет звонить не переставая. Х Эффекта, прямо противоположного результатам опции -opt, можно достичь с помощью опции Чdelayed. Эта опция заставляет команду mysqldump записывать в файл архива операторы INSERT DELAYED вместо операторов INSERT. Опция Чdelayed оказывается весьма полезной, если при загрузке файла архива в другую базу данных администратор желает уменьшить влияние этой операции на выполнение текущих запросов. Х Для уменьшения передаваемого объема информации при копировании базы данных с одного компьютера на другой весьма эффективной является опция Чcompress. Однако эта опция предназнаГлава 11. Общее администрирование MySQL чается для программ, взаимодействующих с сервером удаленного, а не локального компьютера:
% mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db Команда mysqldump имеет и множество других опций. Более детально о них рассказывается в приложении Д, "Программы MySQL". Использование методов прямого копирования Второй метод резервирования баз данных и таблиц заключается в непосредственном копировании файлов таблиц. Как правило, эта процедура выполняется с помощью таких утилит, как ср, tar или cpio. В примерах этого раздела используется программа ср. Ранее уже отмечалось, что при использовании методов прямого копирования обязательно нужно убедиться, что таблицы в процессе резервирования не используются другими пользователями. Если сервер изменяет какую-либо таблицу во время копирования, ее копия окажется искаженной. Лучший способ обеспечить целостность копий Ч временно приостановить работу сервера, скопировать файлы и затем снова запустить сервер. Если ситуация не позволяет полностью остановить сервер, обратитесь к материалу главы 13, "Поддержка и восстановление баз данных". Попробуйте воспользоваться описанными в ней способами блокировки сервера при проверке таблиц. На копирование файлов накладываются те же ограничения, что и на проверку таблиц, что позволяет использовать для блокировки сервера тот же блокирующий протокол. Итак, предположим, что работа сервера временно приостановлена либо подлежащие копированию таблицы защищены от изменения. В таком случае резервирование всей базы данных samp_db в каталог резервирования (DATADIR в этом примере Ч каталог данных сервера) выполняется посредством следующих команд:
% cd DATADIR % ср -г samp_db /usr/archive/mysql Для резервирования отдельных таблиц введите следующие команды:
% cd DATADIR/samp_db % ср member.* /usr/archive/mYsql/samp_db % ср score.* /usr/archive/mysql/samp_db По завершению процедуры резервирования можно перезапустить сервер (если его работа была приостановлена) или снять блокировку с таблиц (если сервер все же работал). Для переноса зарезервированных методом прямого копирования файлов на другой компьютер достаточно еще раз скопировать их в соответствующий каталог базы данных другого компьютера. Однако прежде необходимо убедиться, что файлы соответствуют MyISAM-таблицам и оба 508 Часть III. Администрирование MySQL компьютера имеют одинаковую аппаратную архитектуру. Иначе содержимое таблицы на втором компьютере может выглядеть очень странно. Следует также проверить, что в процессе инсталляции файлов на другой компьютер пользователи сервера не пытались получить к ним доступ. Репликация баз данных Термин "репликация" может означать как простое копирование базы данных на другой компьютер, так и интерактивное обновление подобной второй базы данных при внесении изменений в основную базу данных. Если необходимо просто скопировать базу данных на другой компьютер, можно воспользоваться одним из описанных выше методов. Первые признаки возможностей интерактивного обновления появились только в версии MySQL 3.23. Пока они находятся на стадии разработки, поэтому заинтересованным администраторам следует внимательно следить за будущими версиями, чтобы не пропустить новые разработки. Восстановление данных из архивов Повреждение данных может происходить по самым разным причинам и значительно варьироваться по масштабам. В наилучшем случае поврежденными оказывается одна-две таблицы (например, если работа компьютера была внезапно завершена из-за отключения электричества) В наихудшем Ч придется восстанавливать весь каталог данных (например, если сломался и не подлежит ремонту жесткий диск). Восстановление данных может потребоваться и в некоторых других ситуациях, например, когда пользователи случайно удалят базы данных или таблицы, либо сотрут их содержимое. Независимо от причин повреждения, администратору немедленно нужно выполнить процедуру восстановления. Если таблицы не утеряны, а лишь повреждены, попытайтесь отладить их с помощью команд myisamchk и issamchk. Вполне вероятно, что проблему можно решить с их помощью, и необходимость в восстановлении файлов архивов отпадет. Процедура отладки таблиц описывается в главе 13, "Поддержка и восстановление баз данных". Если же таблицы потеряны или не подлежат отладке, самое время приступить к их восстановлению. Для восстановления используются два источника информации: файлы архива и журналы обновлений. Первые позволяют восстановить таблицы до состояния, в котором они были в момент выполнения резервирования. Однако зачастую таблицы значительно изменяются пользователями между моментами резервирования и сбоя. В такой ситуации эффективными оказываются журналы обновлений, содержащие все последние запросы на внесение изменений. Чтобы восстановить все эти изменения, достаточно запустить запросы журнала обновлений в mysql. (Именно по этой причине администратор должен обязательно включить регистрацию Глава 11. Общее администрирование MySQL обновлений. Если она не активизирована, немедленно включите, и прежде чем читать далее, создайте новый архив базы данных.) Процедура восстановления может видоизменяться в зависимости от объема информации, подлежащей воссозданию. Фактически, легче восстановить всю базу данных, чем одну таблицу, поскольку в журнал обновлений заносятся запросы на изменение именно баз данных, а не таблицы. Восстановление базы данных Сначала, если речь идет о восстановлении базы данных mysql с таблицами разрешений, необходимо запустить сервер с опцией Чskipgrant-tables. Иначе сервер выдаст сообщение о невозможности поиска таблиц разрешений. После восстановления таблиц разрешений выполните команду mysqladmin flush-privileges, чтобы заставить сервер загрузить и использовать таблицы разрешений. Х Скопируйте содержимое каталога базы данных в другое место. Оно может потребоваться в будущем для изучения оставшихся данных поврежденных таблиц. Х Загрузите базу данных, используя файлы самых последних архивов. Если эти файлы были созданы программой mysqldump, используйте их в качестве ввода в mysql. Если же восстановление информации выполняется из файлов, непосредственно скопированных из каталога базы данных (например, с помощью команд tar или ср), скопируйте их обратно в каталог данных. В последнем случае перед копированием файлов необходимо временно приостановить работу сервера, а по завершении переноса Ч снова запустить. Х Используя журналы обновлений, повторно запустите все запросы на изменение базы данных, которые были исполнены с момента последнего резервирования. Для этого содержимое журнала обновлений можно представить в качестве ввода для mysql. Если необходимо, определите опцию --one-database, чтобы сервер mysql исполнил запросы только к той базе данных, которая представляет интерес. Если для восстановления информации необходимо использовать все журналы обновлений, запустите в каталоге с этими журналами следующую команду: Х* %ls -t -r -1 update.[0-9]*Ixargs catlmysql Чone-database db_name Команда Is воспроизводит список файлов журналов обновлений, отсортированный сервером в порядке создания. (Об этом следует помнить, поскольку неаккуратное изменение имен файлов журналов может привести к восстановлению их запросов в неправильном порядке.) В большинстве же случаев используются не все, а только часть журналов обновлений. Например, если запросы к базе данных, выполненные 510 Часть III. Администрирование MySQL после последнего резервирования, хранятся в файлах с именами update. 392, update. 393 и т.д., повторно запустить их можно с помощью следующих команд:
% mysql Чone-database db_name < update.392 % mysql --one-database db_narae < update. Если процедура восстановления применяется для устранения результатов случайного выполнения операторов DROP DATABASE, DROP TABLE или DELETE, не забудьте перед запуском команды удалить эти операторы из журнала! Восстановление отдельных таблиц Восстанавливать отдельные таблицы сложней. Если для восстановления применяется файл архива, созданный утилитой mysqldump и содержащий данные для множества таблиц, администратору придется извлечь из него строки, соответствующие требуемой таблице, и использовать их в качестве ввода для mysql. Это самая легкая часть процедуры восстановления. После нее необходимо из журнала обновлений извлечь записи, соответствующие требуемой таблице. Для выполнения этой процедуры весьма полезной может оказаться утилита mysql_f ind_rows, возможности которой позволяют извлекать многострочные запросы из журнала обновлений. Еще один вариант Ч восстановить всю базу данных на другом сервере, а затем скопировать нужную таблицу в исходную базу данных. Эта процедура гораздо проще! Необходимо лишь убедиться, что работа сервера с исходной базой данных приостановлена в процессе копирования файлов в исходную базу. Настройка сервера На работу сервера MySQL влияет несколько основных параметров (переменных). Если установленные по умолчанию значения этих параметров не полностью соответствуют среде работы сервера, администратор может их изменить. Так, например, пользователи компьютеров с большим объемом памяти могут указать серверу, что необходимо увеличить буферы для операций с диском и индексами. В этом случае в память будет загружаться больше информации, что резко уменьшит число обращений к диску. Если же возможности системы более ограничены, желательно указать, чтобы сервер использовал меньшие буферы, чтобы ресурсы системы не использовались неэффективно в ущерб другим процессам. Для исследования текущих значений переменных сервера выполните команду mysqladmin variables. Установить значения переменных можно с помощью опции Чset-variable var_name=value командной строки (или опции -0 var_name=value). Для установки значений нескольких переменных необходимо использовать несколько опций Чset-variable. Глава 11. Общее администрирование MySQL Кроме того, настроить значения этих параметров можно и в группе [mysqld] конфигурационного файла, используя следующий синтаксис:
set-variable=var_name=value Полный список переменных сервера представлен в приложении А, "Получение и инсталляция программного обеспечения", в описании программы mysql. В этом же разделе рассматриваются переменные сервера, применяемые при настройке его производительности. Дополнительную информацию по этому вопросу можно найти в справочном руководстве по MySQL. Х back_log. Число запросов на подключение клиентов, размещаемых в очереди при обработке сервером запросов текущих клиентов. Администраторам весьма сильно загруженных узлов следует увеличить значение этой переменной. Х delayed_queue_size. Эта переменная определяет число строк оператора INSERT DELAYED, размещаемых в очереди. Если очередь заполнена, последующие операторы INSERT DELAYED блокируются до освобождения очереди. В результате клиенты временно не могут запускать эти операторы. Если подобного рода дополнение делает большое количество клиентов и администратор замечает, что их запросы весьма часто блокируются, имеет смысл увеличить значение этой переменной, чтобы ускорить обслуживание клиентов. (Оператор INSERT DELAYED подробно описывается в разделе "Проблемы планирования и блокировки" главы 4, "Оптимизация запросов".) Х fiush_time. Если рабочая система подвержена систематическим сбоям и довольно часто перезагружается, установите значение этой переменной больше единицы. В этом случае сервер будет обновлять кэш таблиц каждые f lush_time секунд. Подобная запись изменений таблиц негативно отразится на производительности системы, однако в то же время значительно снизит вероятность потери или повреждения данных таблицы. На компьютерах с ОС Windows можно запускать сервер с опцией командной строки Чflush, в результате чего изменения таблицы будут сохраняться после каждого обновления. Х key_buf fer_size. Эта переменная определяет размер буфера, используемого для хранения блоков индексов. Увеличение ее значения приведет к более быстрому созданию и изменению индексов. Чем больше значение этой переменной, тем выше вероятность того, что MySQL найдет ключевые значения в памяти. Следовательно, уменьшается и число обращений к диску, необходимое для обработки индексов. В версиях, предшествующих MySQL 3.23, эта переменная имеет название key_buffer. Системы MySQL версий 3.23 и выше распознают оба названия. 512 Часть III. Администрирование MySQL Х max_allowed_packet. Максимальный размер буфера для обмена информацией с одним клиентом. Значение этой переменной рекомендуется увеличить, если клиенты в процессе работы отправляют большие значения BLOB и TEXT. В настоящее время для клиентов по умолчанию используется буфер размером 24 Мбайта. В более старых версиях размер буфера меньше, поэтому при использовании их, возможно, имеет смысл его увеличить. Так, например, для определения лимита в 24 Мбайта можно воспользоваться следующей командой: mysql --set-variable max_ailowed_packet=24M Х max_connections. Максимальное количество одновременных клиентских соединений сервера. Администраторам сильно загруженных серверов следует увеличить значение этой переменной. Так, например, если сервер MySQL используется Web-сервером для обработки запросов DB1- и PHP-сценариев и объем Webданных очень велик, установка низкого значения этого параметра приведет к отклонению запросов многих пользователей. Х table_low. Эта переменная определяет размер кэша таблиц. Увеличение этого значения позволит mysql держать открытыми большее число таблиц, что уменьшает число открытий и закрытий файлов. При увеличении значений переменных max_connections или table_cache серверу понадобится большее число дескрипторов файлов. С этим могут возникнуть проблемы, если в операционной системе установлены жесткие ограничения по числу дескрипторов файлов на один процесс. Это ограничение необходимо либо увеличить, либо попытаться обойти другим способом. Способы увеличения числа дескрипторов могут быть разными. Можно, например, воспользоваться командой u l i m i t сценария запуска сервера, либо вовсе перенастроить сервер. Для подобной настройки в некоторых системах достаточно просто отредактировать системный файл описания и перезагрузиться. В других операционных системах для этого же придется редактировать файл описания ядра или перестраивать ядро. Как действовать в каждом конкретном случае, лучше узнать в справочном руководстве по операционной системе. Еще один способ обойти ограничение на число дескрипторов файлов Ч разбить каталог данных на несколько каталогов и запустить несколько серверов. Число дескрипторов файлов, доступных для нескольких запущенных серверов, значительно увеличится. Такой подход, однако, чреват другими осложнениями. Так, пользователи не смогут получить доступ с одного сервера к базам данных разных каталогов, что потребует переноса одинаковых привилегий в таблицах разрешений всех серверов для пользователей, которым необходим доступ сразу к нескольким серверам. Существуют еще две переменные, значения которых администр;
и оры иногда увеличивают в надежде на повышение производительности работы Ч r e c o r d _ b u f f e r и s o r t _ b u f f e r. Эти буферы используются в проГлава 11. Общее администрирование MySQL J7 цессе операций объединения и сортировки данных, и их значения определяют размер буфера для одного клиентского соединения. Таким образом, каждый клиент получает свой собственный буфер. Если значения этих переменных установить достаточно большими, производительность системы может снизится из-за неэффективного распределения ресурсов. Чтобы настроить эти переменные, просмотрите сначала их текущие значения с помощью команды mysqladmin variables, а затем незначительно увеличивайте (или уменьшайте) их. В этом случае можно достичь наибольшего эффекта без серьезного снижения производительности.
Запуск нескольких серверов Большинство пользователей предпочитают запускать один сервер MySQL на одной машине, однако в некоторых случаях (описанных далее) возникает необходимость в запуске сразу нескольких серверов. Х Администратор желает протестировать новую версию сервера, прежде чем полностью перевести под его управление всех пользователей. В этом случае запускаются, как правило, несколько разных версий одного сервера. Х Операционные системы обычно накладывают ограничения по числу дескрипторов файлов на один процесс. Если увеличить это значение невозможно, обойдите данное ограничение посредством запуска нескольких серверов. (Повышение лимита, например, может потребовать перекомпиляции ядра, однако довольно часто администратор MySQL не является сразу и администратором компьютера, что делает невозможным такую компиляцию.) В этом случае, как правило, запускаются несколько серверов одной версии. Х Провайдеры услуг Internet зачастую обеспечивают своих клиентов собственными инсталляциями MySQL, для которых вовсе необязательно выделять отдельные серверы. В таком случае достаточно запустить несколько образцов одной версии сервера или нескольких версий, если клиенты используют разные версии MySQL Безусловно, запустить несколько серверов сложней, чем запустить один. Недостаточно установить несколько версий одного продукта в разные каталоги. Ведь при запуске нескольких серверов определенные параметры должны быть уникальными для каждого сервера. Некоторые из них определяют местоположение инсталляции сервера, имя и путь каталога данных, номер порта TCP/IP, имя и путь доменного разъема UNIX, а также учетную запись UNIX, используемую для запуска сервера (если, конечно, все серверы не работают под управлением одной учетной записи). Администратор, управляющий сразу несколькими серверами, должен обязательно записать все значения параметров серверов, иначе он может со временем забыть их. 514 Часть III. Администрирование MySQL Инсталляция и настройка нескольких серверов Инсталлируемые на одном компьютере разные версии одного сервера следует размещать в различных каталогах. В процессе инсталляции двоичных (не RPM-) дистрибуций все файлы размещаются в каталоге, название которого включает номер версии. Наиболее простой способ отделить дистрибуции при инсталляции с исходного кода Ч воспользоваться опцией --with-prefix при запуске команды configure в процессе инсталляции каждой версии MySQL. Это приведет к инсталляции всех файлов в одном каталоге, который можно разделить по номерам версий. Настроить дистрибуцию MySQL можно с помощью следующей команды (version Ч номер версии MySQL): %./configure Чwith-prefix=/usr/local/mysql~version В этом примере опция Чwith-prefix определяет уникальный каталог данных для сервера. С помощью дополнительных опций можно определить и другие значения параметров сервера, как-то номер порта TCP/IP или имя пути разъема (опции Чwith-tcp-port и Чwithunix-socket соответственно). При запуске нескольких вариантов одной двоичной дистрибуции сервера все опции параметров сервера необходимо устанавливать во время загрузки. Процедуры запуска нескольких серверов Настроить работу нескольких серверов сложней, чем работу одного, поскольку сценарии safe_mysqld и m y s q l. server лучше всего работают в среде одного сервера. Настоятельно рекомендуется подробно разобраться в работе сценария safe_mysqld и использовать его в качестве основы процедуры запуска. Для этих целей, однако, следует использовать измененные копии, которые можно более точно настроить в соответствии со своими потребностями. Основная проблема, с которой сталкивается администратор в такой ситуации, Ч определение параметров в конфигурационном файле. Файл /etc/my, cnf невозможно использовать для установок, изменяющихся для разных одновременно работающих серверов. В этом файле можно определять только установки, значения которых одинаковы для всех серверов. Если каждый устанавливаемый сервер размещается в своем каталоге данных, можно определить параметры каждого сервера в файле my. cnf, размещенном в соответствующем каталоге данных. Другими словами, используйте файл /etc/my, cnf для общих установок всех серверов и файл DATADIR/my.cnf, где DATADIR Ч каталог данных каждого сервера, Ч для определения специфических параметров отдельных серверов. Еще один способ определения опций сервера заключается в использовании в качестве первой опции командной строки ЧdefaultsГлава 11. Общее администрирование MySQL file=path_name, которая указывает серверу считать опции из файла path_name. Это позволяет поместить все опции отдельных серверов в соответствующие файлы, которые будут считываться в момент загрузки. Заметьте, выбор этого варианта не требует использования таких глобальных конфигурационных файлов, как /etc/my.cnf. Обновление MySQL Первая представленная мировой общественности версия сервера MySQL имела номер 3.11.1. В настоящее время применяются версии серии 3.22 и ведется разработка и тестирование версий серии 3.23. Официально выпущенные версии (stable releases) всегда имеют номер, меньший на единицу по сравнению с опытными версиями (development series). Как только серия 3.23 станет официальной, продолжится работа над серией 3.24, которая тут же получит название опытной. Разработчики MySQL, очевидно, работают безустанно, благодаря чему обновления к версиям появляются постоянно (несколько раз в год). Причем выпускаются обновления как для официальных серий, так и для опытных. Эффективность развития заставляет администратора MySQL задумываться, обновлять ли используемую инсталляцию MySQL при выпуске новых версий. Информация этого раздела помогает найти ответ на данный вопрос. Первое, на что следует обратить внимание, Ч это отличие новой версии от предыдущих. Обратитесь к соответствующему разделу справочного руководства по MySQL, в котором выделена эта информация. Затем попытайтесь ответить на следующие вопросы. Приходилось ли в прошлом сталкиваться с проблемами, которые устраняются в новой версии? Х Добавлены ли в новую версию возможности, которые действительно необходимы? Х Повышена ли в новой версии эффективность выполнения часто используемых операций? Если все ответы на представленные выше вопросы отрицательны, особых причин обновлять версии нет. Если же ответ хотя бы на один вопрос утвердительный, следует еще немного подумать. Настоятельно рекомендуется на данном этапе хотя бы несколько дней подождать и в посвященной MySQL рассылке поискать отзывы других пользователей о новой версии. Эффективным ли было для них обновление? Какие ошибки и недоработки найдены? На принимаемое решение могут оказать влияние и следующие факторы. Х Обновления официально используемых версий чаще всего устраняют существующие ошибки, а не добавляют новые возможности. Поэтому обновления официальных версий несут в себе меньше риска, чем обновления опытных. (Безусловно, работающие на сер516 Часть III. Администрирование MySQL Х вере опытной серии администраторы зачастую вовсе не беспокоятся о подобном риске.) Х Вполне возможно, что после обновления MySQL возникнет необходимость и в обновлении других программ, связанных с клиентской библиотекой сервера MySQL. Так, например, обновление MySQL может повлечь за собой перестройку модулей PHP, Apache и Perl DBD: :mysql для установления связи новых клиентских библиотек с этими программами. (Первый признак необходимости в этом Ч выгрузка всех связанных с MySQL сценариев DBI и РНР после обновления MySQL.) Перестройка этих программ Ч несложная задача, однако если администратор все же желает ее избежать, возможно, лучше отказаться от обновления MySQL. Эта проблема не так опасна, если использовать статически, а не динамически связанные программы. Однако в этом случае повышаются требования к системной памяти. Если даже после учета всех этих моментов отсутствует однозначный ответ, что следует обновлять текущую инсталляцию, всегда можно протестировать новый сервер, установив его рядом с текущим. Его можно запустить параллельно с рабочим сервером или инсталлировать на отдельном компьютере. Если же возможности не позволяют выделить отдельный компьютер исключительно для тестирования, инсталлируйте новый сервер на одном компьютере с рабочим. В этом случае обязательно убедитесь, что для нового сервера установлены другие значения для таких параметров, как месторасположение инсталляции, каталог данных, номер сетевого порта и разъем, через которые осуществляется подключение к серверу. Более детально об этом рассказывается в разделе "Инсталляция и настройка нескольких серверов" ранее в этой главе. Независимо от места инсталляции сервера, создайте для проверки его работы копию существующих баз данных. Как это сделать, рассказывается в разделе "Резервирование и копирование баз данных". Приняв решение об обновлении версии, поищите в справочном руководстве по MySQL обязательные инструкции по обновлению. Не бойтесь использовать опытные серии Опытные версии серверов большинство администраторов стараются не использовать для работы с основными базами данных, однако, профессионалы настоятельно рекомендуют по крайней мере протестировать работу такого опытного сервера, установив его отдельно и создав на нем копию рабочих данных Чем больше пользователей попробуют работать с этими версиями, тем больше ошибок будет найдено. Поиск ошибок в MySQL Ч важный фактор развития системы, поскольку разработчики всегда стараются устранить проблемы, о которых сообщают пользователи.
Глава 11. Общее администрирование MySQL 1 Безопасность В этой главе основное внимание уделяется действиям администратора, направленным на поддержание безопасности и целостности инсталляции MySQL. В главе 11, "Общее администрирование MySQL", уже были затронуты такие важные аспекты безопасности, как установка пароля основного MySQL-пользователя root и настройка учетных записей пользователей. Однако в предыдущей главе эти вопросы рассматривались как часть процесса инсталляции и запуска. В этой же главе детально описываются следующие моменты Почему безопасность так важна и от каких видов атак следует защищаться в первую очередь. Х Какой риск несет в себе подключение пользователей локального компьютера (внутренняя безопасность) и как его минимизировать. Х Какой риск несет в себе подключение пользователей к серверу через сеть (внешняя безопасность) и как его минимизировать. Администратор MySQL полностью отвечает за безопасность содержимого баз данных, поэтому должен позаботиться о том, чтобы доступ к их записям пользователи получали только после жесткой авторизации. Необходимо обеспечить как внутреннюю, так и внешнюю безопасность. Х Часть III. Администрирование MySQL Внутренняя безопасность связана с выполнением действий на уровне файловой системы Она обеспечивает защиту каталога данных MySQL от атак пользователей, работающих на том же компьютере, на котором запущен сервер Нет смысла долго настраивать таблицы разрешений, контролирующие доступ клиентов через сеть, если из-за неправильно установленных полномочий каталога данных любой локальный пользователь может заменить файлы этих таблиц! Внешняя безопасность предназначена для управления внешними клиентскими соединениями, а соответственно необходима для защиты доступа к серверу MySQL через сетевые соединения. Таблицы разрешений MySQL должны быть настроены таким образом, чтобы доступ к базам данных предоставлялся только после правильного ввода имени и пароля. В этой главе рассматриваются все описанные выше вопросы, а также приведены инструкции, выполнение которых позволит заблокировать неавторизированный доступ как изнутри, так и извне системы. Внутренняя безопасность: защита доступа к каталогу данных Сервер MySQL включает гибкую систему привилегий, реализованную через таблицы разрешений базы данных mysql. Изменяя содержимое этих таблиц, можно предоставлять или запрещать доступ определенным клиентам. Именно таким образом обеспечивается защита от неавторизированного сетевого доступа к данным. Однако нет смысла тратить много времени и усилий на обеспечение надежной защиты баз данных от доступа сетевых пользователей, если локальный пользователь, работающий на компьютере с сервером наряду с администратором, сможет легко просматривать и изменять содержимое каталога данных. Этот вид защиты можно проигнорировать, лишь будучи полностью уверенным, что никто другой не сможет зарегистрироваться и работать на компьютере, используемом для запуска сервера MySQL Максимальную защиту необходимо обеспечить следующим категориям. Х Файлы базы данных. Очевидно, что необходимо постоянно поддерживать закрытость баз данных сервера. Владельцы баз данных обычно вполне обоснованно полагают, что содержимое их баз данных закрыто для других пользователей Даже если они так не считают, все равно не стоит выставлять информацию на всеобщее обозрение или делать ее открытой из-за плохой защиты каталога данных. Х Учетные файлы. Файлы общего журнала и журнала обновлений также должны быть надежно защищены, поскольку они включают тексты запросов. Ведь любой пользователь, обладающий доступом Глава 12. Безопасность ;
'" 5 [ | |.| к файлам журналов, сможет легко отследить все транзакции с базами данных. Важность подобной защиты еще более подчеркивается тем фактом, что в файлах журналов регистрируются даже запросы с операторами GRANT и SET PASSWORD, включающие пароли. (Вообще-то, в MySQL используется шифрование паролей, однако оно применяется только после установления соединения с предварительной проверкой пароля. Процесс же установки пароля включает выполнение таких операторов, как GRANT, INSERT и SET PASSWORD. В файлы журналов они заносятся в обычной текстовой форме.) Взломщику, получившему доступ к файлам журналов, достаточно запустить команду grep, чтобы раскрыть важную информацию операторов GRANT и PASSWORD. Не следует предоставлять пользователям компьютера, на котором установлен сервер, права чтения для файлов каталога данных, поскольку они могут легко повредить файлы состояния и таблицы баз данных. Не менее опасен и доступ с правами чтения. Обладая возможностью чтения файлов таблицы, очень легко "украсть" эти файлы и позволить другому серверу MySQL самому показать содержимое таблицы в виде простого текста. Как? Да очень просто. 1. Проинсталлируйте собственную версию MySQL на компьютере с сервером, установив отдельные значения порта, разъема и каталога данных. 2. Запустите сценарий mysql_install_db для инициализации каталога данных. Это позволит получить доступ к серверу в качестве MySQL-пользователя root, получив полный контроль над механизмом доступа. Параллельно будет создана база данных test. 3. Скопируйте файлы, соответствующие "украденной" таблице или таблицам в подкаталог test каталога данных сервера. 4. Запустите второй сервер. Вот те на! Доступ к таблицам открыт. Оператор SHOW TABLES FROM test указывает на наличие копий "украденных" таблиц, а с помощью оператора SELECT * можно увидеть их содержимое. 5. Очень "злые" пользователи могут изменить полномочия учетной записи анонимного пользователя сервера, в результате чего к серверу для доступа к базе данных test сможет подключиться любой. В результате этих нехитрых действий содержимое украденных таблиц становится открытым для всех. Задумайтесь об этом. Вне всяких сомнений, ни один администратор не захочет столкнуться с такой ситуацией. Для определения, расположены ли в каталоге данных какие-либо незащищенные файлы и подкаталоги, достаточно запустить в нем команду Is -1. Найдите все файлы и каталоги, для которых активизированы 520 Часть III. Администрирование MySQL "групповые" или "другие" полномочия. Вот для примера краткий список незащищенных элементов каталога данных, среди которых встречаются и подкаталоги баз данных.
% Is -1 total 10148 drwxrwxr-x 11 mysqladm drwxr-xr-x 22 root drwx 2 mysqladm drwxrwxr-x 2 mysqladm drwxrwxr-x 7 mysqladm drwxrwxr-x 2 mysqladm drwx 2 mysqladm wheel 1024 wheel 512 mysqlgrp 512 wheel 512 wheel 512 wheel 1536 mysqlgrp May 8 12:20. May 8 13:31.. Apr 16 15:57 menagerie Jan 25 20:43 mysql Aug 31 1998 sql-bench May 6 06:11 test May 8 18:43 tmp Как видите, для доступа к одним каталогам используются правильные полномочия, для других Ч нет. Такая ситуация стала результатом использования сервера в течение долгого периода времени. Менее ограничивающие полномочия созданы более старыми версиями серверов, которые были менее жестки в отношении прав доступа, чем новые. (Обратите внимание, что наиболее ограничивающие доступ каталоги menagerie и tmp имеют более позднее время создания.) Последние версии MySQL обязательно проверят, чтобы эти файлы смогли прочитать только пользователи, под именем которых работает сервер. Давайте попробуем настроить эти полномочия, чтобы доступ к файлам мог получить только пользователь сервера. Для этого можно воспользоваться средствами защиты файловой системы UNIX и определить права владения и режим данных файлов и каталогов. Выполните следующие действия. 1. Перейдите в каталог данных: % cd DATADIR 2. Присвойте права владения всеми файлами каталога данных одной учетной записи, под управлением которой запускается сервер. (Эту операцию необходимо выполнить, зарегистрировавшись в качестве пользователя root.) В данной книге для такой учетной записи используются имя пользователя mysqladm и группы mysqlgrp. Изменить права владения можно с помощью одной из следующих команд:
# chown -R mysqladm.mysqlgrp. # find. -follow -type d -printIxargs chown mysqladm.mysqlgrp 3. Измените режим доступа к каталогу данных и каталогам баз данных, чтобы прочитать их смог только пользователь mysqladm. В результате этого доступ к каталогу данных не смогут получить другие пользователи. Изменить режим можно с помощью одной из приведенных ниже команд, зарегистрировавшись в качестве пользователя root или mysqladm (последнее предпочтительней, поГлава 12. Безопасность скольку позволяет минимизировать пользователем root):
число команд, запущенных % chmod -R go-rwx % find. -follow -type d -print | xargs chmod go-rwx 4. Теперь права владения и режим содержимого каталога данных присвоены пользователю mysqladm. Осталось убедиться, что сервер отныне будет запускаться в качестве пользователя mysqladm, поскольку только этот пользователь имеет доступ к каталогу данных. Процедура запуска сервера в качестве нового пользователя (не root) детально описана в главе 11, "Общее администрирование MySQL". После выполнения всех описанных выше действий остается лишь убедиться в правильности установки полномочий для доступа к каталогу данных.
% Is -1 total 10148 drwxrwxr-x 11 drwxr-xr-x 22 z -> drwxrwxr-x 2 7 drwxrwxr-x drwxrwxr-x 2 о mysqladm root myscjlsciiu mysqladm mysqladm mysqladm mysqlgrp wheel mysqlgrp mysqlgrp mysqlgrp mysqlgrp 1024 c-i Э 1Z 512 512 1 ПОЛ May May Apr Jan Aug May Wl=l!
т с. c.-j menagerie 1 1D 10. D / 25 20:43 mysql 31 1998 sql-bench 6 06:11 test Q 8 12:20 13: Л Q. ЛТ Внешняя безопасность: защита сетевого доступа Система безопасности MySQL достаточно гибка, поскольку позволяет настроить привилегии доступа пользователей множеством различных способов. Как правило, установка привилегий реализуется с помощью операторов GRANT и REVOKE, которые изменяют таблицы разрешений, управляющие клиентским доступом. Некоторые администраторы, тем не менее, все еще используют старые версии MySQL, которые не поддерживают эти операторы (до версии MySQL 3,22.11). Иногда также администраторы замечают, что при установке с помощью операторов GRANT и REVOKE привилегии функционируют не так, как хотелось бы. В подобных ситуациях весьма полезным может оказаться знание таблиц разрешений MySQL и принципов использования их сервером для определения полномочий. Владеющий подобными знаниями администратор может добавлять, удалять или изменять привилегии пользователей посредством изменения собственно таблиц разрешений. Более того, исследование таблиц позволяет гораздо быстрей диагностировать проблемы, связанные с доступом.
Часть III. Администрирование MySQL Автор предполагает, что читатель уже ознакомился с материалом раздела "Управление пользовательскими учетными записями" главы 11, "Общее администрирование MySQL", и разобрался в принципах работы операторов GRANT и REVOKE. Их применение Ч удобный способ установки пользовательских учетных записей MySQL и связанных с ними привилегий. Хотя эти операторы являют собой лишь оболочку. Реальные действия выполняются в таблицах разрешений сервера MySQL. Структура и содержимое таблиц разрешений MySQL Управление доступом к базам данных MySQL для клиентов, подключившихся к серверу через сеть, осуществляется с помощью содержимого таблиц разрешений. Эти таблицы входят в состав базы данных mysql и инициализируются в процессе инсталляции MySQL на компьютере (процесс инсталляции детально описывается в приложении А, "Получение и инсталляция программного обеспечения"). В табл. 12.1 и 12.2 представлено краткое описание структур пяти таблиц разрешений: user, db, host, tables_priv И columns_priv. Таблица 12.1. Структура таблиц разрешений user, db и host Столбцы области доступа user Host User Password db Host host Host Db User Db Столбцы привилегий базы данных/таблицы Alter priv Create priv Delete priv Drop priv Index priv Insert priv References priv Select priv Update priv Alter priv Create priv Delete priv Drop priv Index priv Insert priv References priv Select priv Update_priv Alter priv Create priv Delete priv Drop priv Index priv Insert priv References priv Select priv Update priv Глава 12. Безопасность Окончание табл. 12.1 Столбцы административных привилегий File_priv Grant_priv Process_priv Reload_priv Shutdown_priv Таблица 12.2. Структура таблиц привилегий tables_priv И corumns_priv Столбцы области доступа tables_priv Host columns_priv Host Grant_priv Grant_priv Db User Table_name Column_name Db User Table_name Столбец привилегий Table_priv Column_priv Таблицы разрешений содержат следующую информацию. Х user. Таблица user содержит список всех пользователей, которые могут подключаться к серверу, а также их пароли и все глобальные привилегии, если таковые применяются. Все указанные в этой таблице привилегии являются глобальными и применимы ко всем базам данных. Так, например, если активизировать в этой таблице привилегию DELETE, соответствующий пользователь сможет удалить записи из любой таблицы. Следовательно, необходимо тщательно все обдумать, прежде чем присваивать такую привилегию. Х db. Таблица db содержит список всех баз данных и пользователей, обладающих полномочиями на доступ к ним. Определенные в этой таблице привилегии применимы ко всем таблицам соответствующей базы данных.
Х host. Таблица host используется вместе с таблицей db и определяет привилегии доступа к базам данных определенного компью524 Часть III. Администрирование MySQL тера. Уровень этого контроля более высокий, чем при использовании одной лишь таблицы db. Операторы GRANT и REVOKE не могут изменять содержимое этой таблицы, поэтому на некоторых компьютерах она вообще не используется. Х tables_priv. Таблица tables_priv определяет привилегии доступа к таблицам. Эти привилегии применимы ко всем столбцам определенной таблицы. Х columns_priv. Таблица columns_priv определяет привилегии доступа к столбцам. Эти привилегии применимы к отдельным столбцам соответствующей таблицы. В расположенном далее разделе "Установка пользователей без помощи оператора GRANT" рассказывается, как оператор GRANT изменяет информацию этих таблиц и как с помощью непосредственного редактирования аналогичных результатов может достичь администратор. Таблицы tables_priv и colums_priv впервые появились в MySQL версии 3.22.11 (вместе с оператором GRANT). Поэтому администраторы старых версий MySQL могут найти в базе данных mysql своего сервера только таблицы user, db и host. Если же эти таблицы не появляются даже после обновления до версии 3.22.11 или более поздней, запустите для их создания сценарий mysql_f ix_privileges_tables. Отсутствие таблицы row_priv объясняется невозможностью предоставления в MySQL привилегий на уровне строк. Нельзя, например, предоставить пользователю доступ только к отдельным строкам таблицы. Обеспечить подобную возможность реально можно только посредством написания соответствующей программы. Для блокировки данных на уровне записей можно использовать функцию GET_LOCK (}, описанную в приложении В, "Операторы и функции". Таблицы разрешений содержат столбцы двух видов: столбцы области, определяющие область применения записи, и столбцы привилегий, определяющие присваиваемые привилегии. (Некоторые таблицы разрешений включают и другого рода столбцы, однако здесь они не рассматриваются.) Столбцы области применения таблицы разрешений Столбцы области применения таблицы разрешений определяют, когда же применяются записи таблиц. Каждый элемент таблицы разрешений включает значения столбцов User и Host. Эти значения определяют, что данный элемент применяется при подключении определенного пользователя (User) к определенному компьютеру (Host). (Таблица Host является исключением в этом отношении. Она используется особым способом, который в данном разделе не рассматривается.) Кроме того, другие таблицы могут содержать дополнительные столбцы. Таблица db, например, включает также столбец Db, определяющий базу данных, к которой применяется запись. Аналогичным обГлава 12. Безопасность разом таблицы tables_priv и columns_priv содержат поля области, которые ограничивают область применения записи до отдельной таблицы базы данных или отдельного столбца таблицы.
Столбцы привилегий таблицы разрешений Таблицы разрешений включают также столбцы привилегий. Именно они определяют, какие привилегии предоставляются описанному в столбцах области пользователю. Поддерживаемые сервером MySQL привилегии приведены в списке, представленном ниже. В этом списке указываются названия привилегий, используемые в строке оператора GRANT. В большинстве случаев названия столбцов привилегий таблиц user, db и host сходны (по очевидным причинам) с названиями привилегий, приведенными в главе 11, "Общее администрирование MySQL", в разделе, посвященном описанию оператора GRANT. Столбец Select_priv, например, соответствует привилегии SELECT. Привилегии баз данных и таблиц Для работы с базами данных и таблицами применяются следующие привилегии. Х ALTER. Позволяет использовать оператор ALTER TABLE. Вообще ALTER Ч это привилегия первого уровня. Для обработки таблиц необходимо предоставить дополнительные привилегии в зависимости от того, какие операции необходимо выполнять. Х CREATE. Позволяет создавать базы данных и таблицы, но не индексы. Х DELETE. Позволяет удалять записи из таблиц. Х Х Х Х DROP. Позволяет удалять таблицы и базы данных, но не индексы. INDEX. Позволяет создавать и удалять индексы в таблице. INSERT. Позволяет вставлять новые записи в таблицы. SELECT. Позволяет извлекать данные из таблиц с помощью операторов SELECT. Эту привилегию необязательно присваивать для исполнения операторов SELECT, не связанных с таблицами, например, SELECT N O W ( ) ИЛИ SELECT 4 / 2.
Х REFERENCES. В настоящее время не используется.
Х UPDATE. Позволяет изменять записи таблицы. Административные привилегии Следующие привилегии позволяют выполнять административные операции, управляющие функционированием сервера или дающие возможность присваивать привилегии другим пользователям.
Часть III. Администрирование MySQL Х FILE. Позволяет давать серверу задание на считывание или запись файлов. Эту привилегию рекомендуется присваивать лишь в особых случаях. Будьте внимательны (см. раздел "Как минимизировать риск при работе с таблицами разрешений"). Поэтому сервер также предпринимает определенные меры предосторожности, позволяющие установить границы применения этой привилегии. Так, пользователи могут считывать файлы, которые доступны для чтения во всей системе. Невозможно записать файл, который уже существует на диске. Это позволяет избегать путаницы с критически важными файлами сервера, например /etc/passwd, или файлами чужих баз данных. Отсутствие подобного ограничения может привести к полной замене содержимого таблиц разрешений базы данных mysql.
. i Присваивая привилегию FILE, следует обязательно убедиться, что запущенный сервер не обладает правами UNIX-пользователя root, который может создавать новые файлы в любом каталоге файловой системы. При запуске сервера под управлением учетной записи пользователя без особых привилегий создавать файлы можно будет только в доступных для такого пользователя каталогах. Х GRANT. Позволяет предоставить другому пользователю привилегии, имеющиеся у администратора, включая саму возможность присвоения привилегий. Х PROCESS. Позволяет просматривать информацию о выполняемых внутри сервера нитях (процессах) с помощью оператора SHOW PROCESSLIST или команды mysqladmin processlist. Эта же привилегия позволяет завершить выполнение процесса с помощью оператора KILL или команды mysqladmin k i l l. Наличие этой привилегии позволяет пользователям просматривать и завершать выполнение любых процессов, включая свои собственные. Ч Х RELOAD. Позволяет выполнять множество операций администрирования сервера, например запускать SQL-оператор FLUSH или выполнять такие mysqladmin-команды, как reload, r e f r e s h, flush-hosts, flush-logs, flush-privileges и flush-tables. Даже несмотря на административные функции, эта привилегия не является опасной. ш SHUTDOWN. Позволяет завершать работу сервера с помощью команды mysqladmin shutdown. В таблицах user, db и host каждая привилегия определена в отдельном столбце. Все эти столбцы описаны типом ENUMC'N", " Y " ) и по умолчанию каждая привилегия имеет значение "м" (отключена). Привилегии таблиц tables_priv и column_priv представлены с помощью типа SET, благодаря чему привилегии могут определяться различными комГлава 12. Безопасность бинациями в одном столбце. Более эффективное представление привилегий в последних двух таблицах объясняется тем, что они появились гораздо позже, чем первые три. (Вполне возможно, что в будущем таблицы user, db и host будут реорганизованы и привилегии в них будут задаваться с помощью типа SET.) Например, столбец Tablepriv таблицы tables_priv определяется следующим образом: 1 SET('Select', 'Insert', 'Update','Delete', 'Create, ' D r o p ', ' G r a n t ', 'Reference','Index','Alter') Столбец Column_priv таблицы column_priv определяется так: SET ( ' Select', ' I n s e r t ', ' U p d a t e ', ' R e f e r e n c e ' ) Привилегий столбцов гораздо меньше, чем привилегий таблиц, поскольку на уровне столбца можно выполнить гораздо меньше операций. Так, например, можно создать новую таблицу, но невозможно создать отдельный столбец. Таблица user, помимо всего прочего, содержит несколько привилегий, которые отсутствуют во всех других таблицах разрешений: Filepriv, Process_priv, Reload_priv и Shutdown_priv. Эти привилегии применяются к выполняемым сервером операциям, не связанным с отдельной базой данных или таблицей. Ведь при необходимости завершения работы сервера вовсе необязательно проверять, над какой базой данных в настоящее время ведется работа. Как сервер управляет доступом клиентов Сервер MySQL выполняет контроль за доступом клиентов в два этапа. Первый этап имеет место при попытке подключения, когда сервер "заглядывает" в таблицу user и ищет все соответствующие этому имени записи, например, название компьютера, с которого можно подключаться, и пароль. Если ни одна запись с аналогичными значениями не найдена, пользователю отказывается в подключении. Если же вся предоставленная пользователем информация соответствует информации, записанной в таблице, соединение устанавливается, и сервер переходит ко второму этапу. В процессе этого этапа каждый раз при получении от пользователя запроса сервер обращается к таблицам разрешений и проверяет, обладает ли пользователь достаточными привилегиями для выполнения того или иного запроса. Второй этап продолжается до завершения сеанса работы с сервером. Этот раздел посвящен описанию правил, используемых сервером MySQL для проверки соответствия записей таблиц разрешений с входящими запросами клиента. В нем описываются типы значений, применяемые в столбцах области таблиц разрешений, способы комбинирования информации;
рассказывается о привилегиях в таблицах разрешений и порядке проверки записей таблицы. 528 Часть III. Администрирование MySQL Содержимое столбцов области доступа В некоторых столбцах области необходимо вводить буквенные значе1ния, однако в большинстве из них можно использовать также специаль\ные символы. Х Host. Значение столбца Host может представлять собой имя компьютера или его IP-адрес. Значение localhost соответствует локальному компьютеру, однако рекомендуется использовать его только в том случае, если данный компьютер действительно имеет имя localhost. Представим ситуацию, когда локальный компьютер имеет имя pit-viper. snake и для одного пильзоишс^я hint ется две записи в таблице user. Одна запись в столбце Host имеет значение localhost, а втораяЧ pit-viper. snake.net. Первая запись будет использоваться только при подключении к компьютеру localhost, а вторая Ч к компьютеру pit-viper, snake.net. Если необходимо, чтобы пользователи имели возможность подключиться с помощью любого из этих способов, следует оставить обе эти записи в таблице user. Значения столбца Host также можно задать с помощью шаблона. Так, можно использовать распространенные в SQL символы "%" и "_", имеющие такое же значение, как и в строке запроса с оператором LIKE. (REGEX-шаблоны для этих целей неприменимы.) Символы шаблона SQL можно применять при определении как имен, так и IP-адресов. Строке %. w i s c. e d u, например, соответствуют все компьютеры домена wisc.edu, а строке %.edu Ч компьютеры всех подключенных к сети организаций системы образования. Аналогичным образом, строка 1 9 2. 1 6 8. % описывает все компьютеры подсети класса В 192.168, а строка 1 9 2. 1 6 8. 3. % Ч все компьютеры подсети класса С 192.168.3. Значение "%" определяет все компьютеры и дает возможность пользователю подключиться из любой точки. Пустое значение столбца Host аналогично значению "I". (Исключение: в таблице db пустое значение столбца Host указывает на необходимость проверки таблицы host для получения более детальной информации. Этот процесс подробно описывается далее в разделе "Проверка запроса".) В версиях MySQL серии 3.23 можно также определить числа IP-адресов с помощью маски сети, отражающей разрядность сетевого номера. Строка 1 9 2. 1 6 8. 1 2 8. 0 / 1 7, например, определяет 17-разрядный сетевой номер. Ей соответствует любой компьютер, первые 17 разрядов IP-адреса которого аналогичны разрядам адреса 192.168.128.
Глава 12. Безопасность User. Имена пользователей могут задаваться буквенными или пустыми значениями. В последнем случае сможет подключиться любой пользователь. Значение "%" и пустое значение в столбце User Ч это не одно и то же. Оно соответствует пользователю с именем "%". Надо признать, такое имя встречается довольно редко. Если при проверке входящего соединения пользователю соответствует в таблице User запись с пустым значением столбца User, данный клиент рассматривается как анонимный. Password. Значения этого столбца могут быть либо пустыми, либо буквенными. Специальные символы в них использовать нельзя. Пустое значение не является аналогией "любого пароля". Когда в таблице определено пустое значение столбца Password, пользователь не должен определять пароль вовсе. Значения паролей хранятся в зашифрованном, а не в обычном текстовом виде. Пользователи не смогут подключиться к серверу, если в столбец Password записываются обычные текстовые значения! Оператор GRANT и команда mysqladmin password автоматически шифруют пароль. Поэтому при непосредственной записи паролей с помощью команд INSERT, REPLACE, UPDATE и SET PASSWORD следует зашифровать их значения с помощью команды PASSWORD("new_password"). Db. Значения столбца Db в таблицах columns_priv и tables_priv обязательно должны представлять собой текстовые имена баз данных. Использование специальных символов и пустых значений запрещается. В таблицах db и host эти значения можно определить как в виде текстовых значений, так и с помощью SQL-символов "%" и "_". Пустое значение и значение % позволяют получить доступ к любой базе данных. Table_name, Column_name. Значения этих столбцов представляют собой текстовые записи имен таблиц и столбцов. Использование специальных символов и пустых значений запрещается. Регистр символов в некоторых столбцах области играет важное значение, а в остальных столбцах значения могут быть записаны как строчными, так и прописными бухвами. Регистры символов в таких столбцах воспринимаются сервером по-разному. Это показано в табл. 12.3. Необходимо заметить, что регистр значений столбца Table_name всегда имеет значение, хотя учет регистра в именах таблиц в запросах зависит от файловой системы, под управлением которой работает сервер (под управлением UNIX выбор регистра важен, а под управлением Windows Ч нет).
Часть III. Администрирование MySQL Таблица 12.3. Учет регистра в столбцах области таблиц разрешений Столбец Host User Password Db Учет регистра Нет Да Да Да Да Нет Table name Column name Проверка запроса Каждый раз при получении запроса сервер проверяет в таблицах разрешений, обладает ли отправивший запрос пользователь достаточными полномочиями для его исполнения. Для этих целей таблицы user, db, tables_priv и column_priv просматриваются в установленном порядке до тех пор, пока не будет определено, что доступ разрешен, либо не будут проверены все таблицы разрешений. Более подробно этот процесс выглядит следующим образом. 1. При первоначальном подключении сервер проверяет записи таблицы user, пытаясь определить глобальные привилегии подключающегося пользователя. Если таковые имеются и, более того, являются достаточными для выполнения запроса, сервер обрабатывает запрос. 2. Если имеющихся глобальных привилегий недостаточно, сервер ищет дополнительные привилегии в таблице db. Если найденные привилегии позволяют выполнить запрос, сервер его обрабатывает. Как хранятся пароли в таблице user Пароли представлены в этой таблице в виде зашифрованных строк, поэтому узнать их не может даже пользователь, имеющий права доступа к этой таблице. Довольно широко распространено мнение, что функция PASSWORD () применяет методы кодирования, используемые и для шифрования паролей UNIX, однако оно ошибочно. Эти два способа кодирования действительно подобны в том отношении, что являются односторонними, т.е. необратимыми. Однако сервер MySQL использует иной алгоритм шифрования, чем UNIX. Это означает, что даже если UNIX-пароль является одновременно и паролем MySQL, зашифрованные строки пароля совпадать не будут. Чтобы использовать для приложения средства шифрования UNIX, вместо PASSWORD (} запустите функцию CRYPT(). Глава 12. Безопасность 3. Если набора глобальных привилегий и привилегий баз данных недостаточно, сервер продолжает поиск сначала в таблице tables_priv, a потом и в columns_priv. 4. Если после проверки всех таблиц разрешений достаточных полномочий не найдено, сервер отклоняет попытку выполнения запроса. Говоря на языке булевой алгебры, привилегии таблиц разрешений | используются сервером следующим образом: user OR db OR tables_priv OR columns_priv Некоторые читатели уже, возможно, задаются вопросом, почему в этой записи указывается четыре таблицы разрешений, хотя на самом деле их пять. Совершенно верно. Правильней было бы переписать ее следующим образом:
user OR (db AND host) OR tables_pnv OR columns_priv Упрощенный вариант был представлен исключительно для того, чтобы показать, что таблица host не подвержена влиянию операторов GRANT и REVOKE. Администраторы, управляющие привилегиями пользователей с помощью операторов GRANT и REVOKE, могут забыть о таблице host по следующим причинам. Х Проверяя привилегии уровня базы данных, сервер ищет запись для клиента в таблице db. Пустое значение столбца Host означает примерно следующее: проверьте таблицу host, чтобы определить, какие компьютеры могут получать доступ к базе данных. Х Сервер ищет в таблице host записи с таким же значением столбца Db, как и в записи таблицы db. Если компьютер подключающегося клиента не указан ни в одной записи таблицы host, следовательно, привилегии для работы с таблицами этому пользователю не предоставлены. Если значение столбца Host хотя бы одной записи этой таблицы соответствует компьютеру подключающегося пользователя, записи таблиц db и host объединяются, что приводит к определению реальных привилегий уровня баз данных клиента. Привилегии объединяются посредством логического оператора AND. Это означает, что пользователь будет иметь привилегии только в том случае, когда записи о нем будут представлены в обеих таблицах. Таким образом, пользователю может присваиваться базовый набор привилегий в записи таблицы db. Согласно записям таблицы host, получить их можно будет только с определенных компьютеров. Так, например, можно предоставить доступ к базам данных со всех компьютеров домена, но убрать эти привилегии для пользователей компьютеров, расположенных в менее защищенной области.
Часть III. Администрирование MySQL I Из всего этого можно сделать вывод, что проверка привилегий Ч достаточно сложный процесс, особенно если учесть, что сервер проверяет привилегии при каждом получении запроса. Хотя на самом деле реализуется он весьма быстро, поскольку сервер не ищет информацию в таблицах разрешений для каждого запроса. Вместо этого содержимое таблиц записывается в память при загрузке, а данные затем быстро проверяются с помощью занесенных в память копий. Такая организация работы повышает производительность операций проверки доступа, хотя имеет и обратную сторону "медали" Ч сервер не замечает изменения привилегий при непосредственном изменении таблиц разрешений. Например, если новый пользователь создается администратором путем добавления новой записи в таблицу user с помощью оператора INSERT, он не сможет сразу же подключиться к серверу. Начинающих администраторов (а иногда и достаточно опытных) это зачастую весьма сильно раздражает, хотя решение этой проблемы предельно просто: достаточно указать серверу перезагрузить таблицы разрешений сразу после внесения изменений. Это можно осуществить с помощью оператора FLUSH PRIVILEGES ИЛИ команды mysqladmin flush-privileges (либо mysqladmin reload, если используется более старая версия, не поддерживающая flush-privileges). Порядок сравнения столбцов Сервер MySQL сортирует записи таблиц разрешений в определенном порядке, а затем, согласно этому порядку, ищет соответствующие соединениям данные. Важно понимать, в каком порядке записи располагаются сервером MySQL, особенно в таблице user. Считывая содержимое таблицы user, сервер сортирует ее записи, согласно значениям столбцов Host и User. Доминирующую роль здесь играет значение столбца Host (т.е. записи с одинаковыми значениями столбца Host размещаются рядом, а затем упорядочиваются по значению User). Однако выполняемая сортировка не является лексикографической, или, скорее, является таковой лишь частично. Основной принцип Ч более высокий приоритет символьных значений по сравнению со специальными символами. Это означает, что если пользователь подключается к компьютеру b o a. s n a k e. n e t, а в таблице имеются записи со значениями b o a. s n a k e. n e t и %. s n a k e. n e t, будет выбрана именно первая запись. Аналогичным образом, значение %.snake.net имеет больший приоритет, чем %. n e t, которое, в свою очередь, более приоритетно, чем %. Точно также обрабатываются и IP-адреса. Порядок приоритетности значений для пользователя, подключающегося с компьютера с IP-адресом 1 9 2. 1 6 8. 3. 1 4, будет выглядеть следующим образом: 1 9 2. 1 6 8. 3. 1 4, 192.168.3.%, 192.168.%, 192.% И %.
Глава 12. Безопасность Как минимизировать риск при работе с таблицами разрешений В этом разделе приведены некоторые рекомендации, которые следует учитывать при присвоении привилегий, а также описываются проблемы, связанные с неправильным выбором администратора. Во-первых, необходимо весьма аккуратно присваивать глобальные привилегии суперпользователей. Другими словами, не следует активизировать привилегии в записях таблицы user. Используйте с этой целью другие таблицы, чтобы ограничить область применения привилегий отдельными базами данных, таблицами и столбцами. Привилегии таблицы user позволяют воздействовать на функционирование всего сервера и получать доступ ко всем таблицам любой базы данных Не предоставляйте никаких привилегий для доступа к базе данных mysql. Ведь пользователь, обладающий привилегиями доступа к базе данных с таблицами разрешений, может легко изменить свои привилегии и получить таким образом доступ и к другим базам данных. Присвоение пользователю достаточных привилегий для изменения таблиц базы данных mysql дает такому пользователю и привилегию GRANT. Возможность непосредственного изменения таблицы практически равноценна возможности запуска оператора GRANT. Привилегию FILE также рекомендуется присваивать с большой осторожностью. Так, обладающий этой привилегией пользователь может запросто выполнить следующие операторы:
CREATE TABLE etc_passwd (pwd_entry TEXT);
LOAD DATA INFILE "/etc/passwd" INTO TABLE etc_passWd;
SELECT * FROM etc_passwd;
Выполнив эти операторы, пользователь получит содержимое файла паролей. Фактически, наличие привилегии FILE дает возможность пользователю раскрыть содержимое любого читаемого файла сервера, даже работая через сеть. Кроме того, привилегия FILE может использоваться для повреждения баз данных в системах, работающих с недостаточными файловыми правами. Именно поэтому администратор должен сделать содержимое каталога данных читаемым только для сервера. Если файлы таблиц баз данных открыты для всеобщего обзора, прочитать их сможет не только пользователь учетной записи сервера, но и любой другой пользователь, обладающий привилегией FILE и подключающийся к серверу через сеть. Как это реализуется, показано на следующем примере. Х Создайте таблицу со столбцом LONGBLOB.
USE test CREATE TABLE tmp (b LONGBLOB) Часть III. Администрирование MySQL Х Используйте таблицу для записи содержимого файла всех нужных таблиц, а затем запишите это содержимое в файл своей базы данных.
LOAD DATA INFILE "./other_db/x.frm" INTO TABLE trap FIELDS ESCAPED BY "" LINES TERMINATED BY "" SELECT * FROM tmp INTO OUTFILE "y.frm" FIELDS ESCAPED BY "" LINES TERMINATED BY "" DELETE FROM tmp LOAD DATA INFILE "./other_db/x.ISO" INTO TABLE tmp FIELDS ESCAPED BY "" LINES TERMINATED BY "" SELECT * FROM tmp INTO OUTFILE "y.ISD" FIELDS ESCAPED BY "" LINES TERMINATED BY "" DELETE FROM tmp LOAD DATA INFILE "./other_db/x.ISM" INTO TABLE tmp FIELDS ESCAPED BY "" LINES TERMINATED BY "" SELECT * FROM tmp INTO OUTFILE "y.ISM" FIELDS ESCAPED BY "" LINES TERMINATED BY "" Х В результате создана новая таблица, содержащая информацию таблицы other_db.x, к которой имеется полный доступ. Чтобы избежать подобных атак, установите права доступа к содержимому каталога данных в соответствии с инструкциями, представленными в разделе "Внутренняя безопасность: защита доступа к каталогу данных". Можно также при запуске сервера использовать опцию --skip-showdatabase. Это запретит пользователям запускать операторы SHOW DATABASE и SHOW TABLES для баз данных, к которым им запрещен доступ, и не позволит пользователям случайно найти базу данных или таблицу, доступ к которым им не должен предоставляться. Иногда и привилегия ALTER используется таким образом, о котором даже и не подозревают администраторы. Предположим, например, что администратор желает предоставить пользователю userl доступ к таблице tablel, но не к таблице table2. Обладающий привилегией ALTER пользователь может легко обойти это ограничение, переименовав с помощью оператора ALTER TABLE таблицу table2 в tablel. Проявляйте осторожность и с привилегией GRANT. Два пользователя, обладающие разными привилегиями, могут легко расширить круг возможностей друг друга. Установка пользователей без помощи оператора GRANT Администраторы MySQL, работающие с версиями до 3.22.11, не могут использовать операторы GRANT (или REVOKE) для создания пользователей и настройки привилегий доступа. Для достижения тех же целей они могут непосредственно изменять содержимое таблиц разрешений. Гораздо проще это сделать тем администраторам, которые знают, каким образом оператор GRANT изменяет таблицы разрешений. По сути, те же операции можно выполнять и самостоятельно, используя операторы INSERT. Глава 12. Безопасность (Другое дело, что оператор INSERT может быть достаточно неудобным и трудно используемым. Именно этим и объясняется зачастую упрощенное использование GRANT.) В строке оператора GRANT определяется имя пользователя, имя компьютера и иногда пароль. В таблице user для пользователя создается запись и соответствующие значения записываются в столбцы User. Host и Password. Если администратор определяет какие-либо глобальные привилегии в операторе GRANT, они записываются в столбец привилегий записи. Однако следует помнить, что оператор GRANT шифрует записываемый пароль, а оператор INSERT Ч нет. Поэтому при настройке пользователей с помощью операторов INSERT необходимо применять функцию PASSWORD (). При определении привилегий уровня базы данных имя пользователя и компьютера заносятся соответственно в столбцы User и Host таблицы db. Имя таблицы, к которой предоставляются привилегии, записывается в столбец Db, а сами привилегии Ч в столбец привилегий. Подобные операции выполняются и при определении полномочий уровня таблиц и столбцов. Для записи имени пользователя, компьютера, названия базы данных и, если необходимо, имени таблицы или столбца, заносятся соответствующие значения в поля таблиц tablespriv и columns_priv. Присваиваемые привилегии записываются в столбцы привилегий. Все описанные выше операции можно выполнить и не прибегая к помощи оператора GRANT. He забывайте также, что после непосредственного изменения таблиц разрешений необходимо указать серверу перезагрузить их. Иначе изменения окажутся незамеченными. Для повторной загрузки можно запустить команду mysqladmin flush-privileges или mysqladmin reload. Представленный ниже оператор GRANT создает суперпользователя со всеми привилегиями, включая возможность наделения привилегиями других пользователей:
GRANT ALL ON *.* ТО ethel@localhost WITH GRANT OPTION IDENTIFIED BY "coffee" Этот оператор создает запись для компьютера ethel@localhost в таблице user и активизирует для нее все привилегии. Те же привилегии можно присвоить и с помощью оператора INSERT:
INSERT INTO user VALUESI"localhost","ethel", PASSWORD("coffee"), Дy,, ( Д y,, f Дy,, ( Д y l l f Дy,^,,y,, f Дy,, ( Дy,^ Дy., f,, Y,, ;
,, y,, ( Дy,, ( Дy,, f Дy,,J И это только один оператор INSERT! Более того, в зависимости от используемой версии MySQL, он может еще и не работать. Если структура таблиц разрешений была случайно изменена, число столбцов привилегий может не равняться четырнадцати. Чтобы проверить количество столбцов в каждой таблице разрешений, воспользуйтесь оператором SHOW COLUMNS, а затем соответствующим образом измените операторы INSERT. 536 Часть III. Администрирование MySQL Следующий оператор GRANT также создает пользователя со статусом суперпользователей, однако только для одной привилегии:
GRANT RELOAD ON *.* ТО flush@localhost IDENTIFIED BY "flushpass" Этот оператор уже рассматривался в главе 11, "Общее администрирование MySQL", когда речь шла о создании пользователя flush. Равноценный предыдущей строке оператор INSERT в этом примере не такой сложный, как в предыдущем. Ведь гораздо проще указать имена столбцов и определить значение только в одном столбце привилегий. Во всех других столбцах по умолчанию будет установлено значение "N": INSERT INTO user (Host, User, Password, Reload_pnv) VALUES("localhost","flush",PASSWORD("flushpass"), " Y " ) Привилегии уровня базы данных присваиваются с помощью предложения ON db_narae, а не ON *. * : GRANT ALL ON samp_db.* TO bonsglocalhost IDENTIFIED BY "ruby" Эти привилегии не являются глобальными, поэтому их не следует записывать в таблицу user. Запись в этой таблице создать нужно (чтобы пользователь смог подключиться), однако для определения привилегий доступа к базе данных необходимо создать запись также и в таблице db:
INSERT INTO user (Host,User,Password) VALUES("localhost","boris",PASSWORD("ruby")) INSERT INTO db VALUES("localhost","samp_db","boris", "Y","Y","Y","Y","Y","Y","N","Y","Y","Y" Столбец со значением ''N" соответствует привилегии GRANT. Для оператора GRANT уровня базы данных с окончанием WITH GRANT OPTION в этом столбце можно установить значение "у". Настройка привилегий уровня таблицы и столбца осуществляется посредством выполнения оператора INSERT для таблиц tables_priv и columns_priv. Безусловно, если версия MySQL не включает оператор GRANT, то она и не включает и эти таблицы, поскольку появились они одновременно. Если же администратор по определенным причинам желает манипулировать данными таблиц tables_priv и columns_priv без помощи оператора GRANT, он должен проявлять осторожность, поскольку невозможно активизировать привилегии в отдельных столбцах. Необходимо установить в одном из столбцов tables_priv.Table_priv или columns_priv.Column_priv значение SET, состоящее из активизируемых привилегий. Например, чтобы предоставить пользователю привилегии SELECT и INSERT для таблицы, установите в столбце Table_priv соответствующей записи таблицы tablespriv значение "Select, Insert". Для изменения привилегий пользователей, уже имеющих учетную запись MySQL вместо INSERT, используется команда UPDATE. Ее можно применять как для добавления, так и для удаления привилегий. Для полного удаления пользователя и всех его привилегий, удалите с помощью |i команды DELETE его записи изо всех таблиц разрешений. Глава 12. Безопасность Если администратор желает избежать непосредственного изменения таблиц разрешений, можно воспользоваться сценариями mysqlaccess и mysql_setpermissions, входящими в состав дистрибуции MySQL. Головоломка с привилегиями (продолжение) В разделе "Ведение файлов журналов" главы 11 была рассмотрена ситуация, когда присвоенные администратором привилегии не позволяли достигать желаемого уровня доступа. Если помните, проблема возникала с новой инсталляцией MySQL, администратор которой добавлял запись для пользователя, тем самым разрешая ему подключаться к серверу с нескольких компьютеров. Очевидный способ определить подобный доступ Ч воспользоваться спецификатором имени компьютера с символом "%". Следовательно, администратор создает учетную запись пользователя с помощью следующего оператора:
GRANT ALL ON samp_db.* TO fred@%.snake.net IDENTIFIED BY "cocoa" Если пользователь f red имеет ученую запись на компьютере с сервером, то он попытается подключиться с него и получит следующий ответ: % mysql -u fred -pcocoa samp_db ERROR 1045: Access denied for user: 'fred@localhost' (Using password: YES) Почему же так происходит? Чтобы понять это, необходимо разобраться, как сценарий mysql_install_db создает исходные таблицы разрешений и как сервер проверяет соответствие данных клиентских соединений и записей таблицы user. При инициализации баз данных в процессе работы mysql_install_db создает записи в таблице user со следующим значениями таблиц Host и User.
Host localhost pit- viper. snake.net localhost pit-viper. snake. net User root root Первые две записи позволяют пользователю root подключиться к локальному компьютеру, определив либо localhost, либо собственно имя компьютера. Вторые две записи разрешают анонимное соединение с локальным компьютером. При добавлении записи для пользователя fred таблица принимает следующий вид.
Host localhost pit-viper. snake. net localhost pit-viper. snake. net %.snake.net User root root fred Часть III. Администрирование MySQL В процессе запуска сервера он считывает эти записи и сортирует их (сначала по имени компьютера, а затем по пользователям). В результате более определенные значения оказываются первыми, а менее определенные Ч последними.
Host localhost localhost pit-viper. snake.net pit -viper. snake.net %. snake.net User root root fred Две записи для компьютера localhost располагаются рядом. Запись для пользователя root размещается первой, поскольку она является более полной. Аналогичным образом и в таком же порядке размещаются и записи компьютера pit-viper. snake.net. Все эти записи имеют в столбце Host буквенные значения безо всяких специальных символов, поэтому и располагаются перед записью для пользователя fred, включающей один специальный символ. Соответственно, записи анонимных пользователей имеют приоритет перед записью пользователя fred. Когда пользователь fred предпринимает попытку подключиться к серверу с локального компьютера, его данным соответствует запись с пустым именем пользователя, которая в порядке сортировки располагается перед записью с %.snake.net. Поскольку анонимные пользователи не применяют пароли, то и эта запись включает пустое значение пароля. Поскольку fred вводит пароль при подключении, возникает несоответствие, и соединение не устанавливается. Важно всегда помнить, что хотя определять с помощью специальных символов имена компьютеров весьма удобно, с подключением с локального компьютера всегда будут возникать проблемы, если в таблице user будут размещаться записи для анонимных пользователей. В большинстве случаев эти записи рекомендуется просто удалить, что значительно упростит дальнейшую работу администратора. Для этого можно воспользоваться следующим оператором:
mysql> DELETE FROM user WHERE User = "";
Чтобы быть полностью уверенным, что такая коллизия не произойдет в будущем, удалите записи анонимных пользователей и изо всех других таблиц разрешений. Подобные записи имеются в таблицах db, tables_priv и columns_priv. Хотя представленный в этом разделе материал описывает одну специфическую ситуацию, он позволяет сделать следующие общие выводы. Если присвоенные пользователям привилегии функционируют не так, как того ожидает администратор, необходимо заглянуть в таблицы разрешений и посмотреть, нет пи в них записей, значения столбца Host которых являются более определенными, чем введенные администратором. Именно в этом зачастую и кроется причина проблемы. Это свидетельствует также и о том, что администраторам необходимо более точно определять записи пользователей (добавляя новые записи для каждого конкретного уровня доступа).
Pages: | 1 | ... | 4 | 5 | 6 | 7 | 8 | ... | 11 | Книги, научные публикации