Производительность репликации MySql на Master после возобновления репликации - PullRequest
1 голос
/ 05 июня 2011

Текущая конфигурация - базовая репликация Master-> Slave.Каждую ночь на мастере запускаются различные задания по импорту данных.В течение этого времени подчиненная репликация отключается, и трафик направляется на ведомый (чтобы не вызывать узкое место в производительности / снижение производительности заданий загрузки данных).

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

В качестве альтернативного решения отключите «просто» поток SQL на ведомом устройстве (поддерживайте работу потока ввода-вывода все время), чтобы не бомбардировать мастер (позже ... все сразу)после возобновления репликации.Однако проблема этого подхода (очевидно) заключается в том, что теперь у ведомого устройства возникают постоянные проблемы с производительностью, в то время как мастер выполняет тяжелые задания по загрузке данных (поскольку поток ввода-вывода работает все время и перемещает данные).1006 * Таким образом, вопрос заключается в том, как я могу запустить / остановить репликацию на ведомом устройстве (в соответствии с моим графиком / требованиями загрузки данных) без снижения производительности на ведущем или ведомом устройстве?Похоже, вы сможете полностью отключить репликацию, а затем включить ее позже, не затрагивая мастер ??

Заранее спасибо!

1 Ответ

0 голосов
/ 15 июня 2011

Можете ли вы охарактеризовать проблему нагрузки?Вы зависли на iowait или сетевое соединение между ведущим и ведомым насыщено?Сколько памяти у вас на серверах?

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

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

В целом это звучит так, как будто у вас только что возникла проблема с емкостью, и вам нужно предоставить достаточно ресурсов для решения этой проблемы.нагрузка, на которую вы указываете - никакое жонглирование не позволит вам обойти это.Я не сталкивался с конфигурацией, где двоичное ведение журнала является ограничивающим фактором.Любая базовая конфигурация RAID должна обрабатывать не менее 300 МБ / с, и для того, чтобы это стало проблемой, вам нужно держать в руках больше, чем, скажем, 30 секунд за раз, подразумевая, что вам нужно перемещать более 9 ГБ бинлогов каждую ночь- вы действительно генерируете такое количество данных?

Другая альтернатива - использовать DRBD для репликации - таким образом, ведомому не нужно запускать реплицированные запросы или вообще иметь дело с binlogs,хотя есть и другие осложнения.

...