Управление репликацией
В традиционных системах баз данных принято поддерживать репликацию на основе схемы «активный-пассивный» путем пересылки журнальной информации. У каждого объекта имеется «активная» первичная копия, к которой, в первую очередь, направляются все изменения. Затем журнал изменений передается по сети в один или несколько «пассивных» резервных узлов. После этого в удаленных базах данных по журналу воспроизводятся изменения, выполненные в первичном узле.
У этой схемы имеется несколько недостатков. Во-первых, если не используется какая-либо разновидность двухфазной фиксации транзакций, то удаленные копии не являются транзакционно согласованными с первичной копией. Следовательно, если чтения должны быть транзакционно согласованными, то они не могут производиться над репликами. Если операции чтения направляются к репликам, то нельзя ничего сказать о точности ответов. Второй недостаток состоит в том то, что обработка отказа не является мгновенной. Следовательно, простои из-за сбоев являются более длительными, чем могли бы быть. В третьих, для поддержания реплик требуется журнал, а эксперименты авторов показывают, что на поддержку журнала уходит около 20% общего числа тактов процессора. Поэтому авторы полагают, что интересно было бы исследовать альтернативы репликации «активный-пассивный», такие как подход «активный-активный».
Основной причиной того, что в прошлом использовалась репликация «активный-пассивный» с пересылкой журнала, является то, что воспроизведение изменений по журналу обходится гораздо дешевле выполнения над репликой логики транзакции. Однако в системе баз данных в основной памяти время выполнения транзакции обычно составляет менее одной миллисекунды, что, вероятно, не намного превышает время, требуемое для воспроизведения изменений по журналу. В этом случае альтернативная архитектура «активный-активный» кажется вполне осмысленной. При этом подходе все реплики являются «активными», и транзакция выполняется синхронно надо всеми репликами. Преимуществом этого подхода является почти мгновенная обработка отказов, и отсутствует требование направления изменений сначала в узел с первичной копией. Конечно, в таком сценарии существенную дополнительную задержку будет порождать двухфазная фиксация, из чего следует потребность в технологии, избегающей использования двухфазной фиксации – возможно, путем выполнения транзакций в порядке временных меток.
