Репликация MySQL, подвешенная после ведомого устройства, идет офлайн и возвращается онлайн снова
Windows CAL, лицензирующий, сделан на доверии, поэтому при больше подключении устройств/пользователей, чем у Вас есть CAL для затем, ничего не произойдет с ними, но Вы нарушите свою лицензию.
Максимальное поле использования указывает на максимальное количество параллельных пользователей, которых Вы имели соединенный одновременно. Это является самым высоким, это имеет к в единственной точке, это не кумулятивно. В зависимости от того, лицензируете ли Вы свой CALs на на пользователя или использование для каждого устройства, он может указать на необходимость в большем количестве CALs.
Когда ведомое устройство MySQL подключается к ведущему устройству, оно запрашивает поток двоичного журнала, и ведущее устройство самостоятельно отправляет события двоичного журнала по мере их возникновения, без подтверждения от ведомого устройства, если вы не используют полусинхронную репликацию.
Подчиненное устройство не создает никакого трафика, кроме подтверждений низкого уровня, обрабатываемых стеком TCP. Нарушение связи (на различных уровнях стека, не ограничиваясь отключенным кабелем) может привести к разрыву соединения несколькими способами, включая разрыв соединения TCP-стеком главного устройства из-за тайм-аутов, сообщения о недоступности ICMP или брандмауэра с отслеживанием состояния. между машинами, которые «забывают» о сеансе TCP и молча отбрасывают последующие пакеты, когда ведомое устройство спокойно сидит и ждет следующего пакета от ведущего.
Решением здесь является глобальная переменная slave_net_timeout .
Время ожидания дополнительных данных от ведущего в секундах, прежде чем ведомое сочтет соединение разорванным, прервет чтение и попытается восстановить соединение.
Это настроено на ведомом устройстве. Когда ведомое устройство подключается к ведущему, перед запросом потока binlog, оно просит ведущее отправить события пульса, которые форматируются как события binlog и передаются в потоковом режиме, как если бы они были следующим событием в binlog ведущего, но фактически не увеличивают счетчики позиций binlog. По сути, они не требуют дополнительных затрат при нормальной работе, потому что они не отправляются, если мастер не сгенерировал новые события бинарного журнала для половины подчиненного устройства. s Настройка slave_net_timeout (по умолчанию; или другое значение, которое вы можете настроить во время ИЗМЕНИТЬ МАСТЕРА НА ), поэтому события пульса фактически генерируются только при очень слабом трафике ... так что нет какой-либо реальный вред, насколько я могу судить, установив это значение всего в несколько секунд.
Если ведомое устройство видит, что время ожидания истекло, оно закрывает свое соединение и повторно подключается к ведущему.
В случае удаленной возможности, что ведущее устройство не осознает, что ведомое устройство ушло, при повторном подключении ведомого устройство master закроет исходное соединение, потому что ведущее устройство MySQL, принимая новое ведомое соединение, проверяет, подключено ли уже другое ведомое устройство с тем же server_id , и если да, то разрывает исходное соединение. Это, кстати, причина, по которой два ведомых устройства, настроенные с одним и тем же server_id (неподдерживаемая конфигурация), не могут успешно оставаться подключенными к одному и тому же мастеру - как только один из них подключается, это приводит к тому, что другой блокируется, и следует цикл, в котором каждый раб принудительно разрывает соединение другого.
Установка для этой переменной достаточно низкого значения в my.cnf и перезапуск ведомого устройства должны решить эту проблему.