36 lines
2.1 KiB
Markdown
36 lines
2.1 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
- SBR
|
|||
|
|
tags:
|
|||
|
|
- зрелость/🌱
|
|||
|
|
date:
|
|||
|
|
- - 2024-06-02
|
|||
|
|
zero-link:
|
|||
|
|
- "[[00 MySQL]]"
|
|||
|
|
parents:
|
|||
|
|
- "[[Репликация в MySQL]]"
|
|||
|
|
linked:
|
|||
|
|
- "[[Row Based Replication (RBR)]]"
|
|||
|
|
---
|
|||
|
|
Данная репликация работает на уровне самих запросов. То есть мастер сохраняет в журнал SQL запросы, а слейв получает этот список запросов и проигрывает их у себя.
|
|||
|
|
|
|||
|
|
В основе данной репликации лежит журнал [Statement-based Binary Log](Журналы%20в%20MySQL.md#Statement-based%20Binary%20Log).
|
|||
|
|
|
|||
|
|
**Плюсы:**
|
|||
|
|
- Небольшое количество передаваемых данных, при однотипных изменениях. Например, если мы изменяем 5 миллионов строк одним запросом: `UPDATE users SET bonus=bonus+100`, то нужно передать только 1 строку запроса.
|
|||
|
|
- В журнале все записано в понятном человеко-читаемом виде.
|
|||
|
|
|
|||
|
|
**Проблемы:**
|
|||
|
|
* Недетерминирован. Каждый запрос самостоятельно исполняется на слейве.
|
|||
|
|
* Вызов функций, например функции `now()`. В момент попадания запроса на slave это будет уже другое время.
|
|||
|
|
- [Остальные примеры](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)
|
|||
|
|
- uuid()
|
|||
|
|
- fund_rows()
|
|||
|
|
- rand()
|
|||
|
|
- UDF
|
|||
|
|
- триггеры на апдейт
|
|||
|
|
- auto_increment поля
|
|||
|
|
- Сложные запросы выполняются долго.
|
|||
|
|
- Если запрос выполняется 10 минут, то он сначала будет выполняться 10 минут на мастере, а потом еще 10 минут на репликах.
|
|||
|
|
|
|||
|
|
Для того чтобы SBR работала корректно, есть специальный флажок.
|