VoltDB Ответ на группу вопросов, касающихся защиты данных во время плановых или аварийных остановок кластера:

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

Следующий, более низкий уровень защиты - это "reverse caching", те периодические снэпшоты (своего рода incremental backup) базы на локальные диски каждого нода в кластере. Обычно, с периодичностью до часа, во многих системах - каждые 10 -15 минут. Идея в том, что если "отрубили электричество", то обычно у системы есть хоть какое-то гарантированной время для продолжения работы на резервном питании с UPS-батарей и, соответственно, перейти в аварийный режим и сохранить данные из памяти на диск. Этот уровень защиты предохраняет от аварии на уровне кластера.

Для защиты от аварий на уровне одного или нескольких нодов, обычно применяется K-safety кластера: транзакция не коммитнется до тех пор, пока копия изменения не гарантирована на другом ноде в кластере, то если любой нод падает, данные могут быть восстановлены из других нодов (концептуально и функционально напаминает Redundant. Array of Inexpensive Drives, но имплементация другая, те сравнение с RAID 5 в было бы не совсем корректно). Такая защита, конечно, предполагает дополнительную задержку, но при скоростях передачи данных на современных сетях и с учетом, что копия создается только в памяти другого нода (а не на диске), такой подход выглядит как вполне разумный компромисс между высокой надежностью и высокой производительностью системы. K-safety может быть сконфигурирована с К>1, те можно создавать дополнительные копии, и таким образов выживать потерю более чем одного нода. Чем больше К, тем надежнее (но медленнее) система. Фейловер полностью автоматический, равно как и восстановление и обновление данных в случае возврата остановленного нода, и никоем образом не отражается на работоспособность подключенных клиентов.

Это общие подходы, а технические детали как узнать? Отказались от механизма redo/undo, а что взамен? Как сделать бекап 100 машин кластера? Ведь нам нужна согласованная копия. Да, можно остановить весь кластер, но не забываем, у нас OLTP, а значит длительный простой невозможен.
Как реплицировать данные в другой ДЦ? В Vertica это решается дублированием поставки даных, а что здесь?
K>1 - хорошо, а как узнать, что все mirror-копии валидны? Данные в памяти тоже могут портиться, значит, неплохо было бы периодически проверять, все ли копии у нас согласуются с оригиналом. Ну или проверять checksum или что там у вас вместо него.