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

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

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

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

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

Один из методов, позволяющий частично решить проблему доступности, – это стратегия первичной копии: для каждого реплицируемого объекта выделяется один узел, который объявляется хранителем первичной копии (primary copy) данного объекта. Когда производится обновление в масштабах системы, хранящий первичную копию узел запрашивает предоставление блоков в рамках всей системы. Если узел, содержащий первичную копию, зафиксировал обновление, операция обновления считается завершенной. Это означает, что все другие узлы, которые пытаются выполнить фиксацию, могут использовать данный объект базы данных так, как если бы он был уже изменен повсюду. В узлах, которые вследствие возникновения локальных проблем не могут завершить фиксацию, просто локально блокируется использование данного конкретного объекта. Это не влияет на функционирование остальных узлов.

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

ФАЗА 1. Узел-координатор посылает информацию об обновлении и запрос о готовности к фиксации всем узлам, содержащим копии обновляемого объекта базы данных. Каждый узел проверяет, может ли он выполнить фиксацию, и посылает ответный сигнал ДА или НЕТ;

ФАЗА 2. Если хотя бы один узел посылает сигнал НЕТ, узел-координатор посылает по системе сигнал отмены, означающий, что все узлы должны игнорировать информацию об обновлении и работать так, как если бы сигнал-предупреждение о фиксации не посылался. При всех ответных сигналах ДА по всей системе посылается сигнал "Commit" (зафиксировать). После того, как узел выполнил фиксацию, он может считать ее завершенной и снять все локальные блоки.

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