А есть возможность не писать бинарный лог для отдельной таблицы?

А, по умолчанию, сорян. Не сразу понял

Ответ не верный

да, я понял уже

Обычно это в программе указывают

вот тоже над этим размышлял

может кому пригодится решение stop_subscription DATETIME DEFAULT (current_date INTERVAL 31 day)

Добрый всем. А есть возможность не писать бинарный лог для отдельной таблицы ?

фильтры

но нужно внимательно читать как они работают

—binlog-ignore-*

говорит, что умеет только такое: «—replicate-ignore-table=db_name.tbl_name»

кто говорит? можно полный текст ошибки?

документация

О, я забыла, что binlog-inore-table нет 😱

Тогда через intermediary slave и —replicate-wild-ignore-table

С wild проблем не будет

поподробнее, пожалуйста

есть таблица MEMORY, мне не нужно, чтобы работа с ней логировалась

А почему?

Security?

нет, это тупо аккаунтинг радиуса

Много места в бэкапе занимает? Чем она мешает в логах?

за день — 800 мегабайт логов

хотя таблица там в 3 мегабайта сама

А всего сколько логов за день?

800 мегабайт

То есть вы в одну таблицу пишете?

да. в нее 99.99% записей идет

А потом как логи используете?

для этой таблицы — никак

А для других?

пока не пригождалось 🙂

можете в рамках сессии запись в бинлог выключать

А реплика?

есть?

пока реплики нету, раз в день бекапится вся база

То есть логи потенциально для восстановления?

да

Вам видимо только такой вариант подойдет
SET @@session.sql_log_bin=0;
INSERT/UPDATE/CREATE/ALTER/SELECT FOR UPDATE…
SET @@session.sql_log_bin=1;

И для резервного копирования нужно хранить бинарные логи на отдельной машине или, хотя бы, диске.

В общем, 800 МБ — это не много. Тут есть несколько вариантов:
1. Как уже сказали — отключать запись в бинлог для запросов в эту таблицу. Минус: требуются права суперпользователя.
2. Выделить отдельную базу для таблицы и фильтровать по —binlog-ignore-db
3. Продумать binary log rotation policy. Если вы делаете бэкап раз в сутки, то логов за 3-7 дней вам должно хватить. Это 2.4-5.6G — совсем мало. Но тут есть одно НО: вы должны проверять бэкапы каждый день. Это хорошая практика, но так мало кто делает, потом приходят за помощью с 3мя днями логов и последним рабочим бэкапом, сделатнным 2 месяца назад. В результате, мы ничем им помочь не можем.
4. Можно сделать агрессивную binary log rotation policy и дополнительно развернуть реплику с —replicate-wild-ignore-table. И на ней логи можно хранить сильно дольше. Но в этом случае всё равно нужно мониторить, чтобы а) лог скопировался с основного сервера до того как его удалили, б) что бэкапы работают как надо.

Всем привет. Можете подсказать, что я делаю не так?

И как это условие правильно сделать?

А если вместо id реальное имя указать product_id после p. в самом конце?

Как может получится, что с ванильными конфигами на Debian 11 Percona 8 и MariaDB 10.5 отдают результат на запрос SELECT COUNT(1) FROM table за 48 и 0.775 секунд соответсвенно?

Select count(1) from dual?

Или из таблицы?

Из таблицы, 3959039 строк

Какой движок в Percona, в MariaDB?

таблицы одинаковые?