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