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

Кроме таблиц синонимов, на каждом узле поддерживаются следующие данные.

1. Элементы каталога для каждого объекта, местом рождения которого является данный узел.

2. Элементы каталога для каждого объекта, хранимого в данный момент на данном узле.

Предположим теперь, что пользователь выдал запрос, содержащий ссылку на синоним MSTATS. Сначала система выполнит поиск соответствующего расширенного системного имени в подходящей таблице синонимов (простой локальный просмотр). После того как станет известен узел рождения (в нашем примере это узел в Лондоне), можно будет опросить каталог узла в Лондоне (здесь мы для общности подразумеваем удаленный просмотр- первое удаленное обращение). Каталог узла из Лондона будет содержать элемент для объекта в соответствии с п. 1. Если объект по-прежнему хранится на узле в Лондоне, он будет найден. Однако, если объект перемещен, скажем, на узел в Лос-Анджелесе, элемент каталога на узле в Лондоне будет содержать сведения об этом и система должна будет опросить каталог на узле в Лос-Анджелесе (второе удаленное обращение). Каталог на узле в Лос-Анджелесе будет содержать элемент для искомого объекта согласно п. 2. Таким образом, для поиска объекта будет выполнено не более двух удаленных обращений.

Кроме того, если объект вновь потребуется переместить, скажем, на узел в Сан-Франциско, системой будут выполнены следующие действия.

Вставка элемента в каталог на узле в Сан-Франциско.

Удаление элемента каталога на узле в Лос-Анджелесе.

Обновление элемента каталога на узле в Лондоне, который теперь будет указывать на узел в Сан-Франциско вместо узла в Лос-Анджелесе.

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

Отметим, что схема идентификации объектов, которая используется в распределенной СУБД DB2, хотя и подобна описанной выше, не полностью совпадает с ней.

Распространение обновлений

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

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

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

Одна копия для каждого реплицируемого объекта устанавливается как первичная копия, а все оставшиеся копии - как вторичные.

Первичные копии различных объектов находятся на различных узлах (поэтому данная схема все же является распределенной).

Операции обновления считаются логически завершенными, как только обновлена первичная копия. Узел, содержащий такую копию, будет отвечать за распространение обновления на вторичные копии в течение некоторого последующего времени. (Это последующее время , тем не менее, должно предшествовать операции завершения транзакции COMMIT, если должны гарантироваться АСШ-свойства распределенных транзакций, т.е. свойства атомарности, согласованности, изолированности и долговечности. Дополнительные замечания по этому вопросу будут приведены ниже.)

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

Замечание. Как уже указывалось, вследствие требования гарантии соблюдения АСШ-свойств транзакций, весь процесс распространения обновлений должен быть завершен прежде, чем соответствующая транзакция может быть зафиксирована ( синхронная репликация ). Однако несколько коммерческих продуктов поддерживают менее строгую форму репликации, в которой распространение обновлений откладывается на некоторое более позднее время (возможно, на некоторое указываемое пользователем время) и не обязательно в рамках соответствующей транзакции ( асинхронная репликация ). Фактически термин репликация, к сожалению, в какой-то степени узурпирован этими продуктами, в результате чего, по крайней мере на коммерческом рынке, под ним подразумевается, что распространение обновлений откладывается до тех пор, пока соответствующая транзакция не завершится (например, [20.1], [20.18] и [20.21]). Проблема подобного подхода с задержкой распространения обновлений заключается, конечно, в том, что база данных не может больше гарантировать согласованности всех ее данных в любой момент. В действительности пользователь даже может не знать, согласованна ли база данных.

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

1. Концепция репликации в системе с задержкой распространения обновлений может рассматриваться как применение идеи моментальных снимков, речь о которых шла в главе 9-. На самом деле лучше было бы использовать другой термин для такого вида репликации. Тогда можно было бы сохранить термин реплика для обозначения того, что понимается под ним в обычном разговоре (а именно - точной копии).

Замечание. Мы не утверждаем, что задержка распространения обновлений - плохая идея. Это, очевидно, самое лучшее, что можно было сделать при определенных обстоятельствах, как мы убедимся, например, в главе 21. Суть в том, что задержка распространения подразумевает, что реплики - не настояшие реплики, а система - не настоящая распределенная система баз данных.

2. Одна из причин (может быть, даже главная причина), по которой репликация в коммерческих продуктах реализована с задержкой расширения, заключается в следующем: альтернатива, т.е. обновление всех дубликатов перед выполнением операции COMMIT, требует поддержки двухфазной фиксации транзакции (см. ниже), что может существенно повлиять на производительность системы. Именно по этой причине в компьютерных журналах иногда встречаются статьи с озадачивающими названиями, например Репликация или двухфазная фиксация? (озадачивающими потому, что, по существу, в их названиях сравниваются качества совершенно разных предметов).

Управление восстановлением

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

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

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

За исключением того, что моментальные снимки предполагается использовать лишь для чтения (не считая периодического обновления), в то время как некоторые коммерческие системы разрешают пользователям обновлять дубликаты непосредственно (см., например, [20.21]). Конечно, данная воз.можность также противоречит независимости репликации.