Комментарии 4
Спасибо, интересно.

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

Однозначно могу сказать, что libslave подойдет в большинстве случаев, когда требуется получать обновления из базы MySQL, т.е. и в случае быстрого получения небольших обновлений. Единственное, что приходит в голову, когда получать все обновления не хочется — это в случае, когда данные меняются существенно быстрее, чем допустимый лаг для их потребителя, и объем изменений сравним с объемом самих данных. Например, если бесконечным потоком в таблицу льются поправки к каким-то коэффициентам, которые при этом медленно меняют сами коэффициенты, то выгоднее переселектить всю таблицу, чем получать все эти незначительные изменения.

Однако в случае, если таблица небольшого размера, и ее селект существенно быстрее того временного лага, который допустим для ее обновления в читателе, мы используем регулярный переселект всей таблицы, поскольку это проще в реализации — не надо продумывать логику, как обновить данные (т.е. поддержать операции insert/update/delete), надо просто скачать новые и выкинуть старые. Переселекчивать при этом можно раз в минуту, раз в секунду, чаще — сколько надо. Мы так поступаем с таблицами, которые содержат какие-то настройки. Этот случай частично подпадает под «быстрое получение небольших обновлений», хотя и в случае сильных изменений небольших таблиц работает не хуже.

Другой случай «быстрого получения небольших обновлений» — небольшие изменения больших таблиц. Понятно, что регулярный переселект тут не особо поможет, а libslave поможет, но вы спрашиваете, вероятно, про альтернативное решение без libslave, поскольку я упоминал, что сделать это «относительно легко». Поскольку решение, на мой взгляд, во многом зависит от конкретной задачи, попробую пофантазировать: пусть у нас есть один писатель, который пишет данные в таблицу, таблица большая, целиком находится в памяти большого количества демонов (т.е. БД используется ими как минимум для холодного старта), но обновляется по чуть-чуть, и нам хочется простого решения, как обновлять. Думаю, что самое простое по объему реализации, что я бы сделал, это вместе с записью данных в БД рассылал бы с писателя UDP пакеты с обновлениями всем зарегистрированным читателям. Поскольку обновлений немного, применять их должно быть просто, нагрузка будет небольшая во всех отношениях, пакеты не будут теряться, а обновления будут происходить синхронно на всех читателях. Это довольно упрощенное описание, но, по-моему, сделать такую рабочую модель можно.

С ростом количества изменений могут начаться проблемы несинхронности применения обновлений демонами — где-то какая-то задержка, кто-то лагнул, и мы уже не можем рассчитывать, что большой поток обновлений можно рассылать всем демонам одинаково. Приходится принимать во внимание состояние каждого из них, трекать, что кому посылать. И тут уже (хотя на самом деле даже раньше) удобно использовать libslave, поскольку там все эти проблемы решены, и каждый читатель получит свой поток изменений независимо от состояния других читателей и скорости, с которой он способен их применять.

Надеюсь, что мне удалось ответить на ваш вопрос.
Спасибо.

Прошу прощения за «каверзную» формулировку :) Я подразумеваю случай, когда таблицы большие, общий объем изменений в них тоже немаленький, а потребителю требуется лишь небольшая часть из них. То есть случай, когда гонять ради этого по сети весь бинлог — однозначно overkill и чревато проблемами. Тут нужна модель publish-subscribe, как вы и заметили. Примеры — таблица с балансами, таблица с личными сообщениями пользователей и т.д. В «большой тройке» есть средства для этого на уровне СУБД; и я хотел узнать, что есть в MySQL. А если нет, то как это все-таки реализуют, если нужно.
Для фильтрации на стороне мастера одной базы вам поможет:
--binlog-ignore-db

Для фильтрации таблиц — сделайте промежуточный mysql-slave, в нём поставьте опции
--replicate-ignore-table

и уже со slave высасывайте libslave обновления
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.