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

38 lines
4.1 KiB
Markdown
Raw Normal View History

2024-06-13 21:01:37 +03:00
---
aliases:
tags:
- зрелость/🌱
date:
- - 2024-06-07
zero-link:
- "[[00 Базы Данных]]"
parents:
- "[[Репликация БД]]"
linked:
- "[[Синхронная репликация]]"
- "[[Полу-синхронная репликация]]"
---
Асинхронная (async). Если коммит прошел, то он прошел только на одной реплике, и когда-нибудь выполнится на остальных. Быстро, но не надежно. Возможно используется по умолчанию.
Реализовано в [MySQL](00%20MySQL.md), [PostgreSQL](00%20PostgreSQL.md)
Схема выполнения на MySQL.
![](Pasted%20image%2020240206195611.png)
**Как работает**
2024-07-11 08:53:53 +03:00
- Подготовка транзакции в движке БД: Транзакция начинается на главном сервере, где собираются все изменения данных.
- Запись транзакции в лог: Все изменения записываются в журнал транзакций (например, Write-Ahead Log в PostgreSQL).
2024-07-11 08:58:53 +03:00
- Завершение транзакции в движке БД: Транзакция завершается на master.
- Возврат результата клиенту: Клиент получает подтверждение о завершении транзакции
2024-07-11 08:53:53 +03:00
- Пересылка лога репликам: Журнал транзакций отправляется на реплики для асинхронного применения изменений.
- Воспроизведение транзакции на репликах: Реплики получают журнал и применяют изменения к своим копиям данных, но это может произойти с задержкой.
2024-06-13 21:01:37 +03:00
**Плюсы**
2024-07-11 08:58:53 +03:00
- Высокая производительность: Поскольку подтверждение транзакции возвращается клиенту до её применения на репликах, время отклика уменьшается, что улучшает производительность системы.
- Уменьшенная нагрузка на сеть: Пересылка изменений на реплики происходит асинхронно, что снижает нагрузку на сеть и позволяет более эффективно использовать сетевые ресурсы.
- Гибкость в использовании: Асинхронная репликация позволяет использовать реплики для различных задач, таких как отчеты или резервное копирование, без влияния на производительность главного сервера.
2024-06-13 21:01:37 +03:00
**Минусы**
2024-07-11 08:58:53 +03:00
- Потеря данных при сбое: Если master выходит из строя до пересылки изменений на реплики, данные могут быть потеряны. Это может привести к несогласованности данных и необходимости восстановления системы.
Отставание реплик: Задержка в применении изменений на репликах может привести к отставанию реплик от главного сервера, что может затруднить выполнение некоторых операций, требующих актуальных данных.
Проблемы с консистентностью данных: Каждая реплика может отставать по разному, из-за этого данные могут быть несогласованными между репликами. Например, пользователь может получить разные результаты для одного и того же запроса.