Репликация Binlog MySQL - это "мешок боли". Есть ли хорошие альтернативы?
Я честно пробовал этой левый и право и все еще обнаруживают, что мой зеркальный сервер, настроенный как подчиненный репликации, все еще отстает. База пользователей моего приложения продолжает расти, и теперь я достиг точки, когда я не могу продолжать "выключать" базы данных "resync" (даже в выходные дни).
в любом случае, мой вопрос: есть ли правдоподобно, недорогой, альтернативы репликации binlog? Я имейте два сервера, поэтому не рассматривайте покупку третьего для балансировки нагрузки, если только это не единственный вариант.
спасибо,
/ mp
3 ответов
ваш мастер выполняется параллельно, а ваш подчиненный выполняется последовательно. Если ваш хозяин может обрабатывать 1,5 часа вставок / обновлений / исполнений в 1 реальном часе, ваш раб будет отставать.
Если вы не можете найти способы улучшить производительность записи на ведомом устройстве (больше памяти, более быстрые диски, удаление ненужных индексов), вы столкнулись с ограничением в архитектуре приложений. В конце концов вы попадете в точку, что вы не можете выполнить изменения в режиме реального времени так быстро, как ваш мастер может выполняйте их параллельно.
многие большие сайты разбивают свои базы данных: рассмотрите возможность разделения master + slave на несколько кластеров master+slave. Затем разделите свою клиентскую базу по этим кластерам. Когда ведомый начинает отставать, пришло время добавить другой кластер.
Это не дешево, но если вы не можете найти способ заставить репликацию binlog выполнять операторы параллельно, вы, вероятно, не найдете лучшего способа сделать это.
обновление (2017): MySQL теперь поддерживает параллельные рабочие потоки. Есть еще много переменных, которые заставят раба отстать, но рабам больше не нужно писать в последовательном порядке. Выбор сохранения порядка фиксации параллельных ведомых потоков является важным вариантом, чтобы посмотреть, если точное состояние ведомого в любой момент времени является критическим.
вы пробовали : 1) установить innodb_flush_log_at_trx_commit=0 2) установить sync_binlog=0
оба помогут ускорить ваш ведомый с небольшим уровнем дополнительного риска, если у вас есть сбой сервера.
добавление памяти к ведомому устройству, вероятно, поможет. Мы перешли от 32 до 128 мегабайт, и отставание более или менее исчезло. Но его ни дешево, ни будет достаточно во всех ситуациях.
покупка третьего сервера, вероятно, не поможет, хотя, скорее всего, вы просто получите еще один отстающий раб.