Репликация/синхронизация MySQL: очистка от мастера, но не от подчиненного

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

У меня есть два сервера MySQL, один главный/горячий и один подчиненный/архивный. Все запросы на запись направляются ведущему устройству, а также (в конечном итоге) реплицируются/копируются на ведомое устройство. Однако некоторые данные в мастере через некоторое время (скажем, неделю) «устаревают» и затем должны быть очищены, чтобы таблицы мастера были короткими. Однако эта очистка не должна влиять на ведомое устройство. Как я могу добиться этого?

По сути, моя основная база данных действует как «горячая» база данных, в которой данные свежие и очищаются, как только они устареют. Он должен содержать данные, которые могут быстро понадобиться пользователям, и поэтому мы хотим, чтобы таблицы были небольшими. С другой стороны, мой подчиненный работает как архив, который должен содержать все данные, независимо от «горячости». Запросы к подчиненному устройству не должны выполняться быстро, а данные подчиненных устройств могут отставать на несколько минут, но они должны содержать все записи с начала нашего времени.

  • Моя первоначальная мысль состояла в том, чтобы использовать обычную репликацию, но могу ли я каким-то образом фильтровать определенные запросы, чтобы не влиять на ведомое устройство? Я думал о создании запроса purge, который удаляет старые данные с главного сервера, но не влияет на подчиненный. Из документации MySQL кажется, что эта фильтрация может выполняться только на уровне базы данных или таблицы.

  • Еще одна мысль заключалась в том, чтобы сделать это через внешнее приложение и вручную ВЫБРАТЬ данные из ведущего и ВСТАВИТЬ их в ведомое устройство, а затем использовать некоторую умную логику, чтобы решить, какие данные выбрать. Это хорошо работает для журнальных таблиц, которые всегда добавляют данные, но плохо работает для таблиц, которые представляют состояния, такие как пользовательские настройки. Этот подход, вероятно, также будет включать в себя множество особых случаев, так как я не могу найти хороший, последовательный способ описания всех таблиц в нашей базе данных (есть таблицы журналов, таблицы состояний, таблицы конфигурации и несколько, которые я не могу классифицировать). ).

Ни один из этих подходов не решает проблему простым способом, но я чувствую, что не могу быть первым, кто столкнулся с этой проблемой. Любые идеи приветствуются, и спасибо заранее.

Если нужна дополнительная информация, не стесняйтесь комментировать, и я отредактирую ее


mysql database
person Gikkman    schedule 20.09.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Просто используйте обычную репликацию. Когда вы удаляете данные на мастере, вы делаете это в том же сеансе

SET sql_log_bin = 0;
DELETE FROM my_table WHERE whatever = true;
SET sql_log_bin = 1;

Это предотвращает запись этих операторов в двоичный журнал. И поэтому он не будет реплицирован на ведомое устройство.

person fancyPants    schedule 20.09.2016
comment
Если я правильно понимаю, я должен вызывать это через SET SESSION sql_log_bin = 0, верно? Я только хочу, чтобы команда очистки не регистрировалась, все другие одновременные запросы все равно должны регистрироваться. - person Gikkman; 20.09.2016
comment
Да, это так. Это только предотвращает регистрацию операторов в этом сеансе. Заявления в других сессиях не затрагиваются. - person fancyPants; 20.09.2016
comment
Хорошо, я проведу некоторые тесты с этим, и если это сработает, я вернусь и отмечу это как правильное :-) - person Gikkman; 20.09.2016
comment
Работал как шарм. Спасибо за это! - person Gikkman; 22.09.2016