Инструменты пользователя

Инструменты сайта


examination:rsubd:question16

Вопрос №16. Проблема распространения обновлений

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

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

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

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

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

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

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

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

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

examination/rsubd/question16.txt · Последние изменения: 2014/01/15 12:21 (внешнее изменение)