1. Да собственно любой мануал и любая статья по настройке xSTP/ERPS непременно нарисует схему с кольцами.
По сути - один коммутатор в центре, от него кольцо, которое идёт через все здания, и в каждом здании в кольце включен коммутатор, и возвращается обратно на другой порт. Соответственно если где-то сломается оптика, кольцо, конечно, развалится и превратится в линию, но все коммутаторы тем не менее будут достижимы. Если сдохнет коммутатор - отвалится соотв. здание, но остальные останутся достижимы.
Для надёжности используется два центральных коммутатора и делается два кольца. Соответственно в каждом здании два коммутатора, по одному на каждое кольцо, и они ещё соединены меж собой. то же касается и двух коммутаторов в центре. В такой схеме любая одиночная (и большинство двойных) авария (что коммутатора, что оптики), не приводит к разрыву связи.
5. Разные подсети (L3) и VLANs (L2) никак не коррелируют. То есть VLAN нужно делать, причём вне зависимости от IP-адресации.
5а. Классы, конечно, уже много лет побоку, но как-то осталась привычка не превышать. Так-то разницы вообще никакой. Если не считать того, что некоторое активное оборудование фабрично имеет некий адрес, который либо в 192.168.0.0/16, либо в 10.0.0.0/8. А вот дефолтных адресов из 172.16.0.0/12 я что-то не припоминаю.
Запрос будет медленным - он неспособен использовать индексы. Оторвите руки "дизайнеру" такой схемы, и задумайтесь о нормализации. Или, если версия MySQL позволяет, конвертируйте в JSON и используйте multivalued index.
PS. Запрос всё же не в mysqli и не в PHP. Запрос в MySQL.
Обычно единственное, что необходимо - это чтобы SFP правильно работал в оборудовании конкретного вендора.
Если в Арубу вставлять модуль HP (либо заведомо совместимый), а в Микротик - модуль Микротика (либо опять же заведомо совместимый), то они практически обречены на установление физического линка. Нет, мелочи типа совпадения скорости и длин волн, а также непревышение дистанции - тоже нужны, но это как бы очевидно.
character_set_system и character_set_filesystem определяются операционной системой хоста и не влияют, да их и откорректировать-то не получится.
Однако при указанных настройках соединения показанной ошибки возникнуть не может, для неё нет предпосылок. Предполагаю, что состояние переменных Вы получали вовсе не через проблемное программное обеспечение глючащего сайта - и вот там-то настройки и отличаются от phpmyadmin-овских. И именно там настройки соединения и надо фиксить. Чтобы соединение было именно таким же по свойствам, что и соединение, устанавливаемое phpmyadmin-ом.
ноутбук получает ip далекий от правды, какой-то внешний 167.ХХ.ХХ.X
Может, 169.254.XXX.YYY? Если так - то это APIPA, самоприсвоение адреса при отсутствии доступного DHCP.
Далее от Mikrotika идет кабель к умному коммутатору D-Link DGS-1210-52/ME, в котором я физическому порту присвоил ID 1005. От этого порта кабель подключается к ноутбуку
По моему разумению, портов должно быть два - к одному Микротик, к другому ноут. Оба эти порта - в одном VLANID=1005? порт, который к ноуту - untagged?
Выполните SHOW VARIABLES LIKE 'coll%'; и проверьте значения переменных character_set_client, character_set_connection, character_set_results. Все должны быть utf8mb4. Если нет - настраивайте свойства соединения.
Какой великий смысл в такой нумерации? Тем более если вообще нет сортировки. Номера нужны при отображении же - вот средства отображения пусть и нумеруют. Всё равно этот номер ни к какой заднице не прислонить.
Посчитай количество записей на блок до и после. Думаю, в первом случае оно уменьшилось, а во втором не изменилось.
Также надо учесть, что байт-маркер NULL хранится всегда в теле, тогда как значение длинного варчара - нет.
CityCat4, ну я что вижу, о том пою... товарищ просит блокировку определённых адресов - а уж чёрный-то список адресов файрвол Микротика обеспечивает не напрягаясь. Нюхать шифрованные соединения - это немного другая задача, на которую Микротик, конечно, не рассчитан.
1. Да собственно любой мануал и любая статья по настройке xSTP/ERPS непременно нарисует схему с кольцами.
По сути - один коммутатор в центре, от него кольцо, которое идёт через все здания, и в каждом здании в кольце включен коммутатор, и возвращается обратно на другой порт. Соответственно если где-то сломается оптика, кольцо, конечно, развалится и превратится в линию, но все коммутаторы тем не менее будут достижимы. Если сдохнет коммутатор - отвалится соотв. здание, но остальные останутся достижимы.
Для надёжности используется два центральных коммутатора и делается два кольца. Соответственно в каждом здании два коммутатора, по одному на каждое кольцо, и они ещё соединены меж собой. то же касается и двух коммутаторов в центре. В такой схеме любая одиночная (и большинство двойных) авария (что коммутатора, что оптики), не приводит к разрыву связи.
5. Разные подсети (L3) и VLANs (L2) никак не коррелируют. То есть VLAN нужно делать, причём вне зависимости от IP-адресации.
5а. Классы, конечно, уже много лет побоку, но как-то осталась привычка не превышать. Так-то разницы вообще никакой. Если не считать того, что некоторое активное оборудование фабрично имеет некий адрес, который либо в 192.168.0.0/16, либо в 10.0.0.0/8. А вот дефолтных адресов из 172.16.0.0/12 я что-то не припоминаю.