Репликация без ведущего узла

В главе кабанчика про репликацию («Высоконагруженные приложения» Мартина Клепманна) нам остался большой раздел про репликацию без лидера. Такой подход используется в базах Cassandra, Riak, Voldemort.

Клиент может сам отправлять информацию о своих операциях записи на несколько реплик или это может делать узел-координатор. Однако, в отличие от репликации с одним лидером, координатор не навязывает порядок операций записи.

Предположим, у нас есть БД с тремя репликами. Одна из них сейчас недоступна. Пользователь Олег меняет свой статус с «Работает» на «В отпуске». Операция записи отправляется параллельно всем трем репликам. Допустим, нам достаточно, что две из трех реплик подтвердили получение, после этого можно считать операцию записи успешной. Отсутствие подтверждения от одной из реплик просто игнорируется.

Ранее недоступная реплика снова начала работу. Во время ее недоступности данные в ней не обновлялись, а значит при чтении из этой реплики мы рискуем получить устаревшие значения. Пользователь Маша заходит посмотреть профиль Олега. Запрос на чтение направляется не к одной реплике, а сразу к нескольким параллельно. В ответ приходят разные ответы: актуальное значение «В отпуске» от двух реплик и устаревшее значение «Работает» от первой реплики, которая была недоступна и не получила запроса на обновление. Чтобы определить, какое значение новее, используются номера версий.

Каким образом ранее недоступная реплика после возобновления работы может наверстать пропущенные ею операции записи? Есть два механизма:

🔼Разрешение конфликтов при чтении. Клиент, читающий данные с нескольких реплик параллельно, способен обнаружить все устаревшие ответы и записать вместо них актуальные значения.

🔼Процесс противодействия энтропии. В некоторых БД есть фоновый процесс, постоянно выискивающий различия в данных между репликами и копирующий отсутствующие данные из одной реплики в другую. В отличие от журнала репликации при репликации с одним лидером, порядок записей здесь может не соблюдаться.

В базах данных с репликацией без лидера возможна конкурентная запись значения для одного ключа несколькими клиентами. То есть могут возникать конфликты записи, как при репликации с несколькими лидерами. Стратегии работы с конфликтами кратко описаны в посте про репликацию с несколькими лидерами.

#кабанчик #сисдиз #репликация