Высокий уровень доступности
Реляционные СУБД разрабатывались в ту эпоху (1970-е гг.), когда в типичной организации имелась одна вычислительная машина. Если она выходила из строя, компания несла убытки из-за недоступности системы. Для решения проблемы аварийных ситуаций организации поддерживали и тщательно сохраняли журнальные ленты. При возникновении аварийной ситуации поставщик аппаратуры (обычно IBM) проявлял чудеса героизма, в течение нескольких дней поставляя новую аппаратуру и приводя ее в режим эксплуатации. Затем производилось восстановление системы на основе журнальных лент, что позволяло привести ее к почти тому состоянию, в котором она находилась до возникновения аварийной ситуации.
Десятилетием позже, в 1980-е гг. организации заключали контракты со службами восстановления после аварийных ситуаций, такими как Comdisco, на предмет обеспечения ресурсов резервной аппаратуры, так что имелась возможность быстрой установки журнальных лент на удаленных резервных компьютерах. Эта стратегия позволяла сократить время простоя предприятия по причине аварийной ситуации.
Сегодня имеются многочисленные организации, использующие горячее резервирование (hot standby), которое позволяет производить обработку отказов аппаратуры в реальном времени. В некоторых других компаниях поддерживается несколько основных вычислительных систем, что обеспечивает еще более быструю обработку отказов. Организациям оказывается выгодно платить за несколько систем, чтобы избежать сокрушительных финансовых последствий простоя, когда каждая минута простоя часто обходится в тысячи долларов.
Авторы ожидают, что в будущем высокий уровень доступности и встроенные средства восстановления после аварийных ситуаций станут важными чертами рынка OLTP (и других рынков). Из этого утверждения следует несколько очевидных выводов. Во-первых, в любой СУБД, ориентированной на OLTP, потребуется поддержка нескольких согласованных копий данных, для чего нужна возможность эффективного выполнения СУБД в grid, в состав которого входит несколько географически распределенных систем.
Во-вторых, у большинства поставщиков существующих РСУБД имеется интеграционная поддержка системы из нескольких машин поверх их исходной архитектуры, ориентированной на SMP (Symmetric MultiProcessor, симметричный мультипроцессор, компьютерная архитектура, в которой несколько процессоров имеет равноправный доступ к совместно используемой основной памяти). Очевидно, что гораздо более эффективной является поддержка архитектуры shared-nothing с самого начала разработки системы.
В третьих, наилучший способ поддержки архитектуры без общих ресурсов состоит в использовании нескольких машин в одноранговой (peer-to-peer) конфигурации. Тогда нагрузка OLTP может быть распределена между несколькими машинами, а межмашинную репликацию можно использовать для отказоустойчивости. В обычном режиме эксплуатации доступными являются ресурсы всех машин. При отказах деградация функционирования системы возможна только из-за сокращения числа ресурсов. В отличие от этого, во многих коммерческих системах реализуется режим горячего резервирования, при котором вторая машина, по существу, простаивает до тех пор, пока не возьмет на себя управление при отказе первой машины. В этом случае в обычном режиме эксплуатации используется только половина ресурсов, что является заведомо худшим решением. Эти доводы доказывают потребность в полном перепроектировании серверов РСУБД, чтобы в них можно было обеспечить одноранговую высокую доступность внутри новой архитектуры.
В высокодоступной системе, независимо от того, основывается ли она на горячем резервировании или является одноранговой, можно существенно упростить журнализацию. По-прежнему необходимо поддерживать журнал откатов (undo) на тот случай, если произойдет сбой внутри некоторой транзакции, и ее потребуется откатить. Однако журнал откатов не требуется сохранять после завершения транзакции. По существу, этот журнал может представлять собой некоторую структуру в основной памяти, которая удаляется при фиксации транзакции. Никогда не требуется производить повторное выполнение операций (redo), поскольку требуемого эффекта можно достичь путем восстановления данных по сети с удаленного узла.
Когда вышедший из строя узел возобновит свое функционирование, его состояние можно обновить за счет данных работающего узла.
В статье [LM06] утверждается, что процедуры обработки отказа узла путем передачи нагрузки на другой узел и восстановления функционирования узла, вновь вошедшего в строй, (failover/rebuild) настолько же эффективны, что и процедура прямого восстановления по журналу. Следовательно, у этого способа поддержки высокого уровня доступности, по существу, нет недостатков. В мире высокой доступности не требуется поддержка журнала повторного выполнения операций, нужен только временный журнал откатов. Это поразительно упрощает логику восстановления. Можно отказаться от подсистемы журнализации в стиле Aries [MHL+92] и пользоваться новыми функциональными возможностями для восстановления состояния узла, возобновляющего функционирование после отказа, на основе данных других узлов.
И в этом случае большая часть сложного кода существующих РСУБД оказывается ненужной, а требуются совсем другие средства.
