Есть MySQL БД, с постоянными изменениями данных. Как организовать выгрузку изменений таблиц за последний час, или пять минут?

Триггеры на обновление везде, которые меняют change_date на текущую + дамп id изменённых строк+имён таблиц+ревизия куда-нибудь + хоть вызов внешних программ через sys_eval по триггеру/приделать event'ы в rabbitmq или другой брокер. Короче, БД будет у тебя - вариантов масса, но с десятиминутками - самый конченый, забудь об этом совсем.

Вот, кстати, плагин для кролика: https://github.com/ssimicro/lib_mysqludf_amqp можешь снимать данные хоть в реальном времени.

т.е. нарушается целостность

Как правило изменения вносимые транзакциями не видны до коммита, это зависит от уровня изоляции. https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html

Что имеется ввиду под «+ дамп id изменённых строк+имён таблиц+ревизия куда-нибудь» не понял

в той же самой БД (можно в другой если будет мешать)для каждой «tablename» будет создана «tablename_log», в которую триггер будет писать измененные данные + временную метку, структура таблиц будет одинаковой .

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

При Вашем подходе каким образом с точки зрения последующего алгоритма выбирать изменившиеся данные.?

Что имеется ввиду под «+ дамп id изменённых строк+имён таблиц+ревизия куда-нибудь» не понял

Вешаешь на каждую таблицу триггеры, которые вставляют в какую-нибудь другую таблицу id,имя таблицы,timestamp,какой-нибудь счётчик.

в той же самой БД (можно в другой если будет мешать)для каждой «tablename» будет создана «tablename_log»

И зачём тебе 2х таблиц, когда можно все изменения тянуть с одной.

При Вашем подходе каким образом с точки зрения последующего алгоритма выбирать изменившиеся данные

Как-то так:

select table1.* from table1,log 
       where log.table = "table1" 
             and (log.timestamp > somedate 
             or log.recordId > someRecord)
             and log.id = table1.id

под ревизией что Вы понимаете?

Если есть id тракзакции, то не плохо бы прокинуть его, если нет, то хотя бы обычный автоинкремент.

Но логи это такое себе, я понимаю, тебе нужны данные тогда, когда они появятся в бд. А для этого тебе нужен или rabbitmq, или какой-нибудь другой брокер сообщений, или тупо слать http запросы куда-нибудь, когда в базу что-то запишут.

в случае если таких полей в строках с данными нет, какие вообще подходы могут быть

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

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

Хотя с триггерами и таблицей с логами тоже могет быть кирдык, но кирдык кмк менее болезненный

разработчики биллинга отказались от реализации задачи.

Какие у них аргументы были? Биллинг без истории это хрень какая-то, как вы такое купили-то? Сэкономили ?

Какие ваши рассуждения и доводы могут быть?

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

нужно будет писать инфу опять же триггером

Мускул сам обновляет поле если задано https://dev.mysql.com/doc/refman/8.0/en/timestamp-initialization.html

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

разработчики биллинга отказались от реализации задачи

Так тебя и просят вмешаться. А разработчики пусть определяться, они разрабатывают систему и тогда выдвигают условия невмешательства, или нет и тогда помалкивают в тряпочку.

я понял в принципе удобно и возможно уже есть такое поле в БД - и тогда вариантов может быть еще,

Биллинг без истории это хрень какая-то, как вы такое купили-то?

Если это действительно биллинг там логами и так должно всё быть обмазано вдоль и поперёк. Это же деньги. Какие-то просиры платежей вообще не допустимы. В связи с этим вдвойне не понятно зачем что-то городить на уровне бд.

Вмешиваться в бд триггерами - это плохая идея.

Почему ты не рассматриваешь general log под свою задачу?

и что мне с ним делать? есть парсеры sql запросов во что то табличное?

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

Читай и парси биолог

что такое биолог?

дело в том что в этот general log попадают данные со статистикой по реалтайм трафику, которые нафиг не уперлись для сохранения в этом логе. И чем больше нагрузка по трафику - тем больше нагрузка бд через general log.
в БД есть два дохлых триггера.

Бинлог - https://habr.com/ru/company/rambler-co/blog/424025/