34 lines
2.1 KiB
Markdown
34 lines
2.1 KiB
Markdown
---
|
||
aliases:
|
||
- лаг репликации
|
||
tags:
|
||
- зрелость/🌱
|
||
date:
|
||
- - 2024-06-04
|
||
zero-link:
|
||
- "[[00 Базы Данных]]"
|
||
parents:
|
||
- "[[Репликация БД]]"
|
||
linked:
|
||
---
|
||
|
||
Если SQL запрос достаточно тяжелый, то может возникнуть отставание реплик от мастера. Кажется такое возможно только в MySQL, когда например мы передаем на реплику сам запрос. Но если в PostgreSQL мы передаем не сам запрос, а блоки данных, то отставание по идее должно быть меньше.
|
||
|
||
|
||
|
||
В нормальной ситуации отставание достигает 1 секунды.
|
||
|
||
Что может приводить к лагу:
|
||
- Медленные и сложные запросы.
|
||
- Сетевые проблемы.
|
||
- Размер [WAL](Write-Ahead%20Log.md).
|
||
- Проблемы дисковой подсистемы реплики.
|
||
|
||
Рекомендации:
|
||
- Убивайте медленные запросы. Если запрос висит уже 10 секунд, то лучше его прибить.
|
||
- Держать отдельную реплику для медленных запросов.
|
||
- Думайте о кросс-СУБД репликации Репликация из реляционной бд в NoSQL
|
||
- Избегать паттерна запись-чтение 
|
||
- Свои данные читаем с мастера, чужие с реплики
|
||
- Читаем с других реплик через n секунд после записи. Но ничего не гарантируется
|
||
- Выделить отдельный жесткий диск под [Журнал БД](Журнал%20БД.md), чтобы обеспечить эксклюзивный доступ к ресурсам диска, тем самым улучшая производительность. Менее актуально для SSD. |