38 lines
2.9 KiB
Markdown
38 lines
2.9 KiB
Markdown
---
|
||
aliases:
|
||
- запись-чтение
|
||
tags:
|
||
- maturity/🌱
|
||
date: 2024-09-17
|
||
zero-link:
|
||
- "[[../../meta/zero/00 Базы Данных|00 Базы Данных]]"
|
||
parents:
|
||
linked:
|
||
---
|
||
Ситуация, когда после записи данных в master реплику вы пытаетесь немедленно прочитать те же данные с другой реплики. Это может привести к проблемам из-за задержек синхронизации между основным узлом и репликами.
|
||
|
||
![](../../meta/files/images/Pasted%20image%2020240607211343.png)
|
||
|
||
Основные причины, почему стоит избегать этого паттерна при репликации:
|
||
|
||
- [[../architecture/highload/Отставание реплики БД|Задержки репликации]]: Данные, записанные на основном узле, не сразу реплицируются на все реплики. При чтении с реплики можно получить устаревшую информацию.
|
||
- Непоследовательность данных: Вы можете получить неконсистентные данные, так как реплика может не успеть синхронизироваться с основным узлом.
|
||
- [[Race condition|Условие гонки]]: Возникает ситуация, когда операции записи и чтения конкурируют между собой. Это может привести к тому, что операция чтения прочитает данные до того, как завершится операция записи на всех узлах.
|
||
|
||
Чтобы избежать этих проблем, рекомендуется:
|
||
- Чтение данных с основного узла, если требуется сразу после записи.
|
||
- Использование механизмов согласованности, таких как кворумное чтение и запись, где для подтверждения операции необходимо согласие нескольких узлов.
|
||
- Настройка задержек или проверок синхронизации для гарантии, что данные были реплицированы перед чтением.
|
||
***
|
||
## Мета информация
|
||
**Область**:: [[../../meta/zero/00 Базы Данных|00 Базы Данных]]
|
||
**Родитель**::
|
||
**Источник**::
|
||
**Создана**:: [[2024-09-17]]
|
||
**Автор**::
|
||
### Дополнительные материалы
|
||
-
|
||
|
||
### Дочерние заметки
|
||
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|