Репликация Binlog MySQL - это “Мешок с обидой”.Есть ли какие-нибудь хорошие альтернативы?

Question

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

В любом случае, мой вопрос:Есть ли какие-нибудь правдоподобные, доступный по цене, альтернативы репликации binlog?У меня есть два сервера, поэтому я бы пока не рассматривал возможность покупки третьего для балансировки нагрузки, если только это не единственный вариант.

Ваше здоровье,

/мп

Answer 1

Ваш ведущий выполняется параллельно, а ваш подчиненный - последовательно.Если ваш ведущий может обработать 1,5 часа вставок / обновлений / выполнения за 1 реальный час, ваш подчиненный отстанет.

Если вы не можете найти способы повысить производительность записи на вашем подчиненном устройстве (увеличить объем памяти, ускорить работу дисков, удалить ненужные индексы), вы столкнулись с ограничением в архитектуре ваших приложений.В конце концов вы дойдете до того, что не сможете выполнять изменения в режиме реального времени так быстро, как ваш мастер может выполнять их параллельно.

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

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

Обновление (2017):MySQL теперь поддерживает параллельные подчиненные рабочие потоки.По-прежнему существует множество переменных, которые приведут к отставанию ведомого устройства, но ведомому устройству больше не нужно записывать в последовательном порядке.Выбор сохранения порядка фиксации параллельных подчиненных потоков является важным вариантом для определения того, является ли критичным точное состояние подчиненного в любой момент времени.

Answer 2

Вы пробовали :1) УСТАНОВИТЕ innodb_flush_log_at_trx_commit=0 2) УСТАНОВИТЕ sync_binlog=0

И то, и другое поможет ускорить работу вашего подчиненного устройства с небольшим уровнем дополнительного риска в случае сбоя сервера.

Answer 3

Вероятно, помогло бы добавление памяти к ведомому устройству.Мы перешли с 32 до 128 мегабайт, и отставание более или менее исчезло.Но это недешево и будет недостаточно во всех ситуациях.

Покупка третьего сервера, вероятно, не так уж сильно поможет, хотя, скорее всего, вы просто получите еще одного отстающего ведомого устройства.