Репликация в MySQL 519

Теперь нужно остановить главный сервер или заблокировать все таблицы, подлежащие репликации. Создайте точные копии реплицируемых баз данных и лишь затем редактируйте конфигурационные файлы. Вспомните, что таблицы MySQL имеют системно-независимый формат. Это позволяет копировать и перемещать файлы, не меняя их формат. В листинге 29.4 создается tar-архив одной базы данных. Можно также выполнить на подчиненном сервере инструкцию LOAD TABLE, чтобы получить точную копию нужной таблицы.

[/usr/local/var]# tar cvfz freetimedb.tar.gz ./freetime/

Далее требуется включить двоичный журнал на главном сервере, внеся изменения в конфигурационный файл /etc/my. cnf. Соответствующая опция называется log-bin. С помощью опции server-id серверу присваивается уникальный идентификатор. В листинге 29.5 показаны две строки, которые добавляются в раздел [mysqld] конфигурационного файла. После внесения изменений нужно перезапустить главный сервер.

log-bin

server-id=l

Скопируйте на подчиненный сервер созданную выше копию базы данных и отредактируйте его конфигурационный файл. Добавляемые в него опции перечислены в листинге 29.6. Поскольку реплицируется лишь одна база данных, с помощью опции replicate-do-dЬзaдaeтcя конкретное имя: free time. Данномуподчиненному серверу присваивается идентификатор 2.

master-host=192.168.123.194

master-user=slave

master-password=password

master-port=3306

replicate-do-db=freetime

server-id=2

После изменения конфигурации запустите подчиненный сервер. Он свяжется с главным севером и проверит, изменштась ли база данных freetimec момента получения ее последней копии. Пока подчиненный сервер работает, он регулярно получает интересующие его изменения. Задержка обновления зависит от контекста, но обычно она составляет несколько секунд.

В листинге 29.7 перечислены инструкции, используемые в процессе репликации. Их описание можно найти в главе 13, Инструкции SQL . Инструкция CHANGE MASTER приводит к временной смене главного сервера. Она полезна в том случае, ко-

mysql> SHOW SLAVE STATUS \G ***************************

***************************

Master Host: 192.168.123.194 Master User: slave Master Port: 3306 Connect retrY: 60

Log File: red-bin.002 Pos: 312 Slave R-anning: Yes Replicate do db: freetime Replicate ignore db:

Last errno: 0 Last error:

Запуск юльких серверов 521

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

Если репликация применяется для улучшения производительности работы в организации, следуйте схеме, представленной на рис. 29.3. Приложение должно взять на себя заботу о том, чтобы изменения д елались лишь на главном сервере. Во всем остальном репликация должна быть абсолютно прозрачной. Если серверы, на которых хранится распределенная база данных, находятся на большом расстоянии друг от друга, попытайтесь внедрить схему круговой репликации. Например, можно закрепить за каждым сервером свой набор таблиц и позволить обновлять их только на одном сервере.

Каждый узел в схеме круговой репликации важен для нормальной работы системы. Чтобы свести к минимуму потери от сбоев, создайте дополнительные подчиненные серверы, не входящие в цепочку . Они предназначены для экстренной замены вышедшего из строя главного сервера.

Запуск нескольких серверов

Обычно сценарии Sаfe mysqld запускает сервер MySQL от имени специального пользователя. Но на самом деле любой пользователь системы может запустить свой сервер параллельно с другими серверами, при условии, что все онибудут работать с разными портами или сокетами.Таким способом часто обеспечивается повышенный уровень безопасности.

К примеру, провайдеры Internet продают дисковое пространство Web-серверов множеству пользователей. В такой открытой среде нельзя рассчитывать на то, что пользователи не будут злоупотреблять своими привилегиями, имея доступ к общим ресурсам. Вместо того чтобы предоставлять каждому пользователю отдельную базу данных и заниматься администрированием всего множества баз данных, провайдеры создают для каждого пользователя свой сервер. Это позволяет пользователям самостоятельно заниматься администрированием, не мешая остальным.

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

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

Данный сценарий работает с одним конфигурационным файлом, в котором у каждого сервера есть своя группа опций, объединеннгх под общим заголовком. В группу входят опции самого сценария, а названия остальных групп состоят из имени сервера и его номера, например [mysqldl3]. Опции каждой группы передаются соответствующему демону mysqld при егозапуске.