Администрирование MySQL
С развитием систем баз данных процедуры инсталляции и использования MySQL становятся все проще. Судя по всему, именно простота работы с MySQL стала основной причиной широкой ее популярности среди пользователей. Особенно это относится к тем из них, которые не являются, да и не желают быть программистами. Безусловно, знания компьютерного профессионала могут оказаться весьма полезными, но для успешного использования MySQL быть опытным программистом вовсе не обязательно.
Однако и полностью без управления MySQL работать также не может. Администратор должен хотя бы иногда проверять согласованность и эффективность ее работы и знать, что делать при возникновении проблем. Вся эта информация представлена далее
Этот курс посвящен рассмотрению различных аспектов администрирования MySQL. В этой лекции представлено описание всех основных вопросов, которыми необходимо владеть для успешного выполнения задач по администрированию инсталляцией MySQL. Она же включает краткий обзор всех обязанностей администратора. Инструкции по их выполнению рассматриваются в следующих лекциях.
Представленный далее в этой лекции длинный список обязанностей может не на шутку напугать начинающего или неопытного администратора. Каждая указанная в списке задача действительно очень важна, однако не стоит пробовать освоить их все сразу. Гораздо лучше использовать лекции этого курса в качестве справочного руководства, которое всегда под рукой и в которое при необходимости можно заглянуть.
Уже имеющие опыт работы администраторы могут заметить, что администрирование MySQL подобно администрированию других систем управления базами данных. Опыт администрирования других систем просто неоценим. В то же время, администрирование MySQL имеет свои уникальные особенности, которые и описываются в этом курсе.
Обзор задач администрирования
СУБД MySQL состоит из нескольких основных компонентов. Знание их сути и предназначения поможет лучше понять природу управляемой системы и принципы работы различных ее средств. Настоятельно рекомендуется потратить немного времени, чтобы хорошенько разобраться в представленном далее материале. Это значительно упростит дальнейшую работу. В частности, необходимо вникнуть в следующие аспекты работы MySQL.
Сервер MySQL. Сервер mysqld выполняет все операции с базами данных и таблицами. Для запуска сервера, мониторинга его работы и перезапуска в случае сбоя применяется программа safe_mysqld (демон)
Клиентские программы и утилиты MySQL. Для взаимодействия с сервером и выполнения ряда административных задач используются различные программы MySQL, наиболее важными среди которых являются следующие:
mysql. Интерактивная программа, позволяющая отправлять SQL-запросы на сервер и просматривать результаты их выполнения.
mysqladmin. Административная программа, позволяющая выполнять такие операции, как завершение работы сервера, создание и удаление баз данных. Эту же программу можно применять для проверки состояния сервера, если что-то в его работе не так.
isamchk или myisamchk. Утилиты, предназначенные для анализа и оптимизации таблиц, а также восстановления их в случае повреждения.
mysqldump. Средство резервирования баз данных или их копирования на другой сервер.
SQL - язык сервера. Некоторые задачи администрирования можно выполнить только с помощью утилиты командной строки mysqladmin. Иногда гораздо эффективней справиться с задачей может администратор, который может "общаться" с сервером на его языке. Предположим, что необходимо проверить, почему привилегии пользователя работают вовсе не так, как ожидается. Напрямую "поговорить" с сервером на человеческом языке, к сожалению, нельзя. Зато можно воспользоваться программой-клиентом mysql и послать SQL-запрос для анализа таблиц разрешений.
Незнакомым с операторами SQL пользователям следует разобраться по крайней мере в базовых принципах их работы. Незнание SQL - достаточно серьезное препятствие, и время, затраченное на изучение этого языка, окупится очень быстро. Конечно, чтобы стать настоящим "знатоком SQL", придется напряженно учиться и достаточно долго практиковаться. Познакомиться же с основами этого языка можно за весьма короткий промежуток времени. Более детально о языке SQL и использовании клиентской программы, работающей с командной строкой, рассказывается в курсе "Введение в MySQL".
Каталог данных MySQL. Каталог данных используется сервером для хранения баз данных и файлов состояния. Важно понимать структуру и содержимое каталога данных, чтобы знать, как сервер представляет свои базы данных и таблицы в файловой системе, где хранятся различные файлы (например, регистрационные) и что в них содержится. Необходимо также уметь управлять распределением дискового пространства, чтобы избежать переполнения раздела с каталогом данных.
Общее администрирование Общее администрирование включает в себя в основном работу с демономmysqld, сервером MySQL и обеспечение доступа пользователей. К наиболее важным задачам общего администрирования относятся следующие.
Поддержка учетных записей пользователей. Администратор должен отчетливо понимать разницу между пользователями MySQL и пользователями UNIX и Windows, а также уметь настраивать учетные записи пользователей MySQL. Такая настройка зачастую заключается в определении, какие пользователи и с какого компьютера смогут подключаться к серверу. Новым пользователям необходимо, кроме всего прочего, сообщить свои параметры подключения, чтобы успешно настроить обмен данными с сервером. Настройка учетных записей — это задача администратора, а не пользователей!
Иногда возникает необходимость в запуске СУБД на более быстродействующем главном компьютере или в создании копии базы данных. В этом случае все содержимое ее каталога можно скопировать на другой компьютер. Администратор должен уметь выполнять и эту процедуру. Файлы баз данных могут зависеть от конфигурации конкретной системы, поэтому простое копирование файлов не сможет дать достаточно удовлетворительных результатов.
Безопасность В процессе инсталляции MySQL важно также обеспечить надежную защиту хранимых данных. Администратор MySQL полностью отвечает за предоставление доступа к каталогам данных и серверу и должен разбираться в следующих вопросах.
Отладка и поддержка баз данных В душе каждый администратор MySQL надеется избежать повреждения или полного разрушения таблиц баз данных. Однако одних надежд мало. Выполнение определенных процедур позволит минимизировать риск сбоя и оказаться более подготовленным к негативному развитию событий.
Итак, мы рассмотрели краткое описание всех основных обязанностей администратора MySQL. В следующих лекциях эти задачи изучаются более детально, а также описываются процедуры эффективного их выполнения. Однако сначала рассматривается каталог данных MySQL. Ведь администратору необходимо четко понимать структуру и содержимое ресурса, на который направлены все операции поддержки. Ниже будут рассмотрены все общие административные задачи, система безопасности MySQL, поддержка работы СУБД и методы устранения всевозможных проблем. |
|
|
|
Эта лекция посвящена рассмотрению задач администратора MySQL, точное выполнение которых позволит обеспечить согласованную и эффективную работу сервера MySQL. К задачам подобного рода относится проверка работоспособности сервера, достижение максимально возможной производительности, настройка пользовательских учетных записей для обеспечения клиентского доступа к серверу, поддержка журналов и резервирование баз данных. В некоторых случаях, когда на одном компьютере запускается несколько серверов, администратору для достижения максимальной производительности работы приходится также изменять операционные параметры работы сервера. Стремительное развитие возможностей MySQL вынуждает администратора пристально следить за новинками и вовремя обновлять свою систему MySQL посредством инсталляции новых версий. Кроме того, существуют и другие задачи администрирования, однако о них речь пойдет в других лекциях. В этой и следующих лекциях описывается несколько программ, исключительно полезных для выполнения задач администрирования MySQL.
Защита новой инсталляции MySQL На этапе инсталляции MySQL необходимо обязательно установить пароль для MySQL-пользователя root, поскольку сразу после установки права сервера не защищены. Предполагается, что каталог данных и база данных mysql с таблицей разрешений уже инициализированы. На компьютерах с UNIX для их инициализации достаточно запустить сценарий mysql_install_db. На компьютерах, работающих под управлением Windows, каталог данных и база данных mysql инициализируются посредством запуска программы Setup в дистрибутиве сервера. Итак, каталог и основная база данных пронициализированы, и сервер запущен. Сразу после первой инсталляции MySQL на компьютере привилегии в таблице разрешений базы данных mysql устанавливаются следующим образом.
% mysql -h pit-viper.snake.net test На полное отсутствие защиты исходной инсталляции указывает тот факт, что подключиться к серверу MySQL можно в качестве пользователя root абсолютно без пароля. Именно поэтому одна из первых задач администратора MySQL заключается в установке пароля для пользователя root. Затем, в зависимости от метода установки пароля, возможно, еще придется указать серверу перезагрузить таблицы разрешений, чтобы загрузить в память все сделанные изменения. (В процессе запуска сервер загружает таблицы в память и может не заметить внесенные впоследствии изменения. В таком случае следует явным образом указать ему на необходимость повторного считывания таблиц.) В версиях MySQL 3.22 и выше установить пароль можно с помощью команды mysqladmin. Для этого достаточно ввести следующую команду, заменив ее часть "my password" реальным паролем: mysqladmin -u root password "my password" Во всех остальных версиях MySQL для этих целей можно воспользоваться программой mysql и непосредственно обновить таблицу разрешений grant в базе данных mysql: mysql> -u root mysql mysql> UPDATE user SET Password=PASSWORD("my password") WHERE User="root";
Команда mysql и оператор update применяется в старых версиях MySQL, а также во всех бесплатно распространяемых версиях под Windows. После установки пароля необходимо определиться, следует ли задавать серверу перезагрузку таблицы разрешений. Для этого запустите следующую команду: % mysqladmin -u root status Если сервер все еще позволяет подключаться в качестве пользователя root без пароля, укажите ему перезагрузить таблицы, введя следующую команду: % mysqladmin -u root reload После определения пароля пользователя root (и перезагрузки таблиц разрешений) самое время приступать к определению нового пароля для администратора. бычный сервер хранит у себя все данные и обслуживает все клиентские запросы. Схема взаимодействия между сервером и клиентами изображена на рис 12.1. Серверные данные располагаются на одном или нескольких физических дисках. Чтобы сделать запрос, клиент устанавливает соединение с сервером. Сервер анализирует инструкции, выполняет их, извлекает данные и возвращает результаты запроса. По мере возрастания нагрузки производительность сервера снижается. Чтобы избежать этого, задействуют дополнительные ресурсы, например, наращивают память, ставят дополнительные процессоры и даже сетевые платы. Эта стратегия эффективна, если клиенты расположены в непосредственной близости от сервера, — например, несколько серверов приложений взаимодействуют с одной СУБД. Но в тех архитектурах, где сервер и клиенты удалены друг от друга, производительность обратно пропорциональна расстоянию.
Рис. 12.1. Обычный сервер баз данных Решением этой проблемы являются распределенные базы данных (РБД), которые сегментируют хранимую информацию и перемещают отдельные ее блоки ближе к нужным клиентам. Способов организации таких баз данных много. Можно разместить таблицы на разных компьютерах или использовать несколько идентичных хранилищ. Во втором случае серверы взаимодействуют друг с другом для поддержания синхронизации. Если на одном из серверов происходит обновление данных, оно распространяется и на все остальные серверы. К недостаткам распределенных баз данных можно отнести то, что возрастает сложность управления ими. Но преимуществ все же больше. Главное из них — повышение производительности. Данные быстрее обрабатываются несколькими серверами, а кроме того, данные располагаются ближе к тем пользователям, которые чаще с ними работают. Система становится более устойчивой, если она способна выдержать сбой одного из своих компонентов. В распределенной базе данных с симметричной схемой хранения исчезновение одного из серверов приводит к замедлению работы пользователей, находящихся ближе к этому серверу, но в целом система остается работоспособной. К тому же, она легко масштабируется, так как ее не нужно останавливать при добавлении еще одного сервера. В несимметричной системе можно оптимизировать схему расположения данных. Чем ближе пользователи находятся к нужным им данным, тем меньше на их работу влияют сетевые задержки. В результате серверам приходится обрабатывать меньшие объемы данных. Это также способствует повышению безопасности данных, поскольку их можно физически хранить в тех системах, где пользователи имеют право работать с соответствующими данными. В целом, однако, применение распределенных баз данных связано с достаточно высоким риском. Требуется обеспечить соблюдение мер безопасности сразу на нескольких узлах, что не так-то просто реализовать. Распределенные базы данных трудно проектировать и обслуживать. Порядок работы в системе может со временем поменяться что повлечет за собой изменение схемы хранения данных. Как клиенты, так и серверы должны уметь обрабатывать запросы к данным, которые не расположены в ближайшей системе. Плохо спроектированная РБД может демонстрировать меньшую производительность, чем одиночный сервер. Отложенная синхронизация Создать точную копию базы данных MySQL довольно просто. Способы резервного копирования баз данных описывались в лекции "Устранение последствий катастроф". Что касается восстановления данных, то это можно сделать на любом сервере. Располагая такими средствами, несложно реализовать распределенную базу данных, которая синхронизируется через достаточно большие промежутки времени, например, раз в день. Рассмотрим проблему обновления данных. Если обновления происходят сразу на двух серверах, их нужно согласовывать. Чтобы не возникали неразрешимые ситуации, необходимо позволить вносить изменения только на одном сервере. Тогда синхронизация будет заключаться в дублировании содержимого сервера, доступного для записи, на все остальные серверы. Их полезность зависит от того, насколько важна актуальность данных. Во многих случаях база данных, содержащая все записи, кроме тех, которые были созданы за последние 24 часа, вполне приемлема. Методика отложенной синхронизации идеально подходит для баз данных, содержащих результаты ночных отчетов. Например, Web-узел, предоставляющий доступ к МР3-файлам, может регистрировать названия запрашиваемых песен и составлять рейтинги популярности. Раз в день все серверы посылают свои журнальные главному серверу, который корректирует рейтинги согласно новой статистике. Схема такой базы данных приведена в листинге 12.1.
/* Каталог МР3-файлов. */ CREATE TABLE song ( ID INT NOT NULL AUTO INCREMENT, Name CHAR(40) NOT NULL, Artist CHAR(16) NOT NULL, Filename CHAR(80) NOT NULL, PRIMARY KEY(ID), INDEX (Name), INDEX (Artist) );
/* Журнал запрашиваемых файлов. */ CREATE TABLE log ( Server TINYINT UNSIGNED NOT NULL, Song INT NOT NULL, DownloadTime DATETIME NOT NULL );
Листинг 12.1. Схема распределений (html, txt) Каждый сервер хранит информацию о доступных песнях в таблице song. В таблицу log заносится запись всякий раз, когда кто-то загружает очередной МР3-файл. У этой таблицы нет первичного ключа, так как в обычном режиме она используется лишь для вставки записей. Наличие индекса только замедлит работу с таблицей. Раз в день таблицы log всех серверов объединяются по следующему сценарию. Один из серверов прекращает обслуживать запросы Web-приложений. Остальные серверы создают копии таблицы log, извлекают из них последние записи и посылают их серверу, генерирующему отчет. На время этой процедуры каждый сервер должен заблокировать свою таблицу log. Чтобы слишком много пользовательских запросов не оказалось заблокировано, процедуру желательно выполнять в период минимальной активности сервера. Сервер, генерирующий отчет, загружает полученные данные в свою таблицу log, после чего выполняет сценарий, показанный в листинге 12.2. В этом сценарии создаются два рейтинга популярности: по всем песням и за последние 24 часа. Временный индекс таблицы log ускоряет ее просмотр.
/* Создание индекса. */ CREATE INDEX song ON log (Song);
/* Определение рейтинга всех песен. */ DROP TABLE IF EXISTS popular alltime; CREATE TABLE popular alltime ( Rank INT NOT NULL, Song INT NOT NULL, Hits INT NOT NULL, ); SET @id = 0; INSERT INTO popular alltime SELECT (@id := @id+1), song, COUNT (*) FROM Log GROUP BY 2 ORDER BY 3 DESC; ALTER TABLE popular alltime ADD PRIMARY KEY (Rank);
/* Определение рейтинга песен за последние 24 часа. */ DROP TABLE IF EXISTS popular last24; CREATE TABLE popular last24 ( Rank INT NOT NULL, Song INT NOT NULL, Hits INT NOT NULL, ); SET @id = 0; INSERT INTO popular last24 SELECT (@id := @id+1), song, COUNT (*) FROM Log WHERE DownloadTime > DATE SUB (NOW(), INTERVAL 24 HOUR) GROUP BY 2 ORDER BY 3 DESC; ALTER TABLE popular last24 ADD PRIMARY KEY (Rank);
/* Удаление индекса */ DROP INDEX song ON log;
Листинг 12.2. (html, txt) Таблицы рейтингов не содержат поле-счетчик: вместо него используется инкрементная переменная. Будучи созданной, рейтинговая таблица уже не меняется. Сценарий удаляет существующие таблицы и формирует их заново. Имеет смысл сжимать такие таблицы с помощью утилиты myisampack (см. лекцию "Утилиты командной строки"). Созданные таблицы загружаются остальными серверами, где они заменяют старые рейтинги. Изменения в таблицу song должны вноситься на одном сервере. Тогда исчезают проблемы, связанные с дублированием песен и первичных ключей. Главный сервер публикует новую редакцию каталога песен либо после каждого изменения, либо по определенному графику. Отложенная синхронизация удобна там, где пользователям не нужны отчеты в реальном времени. В приведенном выше примере число операций записи в журнальную таблицу превышает число обращений к рейтингам, если учесть, что пользователь, просматривающий список десяти лучших песен, наверняка захочет загрузить хотя бы одну из них. Методика срабатывает, поскольку информация, представленная в рейтинге, не имеет непосредственной ценности. В описанной схеме требуется, чтобы приложения знали архитектуру всей системы. Эта система не является монолитной и легко справляется со сбоями отдельных компонентов. Каждый из составляющих ее серверов хранит идентичную информацию. Настройка процедур запуска и завершения работы сервера MySQL Одна из основных обязанностей администратора MySQL — обеспечить согласованную и длительную работу сервера, что даст возможность пользователям получать доступ к нему в любое удобное время. Иногда, однако, возникает необходимость и во временной приостановке работы сервера. (Так, например, при перемещении базы данных необходимо убедиться, что сервер в это же время не обновляет ее таблицы.) Эти лекции не помогут разрешить компромисс между необходимостью постоянной работы сервера и желанием иногда временно приостановить его работу, поскольку зачастую решение этого компромисса зависит от конкретной ситуации. По крайней мере, читатели смогут узнать, как запустить и завершить работу сервера. Все приведенные в этой лекции инструкции применимы только к операционным системам UNIX. |
|
|
|
Запуск представленных команд
В большинстве примеров этой лекции такие программы, как mysqladmin, mysqldump и им подобные, для краткости представлены без опций -h, -u и -р. Предполагается, что пользователи будут правильно вызывать эти программы, используя в случае необходимости подключения к серверу соответствующие параметры.
В версии MySQL 3.22.11 и выше перезагрузить таблицы можно с помощью команды mysqladmin flush-privileges и SQL-оператора FLUSH PRIVILEGES.
Запуск сервера MySQL непривилегированным пользователем
Прежде чем приступить к рассмотрению процедуры запуска сервера, давайте обсудим, какие пользователи могут выполнить подобный запуск. Сервер может запускаться вручную или автоматически. В первом случае сервер запускается в качестве пользователя, под именем которого зарегистрирован администратор, запускающий сервер (или другой сотрудник). Другими словами, если администратор зарегистрирован под именем пользователя paulи запускает сервер, то сервер будет работать с правами пользователя paul. Если затем администратор с помощью команды su авторизуется в качестве пользователя root и запустит сервер, сервер будет работать с правами пользователя root.
Однако всегда запускать сервер вручную весьма неудобно. Лучше всего настроить его на автоматический запуск во время загрузки системы. На UNIX-компьютерах процедура запуска выполняется системой с помощью UNIX-пользователя root, соответственно, все процессы, запускаемые во время этой процедуры, работают впоследствии с привилегиями пользователя root.
Администратору следует помнить о двух целях, преследуемых при настройке процедуры запуска сервера MySQL.
Желательно, чтобы сервер не обладал привилегиями пользователя root. В большинстве случаев рекомендуется ограничивать возможности всех процессов, не требующих прав доступа root. He нужны эти права и демону mysqld.
Желательно, чтобы сервер все время работал под именем одного и того же пользователя. Весьма нелогично запускать сервер в разное время под именами разных пользователей, поскольку в этом случае файлы и каталоги с данными будут создаваться разными владельцами. В определенный момент времени это может привести к невозможности получения доступа к базам данных или таблицам. Постоянный запуск сервера от имени одного пользователя позволит избежать этой проблемы.
Для запуска сервера под обычным пользователем, не обладающим широкими правами, выполните следующие действия.
Выберите учетную запись, предназначенную для запуска сервера. Демон mysqld может работать от имени любого пользователя, однако лучше создать для него отдельную учетную запись. Можно также создать специальную группу для работы с MySQL. Предположим, что такой пользователь и группа уже созданы и имеют имена mysqladm и mysqlgrp. Пользователям, определившим другие имена для этих целей, придется подставлять их далее в примерах кода вместо mysqladm и mysqlgrp.
Если же MySQL был установлен под каким-либо пользователем, не обладающим специальными правами администратора, сервер наверняка будет запускаться под собственным именем этого пользователя. В этом случае необходимо заменить mysqladm и mysqlgrp соответствующим регистрационным именем и именем группы.
Если же система MySQL инсталлировалась под управлением ОС Linux Red Hat с помощью RPM-файла, в процессе установки автоматически создается учетная запись с именем mysql. Ее в последующих примерах этой лекции нужно применять вместо mysqladm.
Создайте, если необходимо, учетную запись сервера, используя обычную процедуру создания учетных записей системы. Для этого необходимо сначала авторизоваться в качестве пользователя root.
Завершите работу сервера, если он работает.
Измените права доступом к каталогу данных, а также всех его подкаталогов и файлов, чтобы новым владельцем этих элементов оказался пользователь mysqladm. Например, чтобы сделать пользователя mysqladm владельцем каталога данных /usr/local/var, необходимо ввести следующие команды (авторизовавшись в качестве пользователя root).
# cd /usr/local/var. Переход в каталог данных.
# chown -R mysqladm.mysqlgrp.
Установка прав доступа для всех каталогов и файлов.
Измените полномочия доступа к каталогу данных и всем его подкаталогам и файлам, чтобы работать с ними мог только пользователь mysqladm. Запретите доступ к данным всем остальным пользователям — это самая эффективная мера предосторожности. Если каталог данных размешается в директории /usr/local/var, определить права доступа на него для пользователя mysqladm можно с помощью следующих команд (авторизовавшись в качестве пользователя root).
# cd /usr/local/var. Переход в каталог данных.
# chmod -R go-rwx.
Все элементы будут доступны только для пользователя mysqladm.
Устанавливая права доступа и режим для каталога данных и его содержимого, не забудьте просмотреть символические связи. Нужно обязательно переместиться в каталоги, на которые эти связи указывают, и изменить права доступа для их содержимого. На этом этапе могут возникнуть проблемы, если содержащий все связанные файлы каталог не принадлежит владельцу каталога данных. Единственный способ решения таких проблем — авторизоваться в качестве пользователя root.
По завершении вышеприведенной процедуры следует убедиться в нормальном запуске сервера, предварительно авторизовавшись в качестве пользователя mysqladm или root. В последнем случае обязательно нужно определить опцию --user=mysqladm, чтобы пользователь мог переключить ID-номер своего компьютера на mysqladm (что также реализуется в процессе запуска системы).
Опция --user была добавлена в mysql в версии MySQL 3.22. В более ранних версиях для этих же целей можно использовать команду su, которая указывает системе, работающей под управлением пользователя root, что запускать сервер необходимо с учетной записью другого пользователя. Настоятельно рекомендуется заглянуть в справочное руководство и ознакомиться с синтаксисом команды su, поскольку он может видоизменяться для отдельных пользователей.
Методы запуска сервера
После определения учетной записи, которая будет применяться для работысервера, можно приступать к выбору способа запуска. Сервер можно запускать вручную из командной строки или автоматически в процессе загрузки системы. Существуют три основных метода запуска сервера.
Непосредственный вызов mysqld. Это, возможно, самый распространенный метод. Поэтому подробно рассматриваться далее он не будет. Достаточно лишь заметить, что в случае необходимости можно использовать команду mysqld --help для определения опций с другими методами запуска.
Вызов сценария safemysqld. Этот сценарий в процессе своей работы пытается определить местоположение программы сервера и каталога данных, а затем запускает сервер с соответствующими опциями. Сценарий safemysqld записывает все сообщения об ошибках сервера в специальный файл ошибок, расположенный в каталоге данных. Кроме того, safemysqld следит за нормальной работой сервера и в случае сбоя перезагружает его. Этот сценарий наиболее часто применяется в BSD-версиях UNIX.
Вызов сценария mysql.server. Этот сценарий запускает сервер посредством запуска сценария safemysqld. Сценарий mysql.serverпредназначен для использования на компьютерах с системой запуска/завершения работы System V. Данная система включает несколько каталогов со сценариями, вызываемыми при входе или выходе с определенного уровня работы. С помощью соответствующих аргументов start и stop можно определить, что делать дальше: запустить сервер или остановить его работу.
Сценарий safemysqld располагается в подкаталоге bin каталога инсталляции MySQL. Его же можно найти в каталоге scripts дистрибутива MySQL. Сценарий mysql.server можно отыскать в подкаталоге share/mysqlкаталога инсталляции или каталоге support-files исходной дистрибуции MySQL. Для использования эти сценарии необходимо скопировать в соответствующие каталоги запуска.
В ОС BSD-UNIX довольно часто используются несколько специальных файлов, которые располагаются в каталоге/etc и инициируют службы во время запуска. Как правило, имена таких файлов начинаются с приставки "rc". Файлrc.local (или имеющий подобное название), например, предназначен специально для запуска локальных служб. Для запуска сервера в подобных системах необходимо добавить в файл rc.local следующие строки (подставив правильный путь к сценарию safe_mysqld):
if [ -x /usr/local/bin/safe_mysqld ]; then /usr/local/bin/safe_mysqld & fi
В системах System V для инсталляции сценария mysql.server достаточно разместить его в подкаталоге /etcкаталога запуска. Это наверняка уже сделано, если Linux или MySQL инсталлировались с помощью RPM-файла. Если нет, инсталлируйте сценарий в основной каталог сценариев запуска и установите связи с ним в каталогах уровней запуска. Можно также сделать так, чтобы сценарии запускались только пользователем root.
Структура каталогов с файлами запуска может изменяться от системы к системе, поэтому рекомендуется внимательно просмотреть, как эти файлы организованы в используемом компьютере. Например, в системе LinuxPPC для запуска применяются каталоги /etc/rc.d/init.d и etc/rc.d/rc3.d. Соответственно, инсталляция сценария выполняется с помощью следующих команд:
# ср mysql.server /etc/rc.d/init.d
# cd /etc/init.d
# chmod 500 mysql.server
# cd /etc/rc.d/rc3.d
# ln -s ../init.d/mysql.server S99mysql
В ОС Solaris основной каталог сценариев — /etc/init.d, а каталог уровня запуска — /etc/rc2.d, поэтому набор команд инсталляции выглядит следующим образом:
# ср mysql.server /etc/init.d
# cd /etc/init.d
# chmod 500 mysql.server
# cd /etc/rc2.d
# ln -s ../init.d/mysql.server S99mysql
Эти команды обеспечивают автоматический запуск сценария S99mysql с аргументом start в процессе загрузки системы.
Если имеется возможность использования команды chkconfig (часто применяемой под управлением Linux), ее также можно применить для инсталляции сценария mysql.server. В этом случае от ручного ввода приведенных выше команд можно отказаться.
Определение опций запуска
Существует два способа определения дополнительных опций запуска, которые применяются при загрузке сервера. Во-первых, можно изменить используемый сценарий запуска (safemysqld или mysql.server) и задать параметры непосредственно в строке вызова сервера. Во-вторых, можно определить параметры собственно в конфигурационном файле. Профессионалы рекомендуют по возможности использовать для этих целей глобальные конфигурационные файлы. В системах UNIX и Windows этими файлами обычно являются /etc/my.cnf.
Однако есть информация, которую невозможно задать в конфигурационных файлах. Для ее определения необходимо изменить сценарий safemysqld. Так, например, если сервер неправильно считал установки временного пояса и возвращает значения времени в формате GMT (времени по Гринвичу), можно для подсказки установить переменную среды TZ. Если сервер запускается с помощью сценария safemysqld или mysql.server, установку временного пояса можно добавить в safemysqld. Отыщите строку запуска сервера и перед ней добавьте следующие команды:
TZ=US/Central
export TZ
Эти команды устанавливают часовой пояс центральной части Соединенных Штатов. Пользователям же необходимо аналогичным образом задать свой часовой пояс. Подобный синтаксис для переменной TZ применяется в системе Solaris. В других системах он может быть другим, например, таким:
TZ=CST6CDT
export TZ
Следует помнить, что после повторной инсталляции MySQL (например, при обновлении версии) все внесенные в сценарий запуска изменения будут потеряны. В таком случае необходимо сперва скопировать сценарий в другую папку, а после инсталляции сравнить оба сценария (старый и вновь инсталлированный) и добавить отсутствующие параметры.
Методы запуска сервера
После определения учетной записи, которая будет применяться для работысервера, можно приступать к выбору способа запуска. Сервер можно запускать вручную из командной строки или автоматически в процессе загрузки системы. Существуют три основных метода запуска сервера.
Непосредственный вызов mysqld. Это, возможно, самый распространенный метод. Поэтому подробно рассматриваться далее он не будет. Достаточно лишь заметить, что в случае необходимости можно использовать команду mysqld --help для определения опций с другими методами запуска.
Вызов сценария safemysqld. Этот сценарий в процессе своей работы пытается определить местоположение программы сервера и каталога данных, а затем запускает сервер с соответствующими опциями. Сценарий safemysqld записывает все сообщения об ошибках сервера в специальный файл ошибок, расположенный в каталоге данных. Кроме того, safemysqld следит за нормальной работой сервера и в случае сбоя перезагружает его. Этот сценарий наиболее часто применяется в BSD-версиях UNIX.
Вызов сценария mysql.server. Этот сценарий запускает сервер посредством запуска сценария safemysqld. Сценарий mysql.serverпредназначен для использования на компьютерах с системой запуска/завершения работы System V. Данная система включает несколько каталогов со сценариями, вызываемыми при входе или выходе с определенного уровня работы. С помощью соответствующих аргументов start и stop можно определить, что делать дальше: запустить сервер или остановить его работу.
Сценарий safemysqld располагается в подкаталоге bin каталога инсталляции MySQL. Его же можно найти в каталоге scripts дистрибутива MySQL. Сценарий mysql.server можно отыскать в подкаталоге share/mysqlкаталога инсталляции или каталоге support-files исходной дистрибуции MySQL. Для использования эти сценарии необходимо скопировать в соответствующие каталоги запуска.
В ОС BSD-UNIX довольно часто используются несколько специальных файлов, которые располагаются в каталоге/etc и инициируют службы во время запуска. Как правило, имена таких файлов начинаются с приставки "rc". Файлrc.local (или имеющий подобное название), например, предназначен специально для запуска локальных служб. Для запуска сервера в подобных системах необходимо добавить в файл rc.local следующие строки (подставив правильный путь к сценарию safe_mysqld):
if [ -x /usr/local/bin/safe_mysqld ]; then /usr/local/bin/safe_mysqld & fi
В системах System V для инсталляции сценария mysql.server достаточно разместить его в подкаталоге /etcкаталога запуска. Это наверняка уже сделано, если Linux или MySQL инсталлировались с помощью RPM-файла. Если нет, инсталлируйте сценарий в основной каталог сценариев запуска и установите связи с ним в каталогах уровней запуска. Можно также сделать так, чтобы сценарии запускались только пользователем root.
Структура каталогов с файлами запуска может изменяться от системы к системе, поэтому рекомендуется внимательно просмотреть, как эти файлы организованы в используемом компьютере. Например, в системе LinuxPPC для запуска применяются каталоги /etc/rc.d/init.d и etc/rc.d/rc3.d. Соответственно, инсталляция сценария выполняется с помощью следующих команд:
# ср mysql.server /etc/rc.d/init.d
# cd /etc/init.d
# chmod 500 mysql.server
# cd /etc/rc.d/rc3.d
# ln -s ../init.d/mysql.server S99mysql
В ОС Solaris основной каталог сценариев — /etc/init.d, а каталог уровня запуска — /etc/rc2.d, поэтому набор команд инсталляции выглядит следующим образом:
# ср mysql.server /etc/init.d
# cd /etc/init.d
# chmod 500 mysql.server
# cd /etc/rc2.d
# ln -s ../init.d/mysql.server S99mysql
Эти команды обеспечивают автоматический запуск сценария S99mysql с аргументом start в процессе загрузки системы.
Если имеется возможность использования команды chkconfig (часто применяемой под управлением Linux), ее также можно применить для инсталляции сценария mysql.server. В этом случае от ручного ввода приведенных выше команд можно отказаться.
Определение опций запуска
Существует два способа определения дополнительных опций запуска, которые применяются при загрузке сервера. Во-первых, можно изменить используемый сценарий запуска (safemysqld или mysql.server) и задать параметры непосредственно в строке вызова сервера. Во-вторых, можно определить параметры собственно в конфигурационном файле. Профессионалы рекомендуют по возможности использовать для этих целей глобальные конфигурационные файлы. В системах UNIX и Windows этими файлами обычно являются /etc/my.cnf.
Однако есть информация, которую невозможно задать в конфигурационных файлах. Для ее определения необходимо изменить сценарий safemysqld. Так, например, если сервер неправильно считал установки временного пояса и возвращает значения времени в формате GMT (времени по Гринвичу), можно для подсказки установить переменную среды TZ. Если сервер запускается с помощью сценария safemysqld или mysql.server, установку временного пояса можно добавить в safemysqld. Отыщите строку запуска сервера и перед ней добавьте следующие команды:
TZ=US/Central
export TZ
Эти команды устанавливают часовой пояс центральной части Соединенных Штатов. Пользователям же необходимо аналогичным образом задать свой часовой пояс. Подобный синтаксис для переменной TZ применяется в системе Solaris. В других системах он может быть другим, например, таким:
TZ=CST6CDT
export TZ
Следует помнить, что после повторной инсталляции MySQL (например, при обновлении версии) все внесенные в сценарий запуска изменения будут потеряны. В таком случае необходимо сперва скопировать сценарий в другую папку, а после инсталляции сравнить оба сценария (старый и вновь инсталлированный) и добавить отсутствующие параметры.
В обязанности администратора 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 проще, чем непосредственно редактировать таблицы разрешений. Однако для более полного понимания представленного здесь материала рекомендуется также прочитать лекцию 11,"Безопасность", в которой детально описываются таблицы разрешений.
Роль этих таблиц действительно велика, и администратор должен понимать, каким образом их обрабатывают операторы GRANT и REVOKE.
Далее в этой лекции рассказывается, как создавать учетные записи пользователей MySQL, присваивать или удалять их привилегии, а также полностью удалять пользователей из таблиц разрешений. В конце лекции описана также одна связанная с привилегиями "головоломка", которая может завести в тупик многих начинающих администраторов MySQL.
Некоторые пользователи захотят также познакомиться со сценариями mysqlaccess и mysql_setpermission, которые являются частью дистрибуции MySQL. Они представляют собой Perl-сценарии и обеспечивают альтернативу оператору grant, поскольку применяются для установки пользовательских учетных записей. Для использования сценария mysql_setpermission требуется инсталляция поддержки DBI.
Создание новых пользователей и предоставление привилегий
Оператор GRANT имеет следующий синтаксис:
GRANT privileges (columns)
ON what
TO user IDENTIFIED BY "password"
WITH GRANT OPTION
Для успешного его выполнения обязательно нужно правильно определить следующую информацию:
privileges (привилегии). Привилегии присваиваются определенному пользователю. Используемые в операторе grant спецификаторы привилегий описаны в представленной ниже таблице.
Спецификатор привилегий |
Разрешенная операция |
user |
Подключающиеся к серверу пользователи и все их глобальные привилегии |
alter |
Изменение таблиц и индексов |
create |
Создание баз данных и таблиц |
delete |
Удаление существующих записей из таблиц |
drop |
Удаление баз данных и таблиц |
index |
Создание и удаление индексов |
insert |
Вставка новых записей в таблицы |
references |
He используется |
select |
Извлечение существующих записей из таблиц |
update |
Изменение существующих записей таблиц |
file |
Чтение и запись файлов сервера |
process |
Просмотр информации о внутренних потоках сервера и их удаление |
reload |
Перезагрузка таблиц разрешений или обновление журналов, кэша компьютера или кэша таблицы |
shutdown |
Завершение работы сервера |
all |
Все операции. Аналог — all privileges |
usage |
Полное отсутствие привилегий |
Спецификаторы привилегий, входящие в первую группу этой таблицы, применяются к базам данных, таблицам и столбцам. Спецификаторы второй группы определяют административные привилегии. Как правило, они применяются довольно редко, поскольку позволяют пользователю влиять на работу сервера. (Не каждому пользователю, например, необходима привилегия shutdown.) В третью группу входят два отдельных спецификатора: спецификаторALL предоставляет "все привилегии", a USAGE означает "полное отсутствие привилегий". В последнем случае создается новый пользователь, не обладающий никакими правами;
columns (столбцы). Столбцы, к которым применяются определенные привилегии. Этот параметр необязателен и используется только при установке привилегий для столбцов. Имена нескольких столбцов отделяются друг от друга запятыми;
what (что). Уровень применения привилегий. Привилегии могут быть глобальными (применяемыми ко всем базам данных и их таблицам), уровня баз данных (применяемыми ко всем таблицам определенной базы данных) или уровня таблицы. Используя оператор columns, можно определить также привилегии уровня столбца;
user (пользователь). Пользователь, которому присваиваются привилегии. В некоторых версиях MySQL необходимо указывать как имя пользователя, так и компьютер, с которого он сможет подключаться. Такой способ задания легко позволяет определить двух пользователей с одинаковым именем, но подключающихся с разных компьютеров. Возможности MySQL позволяют их различать и наделять различными правами.
Имя пользователя в некоторых версиях MySQL представляет собой имя, используемое при подключении к серверу. Оно вовсе не обязательно должно быть связано с именем регистрации в ОС UNIX или Windows. Если имя пользователя MySQL не определено явным образом, клиентские программы по умолчанию применяют его в качестве регистрационного имени, однако это необязательно. Не существует также каких-либо особых требований, чтобы суперпользователь MySQL, обладающий максимальными правами, имел имя root. По желанию его можно изменить в таблицах разрешений на nobody, если для выполнения определенных операций требуются его полномочия;
password (пароль). Присвоенный пользователю пароль, который не является обязательным. Если для нового пользователя опустить выражение IDENTIFIED BY, пароль ему присвоен не будет (что не совсем разумно с точки зрения безопасности). Если же этот оператор задается для уже существующего пользователя, введенный пароль заменит используемый до настоящего момента. Старый пароль останется неизменным, если новый не будет определен. Строка пароля, задаваемая с помощью выражения IDENTIFIEDBY, должна представлять собой буквенную строку, которую при записи зашифрует оператор grant. Поэтому не следует применять функциюpassword(), применяемую с оператором SET password.
Оператор with grant option является необязательным. С его помощью можно предоставить пользователю все привилегии, определенные оператором GRANT для других пользователей. Этот оператор можно использовать для делегирования возможностей определенных категорий другим пользователям.
В именах пользователей, баз данных, таблиц и паролях, записываемых в таблицу разрешений, строчные буквы отличаются от заглавных. Регистр в именах компьютеров и столбцов таблиц не учитывается.
Чтобы определиться, какую же форму оператора GRANT применить, достаточно ответить на следующие вопросы.
Кто и откуда может подключаться к серверу?
Какой уровень привилегий должен иметь пользователь и на доступ к чему эти привилегии предоставляются?
Необходимо ли пользователю предоставлять административные привилегии?
Давайте попробуем ответить на эти вопросы и рассмотрим примеры оператора grant для создания учетных записей пользователей MySQL.
Кто и откуда может подключаться к серверу
Администратор может разрешить пользователю подключаться как с определенного компьютера, так и с различных компьютеров. В первом случае, если точно известно, что пользователи будут подключаться только со своих компьютеров, можно предоставить им такой доступ с помощью следующих операторов:
GRANT ALL ON samp_db.* TO boris@localhost IDENTIFIED BY "ruby"
GRANT ALL ON samp_db.* TO fred@ares.mars.net IDENTIFIED BY "quartz"
GRANT ALL ON samp_db.* TO max@% IDENTIFIED BY "diamond"
Символ "%" заменяет все возможные значения адресов и выполняет те же функции, что и при сравнении с помощью оператора LIKE. В предыдущем примере его можно условно заменить фразой "любой компьютер". Установка символа "%" аналогична простому опусканию части, задающей компьютер. Другими словами, эквивалентными в данном примере выступят записи max иmах@%. Это самый простой и, в то же время, самый незащищенный способ создать пользователя.
В случае необходимости можно также разрешить пользователю подключаться с ограниченного числа компьютеров. Так, чтобы пользователь mаrу мог подключаться с компьютеров домена snake.net, достаточно воспользоваться спецификатором %.snake.net:
GRANT ALL ON samp_db.* TO mary@%.snake.net IDENTIFIED BY "topaz"
Для определения компьютера можно применять не только имена, но и IP-адреса. Эти адреса можно задавать явно либо с помощью вспомогательных символов. Кроме того, в версии MySQL 3.23 появилась возможность определять IP-адреса, задавая маску сети, устанавливая число разрядов в сетевом номере:
GRANT ALL ON samp_db.* TO joe@192.168.128.3 IDENTIFIED BY "water"
GRANT ALL ON samp_db.* TO ardis@192.168.128.% IDENTIFIED BY "snow"
GRANT ALL ON samp_db.* TO rex@192.168 .128.0/17 IDENTIFIED BY "ice"
Первый оператор определяет только один компьютер, с которого может подключиться пользователь joe. Второй определяет набор IP-адресов для подсети класса С 192.168.128. В третьем операторе часть 192.168.128.0/17 определяет 17-разрядный сетевой номер и соответствует любому компьютеру с адресом 192.168.128 в первых 17 разрядах IP-адреса.
Если MySQL отказывается принимать определенные пользовательские значения, попробуйте заключить их в кавычки (необходимо отдельно заключать в кавычки имя пользователя и компьютера):
GRANT ALL ON samp_db.president TO "my_friend"@"boa.snake.net"
Какой уровень привилегий должен иметь пользователь и на доступ к чему эти привилегии предоставляются
Администратор может предоставлять пользователям привилегии разных уровней. Наиболее мощными являются глобальные привилегии, применяемые ко всем базам данных. Так, например, чтобы предоставить пользователюethel права суперпользователя, который может делать все, в том числе и предоставлять привилегии другим пользователям, необходимо запустить следующий оператор:
GRANT ALL ON *.* ТО ethel@localhost IDENTIFIED BY "coffee"
WITH GRANT OPTION
Спецификатор *. * в предложении ON можно условно заменить фразой "все базы данных и все таблицы". Для повышения безопасности подключаться пользователю ethel разрешено только с одного локального компьютера. Ограничение компьютеров, с которых может подключаться к серверу обладающий широкими правами пользователь, — весьма мудрое решение. В этом случае ограничивается и число компьютеров, с которых могут быть предприняты попытки взлома пароля.
Некоторые привилегии (FILE, process, reload и shutdown) являются административными и могут присваиваться только с помощью спецификатора глобальных привилегий ON *.*. В случае необходимости их можно присваивать без предоставления привилегий на уровне базы данных. Так, например, приведенный ниже оператор создает пользователя flush, который обладает возможностью только выполнять операторы FLUSH. Это может оказаться полезным в административных сценариях, когда необходимо выполнить обновление журналов:
GRANT RELOAD ON *.* ТО flush@localhost IDENTIFIED BY "flushpass"
В общем, как уже отмечалось ранее, административные привилегии присваиваются довольно редко, поскольку наделенные ими пользователи могут влиять на работу сервера.
Привилегии уровня базы данных применяются ко всем таблицам определенной базы. Такие привилегии присваиваются с помощью предложения ON db name:
GRANT ALL ON samp_db.* TO bill@racer.snake.net IDENTIFIED BY "rock"
GRANT SELECT ON menagerie.* TO ro_user@% IDENTIFIED BY "dirt"
Первый из указанных операторов предоставляет пользователю bill все права для работы со всеми таблицами базы данных sampdb. Второй оператор создает пользователя rouser с ограниченными правами (только чтение), который может получать доступ к любой таблице базы данных menagerie, однако только для чтения. Другими словами, этот пользователь имеет возможность запускать только оператор select.