3.6 KiB
3.6 KiB
| aliases | tags | date | zero-link | parents | linked | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
При получении запроса от клиента master ожидает, пока все реплики получат новые данные и подтвердят их применение у себя, и только после этого сообщает клиенту, что запрос успешно выполнен. Работает надежно, но медленно.
Реализовано в PostgreSQL.
Как работает:
- Подготовка транзакции в движке БД: Транзакция начинается на главном сервере (мастере), где собираются все изменения данных.
- Запись транзакции в лог: Все изменения записываются в журнал транзакций, что обеспечивает возможность восстановления данных в случае сбоя.
- Пересылка лога репликам: Журнал транзакций отправляется на все реплики для синхронного применения изменений.
- Выполнение транзакций на репликах: Реплики применяют полученные изменения к своим копиям данных.
- Завершение транзакции в движке БД: После успешного применения изменений на всех репликах транзакция завершается.
- Возврат результата клиенту: Клиент получает подтверждение о завершении транзакции только после того, как изменения применены на всех репликах.
Плюсы:
- Высокая надежность данных: Данные не теряются даже в случае сбоя одного из серверов, так как изменения применяются на всех репликах одновременно.
- Консистентность данных: Обеспечивается консистентность данных на всех репликах, что исключает возможность получения различных результатов для одного и того же запроса.
Минусы:
- Увеличенное время отклика: Поскольку подтверждение транзакции возвращается клиенту только после её завершения на всех репликах, время отклика увеличивается. Это может негативно сказаться на производительности системы, особенно при большом количестве реплик.
- Высокая вероятность сбоев: С увеличением числа реплик общая вероятность сбоя возрастает, так как транзакция завершается только при успешном выполнении на всех репликах. Если хотя бы одна реплика не отвечает, транзакция не может быть завершена.