digital-garden/dev/architecture/highload/Асинхронная репликация.md

54 lines
6.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
aliases:
tags:
- maturity/🌱
date:
- - 2024-06-07
zero-link:
- "[[../../../meta/zero/00 HighLoad|00 HighLoad]]"
parents:
- "[[Репликация БД]]"
linked:
- "[[Синхронная репликация]]"
- "[[Полу-синхронная репликация]]"
---
Изменения записываются на master и пересылаются на slaves с некоторой задержкой. Этот метод отличается от синхронной репликации тем, что подтверждение транзакции возвращается клиенту до того, как изменения применены на всех репликах, что позволяет улучшить производительность, но может привести к несогласованности данных.
Быстро, но не надежно. Возможно используется по умолчанию. Реализовано в [MySQL](../../../meta/zero/00%20MySQL.md), [PostgreSQL](../../../meta/zero/00%20PostgreSQL.md)
Схема выполнения на MySQL.
![](../../../meta/files/images/Pasted%20image%2020240206195611.png)
**Как работает**
- Подготовка транзакции в движке БД: Транзакция начинается на главном сервере, где собираются все изменения данных.
- Запись транзакции в лог: Все изменения записываются в журнал транзакций (например, Write-Ahead Log в PostgreSQL).
- Завершение транзакции в движке БД: Транзакция завершается на master.
- Возврат результата клиенту: Клиент получает подтверждение о завершении транзакции
- Пересылка лога репликам: Журнал транзакций отправляется на реплики для асинхронного применения изменений.
- Воспроизведение транзакции на репликах: Реплики получают журнал и применяют изменения к своим копиям данных, но это может произойти с задержкой.
**Преимущества**
- Высокая производительность: Поскольку подтверждение транзакции возвращается клиенту до её применения на репликах, время отклика уменьшается, что улучшает производительность системы.
- Уменьшенная нагрузка на сеть: Пересылка изменений на реплики происходит асинхронно, что снижает нагрузку на сеть и позволяет более эффективно использовать сетевые ресурсы.
- Гибкость в использовании: Асинхронная репликация позволяет использовать реплики для различных задач, таких как отчеты или резервное копирование, без влияния на производительность главного сервера.
**Минусы**
- Потеря данных при сбое: Если master выходит из строя до пересылки изменений на реплики, данные могут быть потеряны. Это может привести к несогласованности данных и необходимости восстановления системы.
- [Отставание реплики БД](Отставание%20реплики%20БД.md): Задержка в применении изменений на репликах может привести к отставанию реплик от master, что может затруднить выполнение некоторых операций, требующих актуальных данных.
- Проблемы с консистентностью данных: Каждая реплика может отставать по разному, из-за этого данные могут быть несогласованными между репликами. Например, пользователь может получить разные результаты для одного и того же запроса.
## Примеры использования
Асинхронная репликация широко используется в системах, где высокая производительность и низкое время отклика имеют приоритет над полной консистентностью данных. Например, в системах аналитики и отчетности, где задержки в обновлении данных не критичны, асинхронная репликация позволяет эффективно распределять нагрузку и использовать реплики для выполнения сложных запросов, не влияя на производительность основного сервера.
***
## Мета информация
**Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]]
**Родитель**:: [[Репликация БД]]
**Источник**::
**Автор**::
**Создана**:: [[2024-06-07]]
### Дополнительные материалы
- [[Синхронная репликация]]
- [[Полу-синхронная репликация|Полу-синхронная репликация]]
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->