| aliases |
tags |
date |
zero-link |
parents |
linked |
|
|
|
|
|
|
|
Данная репликация работает на уровне самих запросов. То есть мастер сохраняет в журнал SQL запросы, а слейв получает этот список запросов и проигрывает их у себя.
В основе данной репликации лежит журнал Statement-based Binary Log.
Плюсы:
- Небольшое количество передаваемых данных, при однотипных изменениях. Например, если мы изменяем 5 миллионов строк одним запросом:
UPDATE users SET bonus=bonus+100, то нужно передать только 1 строку запроса.
- В журнале все записано в понятном человеко-читаемом виде.
Проблемы:
- Недетерминирован. Каждый запрос самостоятельно исполняется на слейве.
- Вызов функций, например функции
now(). В момент попадания запроса на slave это будет уже другое время.
- Остальные примеры
- uuid()
- fund_rows()
- rand()
- UDF
- триггеры на апдейт
- auto_increment поля
- Сложные запросы выполняются долго.
- Если запрос выполняется 10 минут, то он сначала будет выполняться 10 минут на мастере, а потом еще 10 минут на репликах.
Для того чтобы SBR работала корректно, есть специальный флажок.
