Ограничения бинлога MySQL

Question

У меня есть экземпляр MySQL, работающий на AWS, со скоростью около 5000 вставок в секунду.Есть идеи, как повлияет на производительность, если я буду использовать binlog (строку) и хвостовик binlog?

Проверьте эту ссылку

Насколько я понимаю, хранитель журнала bin периодически опрашивает binlog MySQL, чтобы сделать возможным соединение для передачи данных в реальном времени.Программа обработки binlog работает на NodeJS.

Дело в том, что мне нужно использовать MySQL, и я хочу использовать Meteor для передачи данных моим клиентам в реальном времени.Отсюда моя идея использовать этот хвостовик binlog.

Поскольку база данных MySQL будет заполняться довольно интенсивно (5000 вставок в секунду), я хочу знать, в какой момент у binlog/binlog Tailer возникают серьезные проблемы с производительностью.

Гртс, Том

Answer 1

Я разработал программное обеспечение с аналогичной функциональностью, позволяющее использовать поток репликации MySQL (двоичный журнал, binlog) для захвата событий практически в реальном времени в ответ на вставки/обновления/удаления в базе данных.

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

Я предполагаю, что, поскольку я был незнаком с пакетом Node, который вы процитировали, и только сейчас дал беглый обзор их кода, что они на самом деле не «отслеживают» binlog посредством опроса, а на самом деле эмулируют подчиненный сервер/сервер-реплику и подключаются мастеру и запросить поток репликации.

Первым потенциальным узким местом является способность ведущего устройства записывать необходимый объем данных Binlog (основным ограничением является пропускная способность ввода-вывода).Если ваш мастер уже вошел в систему ROW формате, то эта проблема уже решена.Если нет, то переключите формат Binlog и посмотрите.я предпочитать ROW в любом случае, потому что он очень полезен для восстановления данных, когда запросы выходят из строя или приложение делает что-то с данными, которых у него не должно быть.Можно (с помощью сторонних инструментов) зафиксировать то, что произошло, и обратить вспять — в конфигурации по умолчанию, когда происходит удаление (например), удаленные данные фактически записываются в двоичный журнал.

Следующая точка потребления ресурсов — подключение ведомого устройства к мастеру с помощью такого инструмента, куда мастер отправляет данные.Распространенным заблуждением является то, что раб «опрашивает» хозяина.Фактически, ведомое устройство инициирует соединение, но ведущее устройство отправляет данные.На самом деле это нагрузка на ведущее устройство, которая очень мало влияет на производительность, когда количество подключенных ведомых устройств невелико (скажем, 5 или меньше).Эту нагрузку можно полностью снять с ведущего устройства, подключив «хвост бинлога» не к ведущему, а к существующему ведомому устройству ведущего, при этом log_slave_updates настроен.

Транспортировка данных от главного устройства к псевдоподчиненному может потреблять значительную часть пропускной способности сети, поэтому ваша внешняя утилита должна поддерживать протокол сжатия клиент/сервер MySQL, чтобы уменьшить эту пропускную способность.Включение этой возможности позволяет добиться степени сжатия 10:1 в зависимости от полезной нагрузки.

Последняя болевая точка — это сама внешняя утилита.Формат MySQL Binlog — это очень плотно упакованный двоичный формат (отсюда и «двоичный журнал»), который необходимо анализировать и декодировать.Эффективность, с которой внешняя утилита может распаковывать и манипулировать этим потоком данных, будет определять, насколько близко к реальному времени могут быть выданы обнаруженные события, поскольку неэффективный код приведет к тому, что выбранный вами поток событий будет все больше и больше отставать от ведущего, хотя этот фактор не окажет никакого влияния на производительность самого главного сервера.

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