---
aliases: 
tags:
  - зрелость/🌱
date:
  - - 2024-03-10
zero-link:
  - "[[00 HighLoad]]"
parents:
  - "[[Репликация БД]]"
linked:
  - "[[Репликация master-slave]]"
---
Все реплики являются ведущими (мастерами), во все реплики можно писать изменения. А они каким-то образом синхронизируются между собой. Лидеры могут иметь дополнительные реплики в режиме [Репликация master-slave](Репликация%20master-slave.md).

![](Pasted%20image%2020240206194251.png)

**Плюсы**:
- Нет единой точки отказа
- Дает максимальный [High Availability](High%20Availability.md).
- Легкий failover

**Минусы:**
- Нет консистентности, есть конфликты. Могут возникать конфликты при работе с одним и тем же набором данных на разных репликах.
- Усложнение логики. Встречается редко.
- Не масштабирует запись. Для масштабирования нужно использовать [шардирование](Шардирование%20в%20БД.md).

**Варианты применения:**
- Географическая распределенность. Репликация между ЦОД.
	- Производительность.
	- Устойчивость к потере ЦОДа.
	- Устойчивость к проблемам сети
- Hot-standby реплика (VIP). Второй мастер всегда на готове, на случай если упадет основной. Во время штатной работы не используется.
- Offline клиенты. При плохом интернет соединении для асинхронного объединения данных. Пример БД CouchDB.

Варианты реализаций:
- Amazon Aurora
- Google Spanner
## Решение конфликтов
- Избегайте конфликтов
- Last write wins.  Выигрывает последняя запись. Но обычно сложно определить кто был первым.
- Ранг реплик. Выигрывает запись от старейшей реплки.
- Слияние. Объединение конфликтных данных.
- Решение конфликтов на клиенте.
- Conflict-free replicated data types (CRDT). 
- Mergeable persistent data structures.
	- В этом режиме работает [Git](Git.md)