Я сейчас, может быть, глупую вещь скажу.

А что, если использовать 0MQ для отслеживания списка изменившихся таблиц?

pmus
А что, если использовать 0MQ для отслеживания списка изменившихся таблиц?

А не важно где хранить список, важно узнать о моменте изменения.
Вот с этим у MySQL трудности, т.к. встроенных средств нет.
Как любое третье решение, 0MQ ничего не знает чем закончилась и закончилась ли вообще транзакция в MySQL (это понятно).
0MQ можно использовать для организации промежуточного слоя между сервером БД и приложением, но все равно понадобится сервер приложений для обработки ответов MySQL и еще персистент-хранилище данных 0MQ.
Т.к. 0MQ - это транспорт, то она не решит проблемы рассогласованности данных при длительном офлайне одного из клиентов - как бы и не должна.

Lexander
важно узнать о моменте изменения.

вот и пусть сообщает. приложение получило результат транзакции, записало в очередь, отправило оповещение. Дата, время, таблица N.

нет?

По вашему алгоритму, чтобы обеспечить достоверность, нужно чтобы транзакция включала в себя запись в очередь 0MQ.
В принципе, это возможно, если транзакции управляются на клиенте, но выглядит достаточно коряво, т.к. вмешиваемся в бизнес-логику для решения чисто технической второстепенной задачи.
Ну и проблема постоянного хранения данных очереди после выключения компьютера осталась.

ну, дяденька, “я же не настоящий сварщик”. просто предположил.

Все ОК. На то и форум.