Таблицы рейтингов не содержав четчик, вместо него используется инкремент-ная переменная. Будучи созданной, рейтинговая таблица уже не меняется. Сценарий удаляет существующие таблицы и формирует их заново. Имеет смтсл сжимать такие таблицы с помощью утилиты inyi sampack (см. главу 14, Утилиты командной строки ). Созданные таблицы загружаются остальнымисерверами, где они заменяют старые рейтинги.

Изменения в таблицу song должны вноситься на одном сервере. Тогда исчезают проблем!, связанные с дублированием песен и первичнгх ключей. Главный сервер публикует новую редакцию каталога песен либо после каждого изменения, либо по определенному графику.

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

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

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

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

Рис. 29.3. Схема репликации с одним сервером для записи и двумя серверами для чтения

Все серверы работают под управлением MySQL на разных подклю-

ченн1х к сети. В целях синхронизации подчиненные серверы регулярно связываются с главным сервером. Последний фиксирует каждое изменение в двоичном журнале (см. главу 24, Физическое хранение даннтх ). Если не считать короткие промежутки времени, в течение которых происходит синхронизация, подчиненные серверы содержат зеркальные копии базы данных.

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

Клиенты могут посылать запросы на выборку ка мому, так и любому подчиненному серверу. Запись данных должна происходить только на главном сервере, иначе изменения останутся локальными. В схеме на рис. 29.3 запросы на выборку направляются только подчиненным серверам, что позволяет главному серверу сосредоточиться на обновлениях.

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

Рис. 29.4. Круговая репликация

Приложение должно предотвращать несогласованные обновления. Рассмотрим такой случай. Серверы А и Б являются друг для друга главным и подчиненным сервером. Оба используют таблицу сообщений с первичным В определенный

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

В схеме на рис. 29.4 каждое приложение взаимодействует с одним сервером, хотя это необязательно. Если серверы расположены рядом, можно формировать пул веров. Тогда при выборе сервера приложение сможет учитывать возможность сбоя или применять алгоритм выравнивания нагрузки.

Подчиненный сервер контролирует, какое изменение было получено от главного сервера последним. По умолчанию сведения об этом находятся в файл ter. info.

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

В MySQL версии 3.23.39 механизм репликации имеет ря чений; В основном все они связаны с тем, что изменения фиксируются только в двоичном журнале. Функция RAN) по умолчанию инициализирует генератор псевдослучайных чисел значением системных часов, но это значение не сохраняется в двоичном журнале. В подобной ситуации можно инициализировать генератор самостоятельно с помощью функции UNIX TIMESTAMP ().

Вспомните, что изменения таблиц привилегий в базе данныя! не вступят в силу, пока не будут очищены буферы привилегий. Но дело в том, что в двоичном журнале не отслеживаются инструкции FLUSH, поэтому старайтесь не менять таблицы напрямую, а пользуйтесь инструкциями GRANT и REVOKE.

Значения переменных не реплицируются. Если в обновлении строки участвовала переменная, то на подчиненном сервере будет использовано локальное, а не реальное значение этой переменной.

Чтобы включить функции репликации, нужно отредактировать конфигурационные файлы сервера. Ниже перечислены опции демона mysqld, имеющие отношение к репликации. Все они б1ли описаны в главе 14, Утилиты командной строки .

-binlog-do-db=бaзa лaнныx

-binlog-ignore-db=6aза данных

-log-bin-index=кaгaлor

-log-bin[=каталог]

-log-slave-updates

-master-connect-ret гу=секундьг

--master-host=yзeл

-master-info-£11е=файл

-master-password=пароль

-raaster-port=nopT

-master-user=яoльзoвaтeль

-replicate-do-db=бaзa дaныx

-replicate-do-table=бaзa дaнныx .таблица

- replicate-ignore-db=бasa дaнньrx

- replicate-ignore-table=бaзa лaнныx .таблица -replicate-rev/r 1Ье-йЬ=главиый->помчиненный -replicate-wild-do-table=шaблoн

-replicate-wild-ignore-table=ztfa блон --server-i с1=идентифика тор

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

GRANT FILE ON

ТО slave IDENTIFIED BY password;