сервер поднят с чистого образа с устаревшими обновлениями.
Чтобы историческая цепочка стала устойчивой, нужно вводить указатель на следующую или предыдущую запись.
В том числе про failover выборы мастера я также слышу впервые, хотя перечитывал мануал как в оригинале так и в переводе.
Обрыв поделит кольцо на 2 ветки, в каждом транзит обнаружит обрыв и отправит через оставшийся интерфейс линкдаун
2. То есть всё же есть разница в направлении первичного и вторичного портов для быстрого перестроения топологии? Вэтом и заключается мой вопрос
Но обычный UPDATE при обновлении нескольких строк не дает определенного порядка выполнения.
просто если это делает ЛЮБОЙ транзит, значит при обрыве будет сгенерировано 2 сообщения по разные от обрыва стороны.
claude мне озвучил принцип "транизт должен смотреть первичным портом в сторону мастера по кратчайшему пути", видимо, как раз в соответствии с доками Н3С. Таким образом, можно сделать вывод что в каждом полукольце первичные порты будут направлены в свою сторону, а соединение secondary-secondary будет на ровно противоположной мастеру стороне.
мне нужна высокая доступность, чтобы linkdown пришел корректно, а не ждать 30 сек fail timer
Не могли бы вы немного объяснить логику пересылки health транизтами - они видят, в какой порт он пришел и пересылают в противоположный?
Также, в доках h3c написано, что linkdown сообщение шлет только тот транзит, чей ВТОРИЧНЫЙ порт упал.
Transit nodes, edge nodes, or assistant edge nodes send LINK-DOWN packets to notify the master node that an interface is Down.
У меня 3 колонки, данные в ячейках неуникальны, и неуникальные данные подсвечиваются. Собственно, это единственная задача софтины.Извиняюсь, а нахрена она это делает?
Хабр: Отключение фикса Meltdown и Spectre в Windows