digital-garden/_inbox/Безмастерная репликация.md

aliases	tags	date	zero-link	parents	linked
	зрелость/🌱	2024-06-04	00 Базы Данных	Репликация БД

Клиент сразу пишет во все реплики. До каких-то информация доходит, до каких-то нет. Реплики возвращают результаты, клиент их подсчитывает. Если количество успешных ответов больше, чем заранее определенное число W, то мы считаем эту запись успешной. ==Если их меньше, но не 0, отката транзакции не будет.==

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

Формула расчета кворума: W + R > number of replics

• W - в каком количестве реплик должна примениться запись, чтобы мы считали ее успешной
• R - со скольки реплик мы должны прочитать значение ключа, чтобы считать, что чтение прошло успешным

Такая репликация есть в:

• DynamoDB
• Cassandra
• Scylla (Переписанная на C++ Cassandra)
• Riak
• Voldemort

Поддержание консистентности:

• Анти-энтропия. Реплики переодически ходят друг к другу и синхронизируются.
• Противодействие энтропии. Внешний клиент опрашивает все ноды, находит устаревшие данные и обновляет их.
• Обновление при чтении (Set on read). Берем последнюю версию после чтения и отправляем в реплики с устаревшими данными.
• Last write wins. Кто последний записал, те данные и верные.
• Happens before.
• Векторы версий.
• Tombstone

Проблемы:

• Нестрогий кворум. Возможно чтение старых данных при W+R < N
• Нет отката транзакций.
  • Как в таком случае работает обновление при чтении или противодействие энтропии, ведь эти данные становятся новыми.
• Конфликт записей и Потерянное обновление.
• Проблемы с линеаризуемостью.