Здоровья всем!

2 центральных сервера, "Требований назначения функциональности" нет

поиск в форме списка номенклатуры (Ctrl+F):
если оба сервера работают - 10 секунд
если один из них выключен - 1 секунда

смущает, что между серверами сильно разное содержимое в srvinfo\reg_1541\7399b475-a6e4-436e-940b-67fd7753a92a\1Cv8FTxt

пытался настроить "Требования назначения функциональности" - эффекта нет

кто-нибудь сталкивался ? есть решение ?

пятница

понедельник

1с бы спросила: вы последнюю платформу используете?

(3) я бы ответил: на двух предыдущих релизах наблюдается одинаковое поведение

среда

четверг

пятница

вот из-за подобного и нужно обеспечивать отказоустойчивость на более низком уровне, нежели на уровне сервера приложений.... (я об этом и писал в прошлой ветке)

(8) на уровне ОС не получится
на уровне виртуальных машин - то же не получится

так на каком уровне обеспечивать отказоустойчивость 1С ?

(9) я-бы делал обычный кластер 1с (где один основной сервер на виртуалке с возможностью быстрого рестарта из снапшота на соседнем сервере) и отказоустойчивый кластер MSQL.

Это конечно не отказоустойчивый, но в случае проблем на основном сервере время поднятия копии будет менее 5 минут

(0) >> пытался настроить "Требования назначения функциональности" - эффекта нет.

А как пытался?
В документации про сервис полнотекстового поиска сказано.
● Диск ‑ ресурсоемкий сервис, создает повышенную нагрузку на дисковую подсистему.
● Возможность переноса между рабочими серверами.
● Перенос– ‑ сервис может мигрировать между рабочими серверами с потерей данных.
Репликации нет.

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

Я бы попробовал назначить требования назначения функциональности для полнотекстового поиска на нужные базы на каком-то одном из серверов. На втором - соответственно зеркально - "не назначать".
Выполнить полное применение требований на каждом из серверов.
Рестартовать серверы (на всякий случай).
Очистить индекс ППД.
Обновить индекс ППД.
Проверить, что индекс создаётся только на одном сервере.

(11) а как же отказоустойчивость?

(11) (12) вот с этим то и не понятно. Если поставить на одном "не назначать", то, при пропадании другого, из базы выкинет с ошибкой типа "сервис полнотекстового поиска недоступен".
Не пойму, как назначить так, чтобы один из серверов всегда был в приоритете, а второй только подхватывал, если откажет первый.

(13) пробовал так:
на первом:
Объект требования - любой
Тип требования - Назначать

на втором:
Объект требования - любой
Тип требования - Авто

или

на первом:
Объект требования - любой
Тип требования - Назначать
Приоритет - 1

на втором:
Объект требования - любой
Тип требования - Назначать
Приоритет - 0

в обоих случаях размазывает нагрузку по обоим серверам

ЧЯДНТ ?

снова понедельник

В 1с уже писал?

(16) в спортлото

за деньги может кто проконсультирует ?

(18) за деньги в цктп можешь обратиться

В качестве бреда: на обоих сделать ТНФ под полнотекстовый и поставить приоритет 100 и 99 соответственно...

(19) было бы столько бабла, сколько они хотят, я бы тут не писал

(20) нормальный такой бред, мне в голову не приходил

буду попробовать

У сервиса полнотекстового поиска нет репликации.
Я вообще не очень понимаю как он может параллельно работать в отказоустойчивом кластере на нескольких центральных серверах.
Подозреваю, что корректно работать полнотекстовый поиск может только в случае, когда он настроен на каком-то одном рабочем сервере (не важно - центральном или нет).

>> при пропадании другого, из базы выкинет с ошибкой типа "сервис полнотекстового поиска недоступен".

Ты проверял это?...
По идее, когда, например, индекс полнотекстового поиска протухает (долго не обновляется по какой-либо причине) платформа сама принимает решение об использовании механизмов поиска по данным из базы вместо индекса ППД. Почему в случае недоступности индекса (выключении сервера, где сервис работает) выскакивает ошибка?
Если это так, то получается, что никакой отказоустойчивости нет. Раз существует нереплицируемый сервис, для которого невозможен перенос между серверами без потери данных. Аналогичные проблемы у сервиса Журнал регистрации. Но с журналом регистрации это не так критично. В конце концов можно собрать его из кусков на разных серверах.

Я бы всё таки обратился с соответствующим запросом в 1С.
За спрос денег не берут.

и вообще ППД вам зачем ? Для мелких баз ППД только а для больших это вещь которая положит вам сервер и оч глючная. Приучите пользователей пользоваться alt-f и уберите окно поиска в списках. Если пользователь там что-то наберет то поиск идет по всем колонкам а настроить их может чел 100500 ну и итог ...
+ (23) ну согласен ППД и ЖР только на одном сервере однозначно ибо задолбаетесь - вчера ЖР там а сегодня тут )

>>Я бы всё таки обратился с соответствующим запросом в 1С.
ну а если КОРП и РКЛ то пишет в 1с - ибо РКЛ для этого и нужен чтобы у вендора спрашивать и получать ответ быстро - проверено на себе

(24) >> Для мелких баз ППД только а для больших это вещь которая положит вам сервер и оч глючная.

Прям с огромными базами не работал.
Самые большие базы - допиленная БП редакции 3.0 размером около 170Гб с примерно тремя - четырьмя десятками пользователей.
Такого, чтобы полнотекстовый поиск клал сервер, не было. Помимо этой базы на сервере крутилось ещё с десяток типовых БП и ЗУПов меньших размеров.
Глюков или сильных тормозов за поиском особых не замечал. Хотя на больших таблицах действительно поиск по всем колонкам работает неторопливо. Но довольно удобно иногда бывает.

Так что думаю, что тут неоднозначное мнение по поводу отключения полнотекстового поиска. Надо смотреть конкретные обстоятельства.

(26) прикинь как хочет ТС: падает 1ый центральный сервер и поднимается на 2ом а там ППД отродясь никогда не видел - "камни" в сотку часов на N. Сам наблюдал такое )

+ (27) КА 2.4 500гиг 300пользователй