Сравните синхронную репликацию с асинхронной по поведению записи при отказе реплики.
При синхронной репликации запись подтверждается только после фиксации на необходимом числе реплик. Поэтому отказ реплики может временно снизить доступность записи или увеличить задержку, зато подтверждённые данные с меньшей вероятностью потеряются при отказе основного узла.
При асинхронной репликации основная реплика подтверждает запись раньше, чем она попадёт на вторичные узлы. Это обычно сохраняет доступность и низкую задержку, но при отказе основной реплики часть подтверждённых данных может быть утрачена.
Репликация появилась как способ переживать отказы оборудования, увеличивать доступность данных и распределять нагрузку чтения. Однако копирование данных между узлами происходит не мгновенно, поэтому системе пришлось выбирать, в какой момент считать запись принятой.
Синхронный подход усиливает гарантию сохранности записи, жертвуя частью доступности. Асинхронный подход позволяет быстрее продолжать работу, принимая временное расхождение реплик и риск потери последних записей.
Пусть клиент отправил запись основной реплике, а та сразу вернула успешный ответ. Если запись ещё не передана вторичной реплике, отказ основной реплики создаёт неопределённость: данные могли быть приняты бизнесом, но отсутствуют на узле, который станет новым основным.
При синхронной схеме отказ обязательной реплики до подтверждения обычно приводит к ожиданию, ошибке или переключению на другой узел. При асинхронной схеме запись может продолжиться, но окно отставания реплик определяет объём потенциально потерянных данных.
В синхронной репликации отправитель ждёт подтверждения от одной или нескольких реплик, входящих в условие успешной записи. Важно уточнять, что именно подтверждается: получение сообщения, запись в журнал или устойчивое сохранение на диске. Эти варианты дают разные гарантии.
Если обязательная реплика недоступна, система должна выбрать между остановкой записи, сменой набора реплик и ослаблением требования. Ослабление гарантии повышает доступность, но превращает конкретную операцию в фактически асинхронную.
В асинхронной репликации основная реплика подтверждает запись независимо от того, догнали ли вторичные узлы. Репликационный журнал или поток изменений позже доставляет данные получателям. Чем больше задержка репликации, тем больше потенциальное окно потери при внезапном отказе основной реплики.
Синхронность не означает автоматическую защиту от всех проблем. Если подтверждение не связано с устойчивой записью, сбой питания может уничтожить данные даже после ответа. Кроме того, синхронная репликация не заменяет резервное копирование: ошибка приложения, удаление данных или повреждение, принятое системой, могут распространиться на все синхронные копии.
На практике часто используют компромисс: запись подтверждается после фиксации на кворуме реплик, а остальные копии обновляются асинхронно. Это позволяет пережить отказ части узлов, но требует корректного выбора кворума, процедуры восстановления отставших реплик и защиты от конфликтующих записей.
Сервис ведёт журнал платежей. Основная реплика находится в одном центре обработки данных, вторичная — в другом. При межцентровой задержке синхронное ожидание увеличивает время ответа каждой операции, зато подтверждённый платёж не должен исчезнуть вместе с первым центром.
Рассматривались два варианта. Полностью асинхронная схема давала минимальную задержку и позволяла принимать платежи при потере связи со вторым центром, но создавала риск утраты последних подтверждённых операций. Полностью синхронная схема защищала от потери основной реплики, однако при недоступности второго центра блокировала новые платежи.
Выбрали синхронное подтверждение внутри основного центра после фиксации на необходимом наборе узлов, а межцентровую репликацию оставили асинхронной. Это ограничило риск потери из-за отказа одного узла, сохранило приемлемую задержку, но не обеспечило нулевую потерю данных при разрушении всего основного центра; такой риск дополнительно покрывается резервным копированием и планом аварийного восстановления.
Нет. Гарантия зависит от числа подтверждающих реплик, устойчивости их журналов, корректности переключения лидера и сохранения данных после катастрофы. Если все синхронные реплики находятся в одном отказоустойчивом домене, его разрушение может уничтожить все подтверждённые копии.
Также нельзя считать надёжным подтверждением простое нахождение записи в памяти. Для защиты от сбоя питания требуется зафиксировать данные в устойчивом хранилище согласно гарантиям конкретной системы.
Записи снова станут доступными, но гарантия изменится: система может подтвердить данные без узла, отказ которого предполагалось пережить. Это разумный режим деградации только при явном понимании риска и контролируемом восстановлении реплики.
После возвращения узла он должен догнать журнал, пройти проверку целостности и безопасно войти в набор реплик. Иначе старые данные или неподтверждённые записи могут создать расхождение.
Без дополнительной гарантии нельзя: реплика может ещё не получить запись и вернуть старое состояние. Для read-after-write-поведения чтение направляют на узел, который уже подтвердил запись, используют отслеживание позиции репликации или ждут, пока выбранная реплика достигнет нужной позиции журнала.
Это не устраняет саму задержку репликации, а делает её явной частью протокола чтения. Если требовать чтение с отставшей реплики без ожидания, придётся принимать возможность устаревшего результата.