Репликация Binlog MySQL - это серьезная проблема. Есть ли хорошие альтернативы?

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

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

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

/mp


mysql replication binlog
person mauriciopastrana    schedule 07.11.2008    source источник
comment
Репликация mysql - это стабильное, быстрое и тонкое решение по сравнению с альтернативами. Booking.com использует невероятно много экземпляров mysql и настроек каскадной репликации из того, что я слышал. Если ваш веб-сайт действительно слишком велик, вам может потребоваться профессионал, который поможет вам с устранением неполадок, если ваше ведомое устройство не просто слишком маленькое с точки зрения оборудования. У меня лично есть настройки с 10k + запросами в секунду, у которых нет проблем с задержкой ведомого. Возможно, ваши настройки репликации тоже не идеальны.   -  person sjas    schedule 17.07.2017

Ответы (3)


arrow_upward
10
arrow_downward

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

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

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

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

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

person Gary Richardson    schedule 07.11.2008
comment
иногда нужно просто услышать суровую правду - person mauriciopastrana; 12.11.2008
comment
Все приложения сталкиваются с каким-либо ограничением масштабирования. Большинство баз данных попадают в дисковый ввод-вывод. Похоже, у вас репликация. С другой стороны, вы не можете купить более крупные серверы баз данных, чтобы выполнить свою работу. С другой стороны, вы можете покупать серверы баз данных меньшего размера :) - person Gary Richardson; 12.11.2008

arrow_upward
1
arrow_downward

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

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

person Gary    schedule 07.06.2010
comment
Эти две команды будут творить чудеса с точки зрения производительности. Просто имейте в виду, что если ваш главный сервер выйдет из строя, вы можете потерять транзакции, которые еще не попали в двоичные журналы на диске из ОЗУ. Если это нормально, вы должны быть счастливы. - person sjas; 17.07.2017

arrow_upward
0
arrow_downward

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

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

person serbaut    schedule 20.02.2010