(Designing Data-Intensive Applications)
Рисунок 5-1. Репликация на основе лидера (master–slave).
Рисунок 5-2. Репликация на основе лидера с одним синхронным и одним асинхронным последователями
Исследования по репликации
Рисунок 5-3. Пользователь выполняет запись, за которой следует чтение из устаревшей реплики. Чтобы предотвратить эту аномалию, нам нужна согласованность чтения после записи
Рисунок 5-4. Пользователь сначала считывает данные из новой реплики, затем из устаревшей реплики. Кажется, что время идет вспять. Чтобы предотвратить эту аномалию, нам нужны монотонные чтения
Рисунок 5-5. Если некоторые разделы реплицируются медленнее, чем другие, наблюдатель может увидеть ответ раньше, чем увидит вопрос
Рисунок 5-6. Репликация с несколькими лидерами в нескольких центрах обработки данных
Рисунок 5-7. Конфликт записи, вызванный одновременным обновлением двумя руководителями одной и той же записи
Автоматическое разрешение конфликтов
Рисунок 5-8. Три примера топологий, в которых может быть настроена репликация с несколькими лидерами
Рисунок 5-9. При репликации с несколькими лидерами записи в некоторые реплики могут поступать в неправильном порядке
Рисунок 5-10. Запись кворума, чтение кворума и восстановление чтения после сбоя в работе узла
Рисунок 5-11. Если w + r > n, то по крайней мере одна из реплик r, из которых вы читаете, должна была видеть самую последнюю успешную запись
Рисунок 5-12. Параллельная запись в хранилище данных в динамическом стиле: нет четко определённого порядка
Параллелизм, время и относительность
Рисунок 5-13. Фиксация причинно-следственных зависимостей между двумя клиентами, одновременно редактирующими корзину покупок
Рисунок 5-14. График причинно-следственных зависимостей показан на рисунке 5-13