mv Sbase.3 Sbase.4 mv $base.2 Sbase.3 mv $base.l $base.2 mv Sbase.O Sbase.l mysqladmin flush-logs

Лучше всего запускать этот сценарий под учетной записью mysqladm, поскольку именно этот пользователь является владельцем файлов журналов. Если параметры подключения хранятся в конфигурационном файле .my.cnf, определять какие-либо параметры в команде mysqladmin этого сценария не нужно. В любом другом случае, возможно, имеет смысл создать пользователя с офаниченными привилегиями, который сможет только запускать команды FLUSH. Размещение пароля этого пользователя в сценарии не повлечет за собой большого риска. Такому пользователю следует присвоить только привилегию reload. Так, для вызова пользователя flush и присвоения ему пароля flushpass воспользуйтесь следующим оператором grant:

GRANT RELOAD ON *.* TO flush@localhost IDENTIFIED BY flushpass

Запуск процедуры заполнения в сценарии можно реализовать с помощью следующей команды:

mysqladmin -и flush -pflushpass flush-logs

На компьютерах, работающих под управлением ОС Linux, лучше воспользоваться командой logrotate и инсталлировать сценарий mysql-log-rotate, входящий в состав дисфибуции MySQL, чем писать свой собственный сценарий. Если этот сценарий не инсталлирован по умолчанию RPM-файлом, поищите его в каталоге support-files дисфибуции MySQL.

Ротация журналов обновлений немного отличается от ротации общих журналов, что объясняется своеобразным способом обработки сервером имен файлов журнала обновлений. Как уже отмечалось ранее, если администратор указывает серверу имя файла журнала обновлений без расширения, например, update, сервер автоматически генерирует имена журналов, согласно последовательности update. 001, update. 002 и т.п. Новый файл журнала создается каждый раз при запуске сервера или заполнении старого журнала. Если при активизации регисфации админисфатор вовсе не указывает имя файла для журнала, сервер генерирует такую же последовательность, выбирая в качестве основной части имени файла имя локального компьютера.

Удалять сгенерированные таким образом файлы лучше бы, конечно, учитывая период их создания, а не порядковый номер имени. Основная причина такого подхода заключается в том, что админисфатор не в состоянии точно проследить, когда сервером выполняются команды flush-logs. Соответственно и невозможно подсчитать точно число журналов обновлений, сгенерированных за определенный период време-

ни. Так, например, файл журнала обновлений с новым именем создается каждый раз при резервировании таблиц с помощью команды 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, однако создаваться новый файл не будет. Соответственно, сценарий ротации журналов обновлений будет отличаться от сценария ротации общих журналов только именем файла.

Для автоматической ротации и удаления лишних журналов можно воспользоваться командой сгоп. Предположим, что сценарии ротации обших журналов и журналов обновлений назьгеаются rotate-logs и rotate-update-logs И инсталлированы в каталоге /usr/users/mysql/bin. Зарегистрируйтесь в качестве пользователя mysqladm и выполните следующую команду редактирования файла crontab пользователя mysqladm:

% crontab -е

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

О 4 * * * /usr/users/mysqladm/bin/rotate-logs

О 4 * * * /usr/users/mysqladm/bin/rotate-update-logs

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

Резервирование и копирование баз данных

Администратор должен обязательно резервировать базы данных на случай повреждения или потери данных. Только благодаря резервированию все таблицы могут быть восстановлены в прежнее состояние в случае сбоя в работе системы. Кроме того, не исключен вариант, когда резервирование может оказаться единственным путем отступления, если какой-либо неопытный пользователь случайно выполнит операторы DROP DATABASE или DROP TABLE. Иногда сбой может произойти по вине собственно администратора MySQL. Так, автору этой книги известны случаи, когда администраторы разрушали файлы таблиц, пытаясь изменить их с помошью таких редакторов, как vi или emacs. Это далеко не самый лучший способ отредактировать таблицы!

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

Программа mysqldump тесно взаимодействует с сервером MySQL. Методы непосредственного копирования являются внешними по отношению к серверу и требуют проверки, чтобы клиенты не пытались изменить таблицы баз данных в процессе копирования. Эта же проблема имеет место при использовании для резервирования баз данных средств резервирования файловой системы. Если в процессе резервирования кто-то из пользователей изменяет таблицы, их файлы окажутся несовместимыми и не подлежащими восстановлению. Разница между резервированием файловой системы и непосредственным копированием файлов заключается в том, что в первом случае имеется возможность управлять расписанием резервирования.

Программа mysqldump медленней резервирует данные, чем методы непосредственного копирования.

Программа mysqldump создает простые текстовые файлы, которые можно легко переносить на другие компьютеры, даже с другой аппаратной архитектурой. Копируемые вручную файлы не могут переноситься на другие компьютеры, если, конечно, не используется специальный формат хранения MylSAM. ISAM-таблицы могут копироваться только между компьютерами с подобной архитектурой. Так, например, копирование файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором SPARC будет успешным, чего нельзя сказать о копировании файлов из системы Solaris на компьютере с процессором SPARC в систему Solaris на компьютер с процессором Intel. Впер-