6.0 KiB
| aliases | tags | date | zero-link | parents | linked | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
Безмастерная репликация — это метод репликации в котором отсутствует главный 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
Мета информация
Область:: ../../../meta/zero/00 HighLoad Родитель:: Репликация БД Источник:: Автор:: Создана:: 2024-06-04