Репликация Binlog MySQL - это «мешок боли». Есть ли хорошие альтернативы?
Честно говоря, я пыталсяэтолевыйиПравильно и все еще обнаружил, что мой зеркальный сервер, настроенный как подчиненный сервер репликации, все еще отстает. База пользователей моего приложения продолжает расти, и теперь я достиг точки, когда я не могу продолжать «отключаться» для «повторной синхронизации» баз данных (даже по выходным).
В любом случае, мой вопрос: есть ли какие-либо правдоподобные, доступный, альтернативы репликации binlog? У меня два сервера, поэтому я пока не стал бы рассматривать покупку третьего для балансировки нагрузки, если только это не единственный вариант.
Ваше здоровье,
/ мп
Ответы 3
Ваш ведущий выполняется параллельно, а ваш ведомый - последовательно. Если ваш мастер может обработать 1,5 часа вставок / обновлений / выполнений за 1 реальный час, ваш подчиненный будет отставать.
Если вы не можете найти способы улучшить производительность записи на ведомом устройстве (больше памяти, более быстрые диски, удалить ненужные индексы), вы столкнулись с ограничением в архитектуре своих приложений. В конце концов вы достигнете точки, когда вы не сможете выполнять изменения в реальном времени так быстро, как ваш мастер может выполнять их параллельно.
Многие крупные сайты разделяют свои базы данных: подумайте о разделении основного + ведомого на несколько кластеров ведущий + ведомый. Затем разделите свою клиентскую базу на эти кластеры. Когда подчиненное устройство начинает отставать, самое время добавить еще один кластер.
Это недешево, но если вы не найдете способ заставить репликацию binlog выполнять операторы параллельно, вы, вероятно, не найдете лучшего способа сделать это.
Обновление (2017 г.): MySQL теперь поддерживает параллельные подчиненные рабочие потоки. Есть еще много переменных, из-за которых ведомое устройство будет отставать, но ведомым устройствам больше не нужно писать в последовательном порядке. Выбор сохранения порядка фиксации параллельных подчиненных потоков - важный вариант, чтобы посмотреть, является ли точное состояние подчиненного устройства критическим в любой момент времени.
иногда нужно просто услышать суровую правду
Все приложения сталкиваются с каким-то ограничением масштабирования. Большинство баз данных попадают в дисковый ввод-вывод. Похоже, у вас репликация. С другой стороны, вы не можете купить более крупные серверы баз данных, чтобы выполнить свою работу. С другой стороны, вы можете покупать серверы баз данных меньшего размера :)
Возможно, поможет добавление памяти в подчиненное устройство. Мы перешли с 32 на 128 мегабайт, и отставание более-менее исчезло. Но это не дешево и не хватит во всех ситуациях.
Покупка третьего сервера, вероятно, не так сильно поможет, скорее всего, вы просто получите еще одного отстающего ведомого.
Ты пробовала : 1) УСТАНОВИТЕ innodb_flush_log_at_trx_commit = 0 2) УСТАНОВИТЕ sync_binlog = 0
Оба помогут ускорить работу вашего ведомого устройства с небольшим уровнем дополнительного риска в случае сбоя сервера.
Эти две команды будут творить чудеса с точки зрения производительности. Просто имейте в виду, что если ваш главный сервер выйдет из строя, вы можете потерять транзакции, которые еще не попали в двоичные журналы на диске из ОЗУ. Если это нормально, вы должны быть счастливы.
Репликация mysql - это стабильное, быстрое и тонкое решение по сравнению с альтернативами. Booking.com использует невероятно много экземпляров mysql и настроек каскадной репликации из того, что я слышал. Если ваш веб-сайт действительно слишком велик, вам может потребоваться профессионал, который поможет вам с устранением неполадок, если ваше ведомое устройство не просто слишком маленькое с точки зрения оборудования. У меня лично есть настройки с 10k + запросами в секунду, у которых нет проблем с задержкой ведомого. Возможно, ваши настройки репликации тоже не идеальны.