MySQL. Библиотека профессионала - Аткинсон Л

Глава 29. Распределенные базы данных

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

К недостаткам распределенных баз данных можно отнести то, что возрастает слож ность управления ими. Но преимуществ все же больше. Главное из — повышение изводительности. Данные быстрее обрабатываются несколькими серверами, а кроме того, данные располагаются ближе тем пользователям, которые чаще с ними работают.

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

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

баз данных связано с достаточно высоким риском. Требуется обеспечить соблюдение

хранения данных. Как клиенты, так и серверы должны уметь обрабатывать запросы к данным, которые не расположены в ближайшей системе. Плохо спроектированная РБД может демонстрировать меньшую производительность, чем одиночный сервер.

РБД состоит из трех основных частей: клиентов, модуля обработки транзакций и хранилища данных. Сервер обычно берет на себя задачи обработки транзакций и хранения данных, хотя в полностью распределенной базе данных за решение этих за дач отвечают разные аппаратные компоненты. Обратимся к рис. 29.2. Здесь три кли ента взаимодействуют с двумя модулями обработки транзакций, которые, в свою оче редь, работают с двумя хранилищами. Клиенты посылают свои запросы модулям, а те определяют, в каком из хранилищ находятся требуемые данные.

Концепции распределенных баз данных

Рис. 29.2. Распределенные серверы

В идеале клиенты не знают, является система распределенной или нет. Они лишь посылают ей запросы, а система возвращает клиентам результаты этих запросов. Как она это делает, клиентов не интересует. На практике распределенные базы данных проявляют разную "прозрачность". В крайнем случае РБД хранится на нескольких не зависимых серверах, а клиентскому приложению приходится выбирать сервер в зави симости от того, какую информацию требуется получить. Это что таб лицы, находящиеся на разных серверах, не имеют никаких внутренних связей. Есте ственно, такая организация РБД лишь изредка оказывается полезной.

Система управления распределенными базами данных, или предоставляет клиентам унифицированный интерфейс доступа к данным, благодаря которому возни кает иллюзия единого сервера. Если данные находятся в разных местах, РСУБД посыла ет запросы и обновления в соответствующие хранилища. В зависимости от того, с каким хранилищем ведется работа, производительность системы может оказаться разной, но, по крайней мере, клиентам не приходится самим заниматься выбором сервера.

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

В РБД применяется несколько схем распределения данных. В случае репликации каждый сервер хранит весь объем данных. Для этого требуется, чтобы РСУБД дубли ровала транзакции, позволяя всем клиентам видеть согласованный образ базы дан ных. В случае несимметричного разделения данных выбирается уровень сегментации. На самом высоком уровне расщеплению подвергаются отдельные базы данных, но не таблицы. Каждая таблица целиком находится в каком то одном месте. На более низ ком уровне таблицы расщепляются по строкам или столбцам. Например, при гори зонтальном расщеплении отдельные подмножества записей помещаются в разные хранилища, а при вертикальном расщеплении подмножества формируются на осно вании столбцов.

Глава 29. Распределенные базы данных

Отложенная синхронизация

Создать точную копию базы данных MySQL довольно просто. Способы резервного копирования баз данных описывались в главе 25, "Устранение последствий катаст роф". Что касается восстановления данных, то это можно сделать на любом сервере. Располагая такими средствами, несложно реализовать распределенную базу данных, синхронизируется через достаточно большие промежутки времени, напри мер раз в день.

Рассмотрим проблему обновления данных. Если обновления происходят сразу на двух серверах, их нужно согласовывать. Чтобы не возникали неразрешимые ситуа ции, необходимо позволить вносить изменения только на одном сервере. Тогда син хронизация будет заключаться в дублировании содержимого сервера, доступного для записи, на все остальные серверы. Их полезность зависит от того, насколько важна актуальность данных. Во многих случаях база данных, содержащая все записи, кроме тех, которые были созданы за последние 24 часа, вполнеприемлема.

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

рейтинги популярности. Раз в день все серверы посылают свои журнальные главному серверу, который корректирует рейтинги согласно новой статистике. Схема такой базы данных приведена в листинге

распределен»

Каталог

CREATE TABLE song

ID INT NOT NULL

Name NOT NULL,

Artist NOT NULL,

Filename NOT NULL,

PRIMARY

INDEX

INDEX (Artist)

Журнал запрашиваемых

Song INT NOT NULL,

NOT NULL

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

Раз в день таблицы log всех серверов объединяются по следующему сценарию. Один из серверов прекращает обслуживать запросы Web приложений. Остальные серверы создают копии таблицы log, извлекают из них последние записи и посылают

Отложенная синхронизация

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

Сервер, генерирующий отчет, загружает полученные данные в свою таблицу log, послечеговыполняетсценарий, показанныйвлистинге29.2.Вэтом сценариисозда ются два рейтинга популярности: по всем песням и за последние 24 часа. Временный индекс таблицы log ускоряет ее просмотр.

Создание индекса.

CREATE INDEX song ON log

Определение рейтинга всех песен.

DROP TABLE IF EXISTS

CREATE TABLE

Rank INT NOT NULL,

Song INT NOT NULL,

Hits INT NOT NULL

SET @id 0;

INSERT INTO

SELECT Song,

FROM log

GROUP BY 2

ORDER BY 3 DESC;

ALTER TABLE

ADD PRIMARY

Определение рейтинга песен за последние 24 часа.

DROP TABLE IF EXISTS

CREATE TABLE

Rank INT NOT NULL,

Song INT NOT NULL,

Hits INT NOT NULL

Глава 29. Распределенные базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 29. Распределенные базы данных

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

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

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

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

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

таблица

таблица

чиненный

он

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

GRANT FILE ON ТО slave IDENTIFIED BY

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

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

tar

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

server id=l

Скопируйте на подчиненный сервер созданную выше копию базы данных и отре дактируйте его конфигурационный файл. Добавляемые в него опции перечислены в листинге 29.6. Поскольку реплицируется лишь одна база данных, с помощью опции задаетсяконкретное имя: Данномуподчиненному сер веру присваивается идентификатор 2.

server id=2

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

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

SHOW SLAVE STATUS \G

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

Master_Host:

Master_User: slave

Master_Port: 3306

Connect_retry: 60

Log_File:

312

Yes

Last_errno: 0

0

1 row in set (0.00 sec)

Запуск серверов

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

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

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

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

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

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

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

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

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