Безмастерная репликация — это метод репликации в котором отсутствует главный master. Все узлы системы являются равноправными.
Клиентские приложения могут записывать данные на любой узел системы. Более того запросы отправляются сразу на все реплики, но применяются только на тех, которые доступны в данный момент.
Для успешного завершения операции записи требуется подтверждение от определенного количества реплик (W). Если количество успешных записей превышает значение W, операция считается успешной. Если их меньше, но не 0, отката транзакции не будет.
Клиентские приложения читают данные со всех доступных в данный момент реплик. Для успешного чтения требуется подтверждение от определенного количества реплик (R). Если количество ответивших реплик превышает значение R, операция считается успешной.
Формула расчета кворума: W + R > number of replics
- W - в каком количестве реплик должна примениться запись, чтобы мы считали ее успешной
- R - со скольки реплик мы должны прочитать значение ключа, чтобы считать, что чтение прошло успешным
Преимущества:
- Высокая доступность: Поскольку все узлы являются равноправными, система не имеет единой точки отказа. Даже если несколько узлов выйдут из строя, остальные узлы продолжают обслуживать запросы.
- Горизонтальное масштабирование: Безмастерная репликация позволяет легко добавлять новые узлы для повышения производительности и масштабируемости системы.
- Гибкость конфигурации: Система может быть настроена для достижения различных уровней консистентности и доступности, в зависимости от требований приложений.
Проблемы:
- Нестрогий кворум. Возможно чтение старых данных при W+R < N
- Проблемы с откатом транзакций: В безмастерной репликации отсутствует механизм отката транзакций, что может усложнить управление ошибками и восстановление данных.
- Как в таком случае работает обновление при чтении или противодействие энтропии, ведь эти данные становятся новыми.
- Проблемы с консистентностью данных: Поскольку запись данных может происходить на нескольких узлах одновременно, возникает риск конфликтов и несогласованности данных. Для разрешения конфликтов используются различные методы, такие как Last Write Wins или версионирование данных.
- Конфликт записей и Потерянное обновление.
- Проблемы с линеаризуемостью.
Поддержание консистентности:
- Анти-энтропия. Реплики могут периодически синхронизоваться друг с другом, чтобы обеспечить консистентность данных.
- Противодействие энтропии. Внешний клиент опрашивает все ноды, находит устаревшие данные и обновляет их.
- Обновление при чтении (Set on read). Берем последнюю версию после чтения и отправляем в реплики с устаревшими данными.
- Last write wins. Кто последний записал, те данные и верные.
- Happens before.
- Векторы версий.
- Tombstone
Такая репликация есть в:
- DynamoDB
- Cassandra
- Scylla (Переписанная на C++ Cassandra)
- Riak
- Voldemort
Мета информация
Область:: 00 HighLoad
Родитель:: Репликация БД
Источник::
Автор::
Создана:: 2024-06-04