Кластер из трёх реплик подтверждает запись после ответа одной реплики. Что произойдёт с гарантией сохранности этой записи при отказе ответившего узла?
Подтверждение после ответа одной реплики не гарантирует сохранность записи при отказе этого узла. Если остальные реплики ещё не приняли или не записали данные устойчиво, запись может быть потеряна.
Для защиты от отказа одной реплики обычно используют синхронную репликацию с кворумным подтверждением: запись считается принятой только после её фиксации на достаточном числе реплик. Для кластера из трёх реплик это обычно означает подтверждение от двух, но точная гарантия зависит от того, что система считает фиксацией записи.
Репликация появилась как способ переживать отказ дисков, серверов и сетевых соединений без потери данных и полной остановки сервиса. Однако отправка записи на несколько узлов увеличивает задержку, поэтому распределённые системы разделяют момент принятия записи клиентом и момент её распространения на остальные реплики.
Асинхронная репликация уменьшает задержку подтверждения, но оставляет временное окно, в котором данные существуют только на одном узле. Синхронная репликация закрывает это окно ценой большей задержки и возможного отказа записи при недоступности нужного числа реплик.
Пусть клиент отправил запись на одну из трёх реплик. Узел записал её в память или на локальный носитель и сразу ответил об успехе, но ещё не передал данные двум другим узлам. Если после этого ответивший узел вышел из строя, кластер может продолжить работу без записи.
Риск зависит от смысла подтверждения. Успешный ответ может означать только принятие данных процессом, запись в буфер операционной системы или устойчивую фиксацию на диске. Эти состояния дают разные гарантии после сбоя питания, повреждения узла или его окончательной потери.
Неверное понимание подтверждения приводит к ложному выводу: клиент считает данные сохранёнными, хотя система защищает их лишь от кратковременной задержки, но не от отказа единственной реплики. Повторная запись после сбоя также может быть небезопасной без идемпотентности или уникального идентификатора операции.
При кворумной записи операция подтверждается после получения успешного результата от заранее определённого числа реплик. В кластере из трёх узлов кворум из двух позволяет пережить отказ одного узла: подтверждённая запись уже присутствует как минимум на двух репликах.
Важно, чтобы реплика считалась подтвердившей запись только после требуемой стадии фиксации. Если данные лишь находятся в оперативной памяти и могут исчезнуть при потере питания, кворум реплик не равен гарантии долговечности. Система должна явно определить, означает ли подтверждение запись в журнал, принудительную фиксацию на устойчивом носителе или только получение данных процессом.
Кворум — это не универсальная гарантия от всех проблем. Он защищает от отказа определённого числа узлов в рамках заданной модели отказов, но не обязательно от одновременного уничтожения нескольких площадок, ошибок оператора, повреждения данных или некорректной логики репликации.
У кворумной политики есть компромиссы:
Нужно также различать кворум записи и кворум чтения. Кворумная запись помогает сохранить данные, но видимость самой свежей версии при чтении зависит от алгоритма выбора реплики, версии записи и политики чтения. Для согласованного чтения часто требуется совместить правила чтения и записи так, чтобы множества реплик пересекались, однако это уже отдельная гарантия, а не автоматическое следствие любого кворума.
Сервис заказов записывает состояние заказа в кластер из трёх узлов. Сначала рассматривались два варианта: подтверждать запись после одного узла или ждать двух.
Первый вариант минимизирует задержку и продолжает принимать записи даже при проблемах с двумя репликами, если единственный доступный узел продолжает работать. Его недостаток — подтверждённый заказ может исчезнуть при отказе этого узла до завершения асинхронной репликации.
Второй вариант требует устойчивой фиксации на двух репликах. Он переживает отказ одной из них без потери уже подтверждённого заказа, но при сетевом разделении может отклонять запись, если сервис не видит кворум. Для критичного состояния заказа выбрали второй вариант, а для менее важных временных событий допустили асинхронную доставку.
В результате политика подтверждения стала соответствовать цене потери данных: критичные записи получают более сильную гарантию, а некритичные не заставляют основной путь запроса ждать все реплики. Отдельно контролируются задержка репликации, доля записей без кворума и состояние устойчивой фиксации.
1. Достаточно ли подтверждения от двух из трёх реплик для гарантии сохранности записи?
Нет, не во всех смыслах. Оно защищает от отказа одной реплики только при условии, что обе подтвердившие реплики действительно приняли запись согласно требуемой модели долговечности. Если подтверждение означает лишь наличие данных в памяти, одновременная потеря питания может уничтожить запись на всех узлах.
Кроме того, гарантия ограничена моделью отказов. Кворум из двух узлов не спасает от одновременного отказа двух реплик, разрушения общей зоны размещения, ошибки удаления данных или повреждения самой записи. Поэтому в архитектуре отдельно задают требования к размещению реплик, устойчивому журналированию и резервному копированию.
2. Почему кворумная запись может повысить надёжность, но снизить доступность?
Для подтверждения требуется доступное пересечение реплик. При отказе одного узла из трёх кворум из двух ещё достижим, но при сетевом разделении, когда клиент видит только одну реплику, запись нельзя безопасно подтвердить: неизвестно, не принял ли её другой сегмент кластера.
Если система продолжит подтверждать записи в меньшинстве, она сохранит доступность ценой риска расхождения или потери данных. Если она требует кворум, то отказывается от части операций во время разделения. Это проявление компромисса между доступностью и согласованностью, а не недостаток конкретной реализации.
3. Может ли запись, подтверждённая на двух репликах, всё равно потеряться из-за задержки третьей?
Обычно отказ третьей реплики сам по себе не должен привести к потере такой записи: после восстановления она может получить данные от оставшихся реплик. Однако это зависит от корректности протокола репликации, сохранения версии записи и способности системы выбрать актуальную копию.
Задержка третьей реплики влияет прежде всего на восстановление избыточности. Пока она не синхронизирована, кластер имеет меньший запас на случай ещё одного отказа. Поэтому после подтверждения нужно отслеживать не только успешность операций, но и состояние отстающих реплик, длительность восстановления и фактический запас отказоустойчивости.