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

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

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

■ Одна копия для каждого реплицируемого объекта устанавливается как первичная

копия, а все оставшиеся копии — как вторичные.

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

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

■ Примечание. Это последующее время, тем не менее, должно предшествовать опера ции завершения транзакции COMMIT, если должны гарантироваться свойства ACID распределенных транзакций (см. главы 15 и 16). Дополнительные замечания по этому вопросу будут приведены ниже.

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

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

отпечаток свойств этих продуктов, в результате чего, по крайней мере, на коммерческом рынке, под ним почти всегда подразумевается, что распространение обновлений откладывается до тех пор, пока соответствующая транзакция не завершится (например, см. [21.1], [21.16] и [21.18]). Недостаток подобного подхода с задержкой распространения обновлений заключается, безусловно, в том, что база данных не может больше гарантировать согласованности всех ее данных в любой момент4. В действительности, пользователь даже может не знать, согласована ли база данных.

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

1. Концепция репликации в системе с задержкой распространения обновлений мо жет рассматриваться как применение идеи снимков, речь о которых шла в главе 10. На самом деле, для обозначения такого вида репликации лучше было бы исполь зовать другой термин. Тогда можно было бы сохранить термин реплика для обо значения того, что понимается под ним в обычном смысле (а именно — точная копия). Но следует отметить, что снимки рассматриваются как предназначенные только для чтения (не считая их периодического обновления), тогда как некото рые системы позволяют пользователям обновлять такие реплики непосредственно (см. [21.18]). Безусловно, последний вариант представляет собой нарушение прин ципа независимости от репликации.

2. Мы не утверждаем, что задержка распространения обновлений — плохая идея.

Это — очевидно самое лучшее, что можно было сделать при определенных обстоя тельствах, как мы убедимся, например, в главе 22. Суть в том, что задержка рас пространения подразумевает, что "реплики" — не настоящие реплики (поскольку возможно, что любое конкретное значение данных на логическом уровне будет представлено с помощью двух или большего количества хранимых значений на физическом уровне, более того, что эти хранимые значения будут разными!), а система — не настоящая распределенная система баз данных.

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

4 Безусловно, если все операции проверки целостности выполняются немедленно (см. главы 9 и 16), то такие ситуации становятся невозможными. И даже если такая проверка откладывается до этапа вызова оператора COMMIT (а такой подход рассматривается нами как логически неправильный, но применяется во многих системах), подобные ситуации не могут возникнуть. Поэтому, в определенном смысле, отложенное распространение можно рассматривать как "еще более логически неправильный подход", чем отложенную проверку (если только можно рассуждать в терминах "более" или "менее" неправильного).