Имя: Пароль:
1C
1С v8
Пропала часть записей журнала регистраций пользователей на кластере серверов 1С.
0 pvase
 
23.12.21
15:33
Здравствуйте. Есть 2 сервера 1С, оба настроеные как главные, подключены как рабочие сервера. Заметил интересный момент. Журнал регистрации пишется как на один так и на другой сервер. Файлы разные на каждом сервере. В какой-то момент случился сбой (пользователи не могут сказать какой) и пропали записи в журнале регистрации за один месяц. ЖУрнал регистрации в формате SQLLite. Файлы по содержанию на обеих серверах разные, на одном сервере есть данные за определенный день, а на втором нет. В Режиме 1С при просмотре журнала регистрации нет записей, и вот при просмотре напрямую в SQLLite на одном из серверов - записи есть. Подскажите может кто сталкивался, как 1С-ка обрабатывает такие служачи, как она объединяет журналы с разных серверов, в чем может быть проблема?
1 pvase
 
23.12.21
15:40
Может есть где описание, как 1С работает в таком случае, как она объединяет эти журналы, как она вообще работает с журналами в таком случае, может есть где описание тонкостей работы 1С в таком режиме?
2 fisher
 
23.12.21
16:04
Ничего не понял. Речь про одну конкретную базу? В одном кластере два центральных рабочих сервера? Как такое может быть? Мне казалось, в кластере только один центральный рабочий сервер может быть. На то он и центральный.
3 fisher
 
23.12.21
16:05
А если кластера два, так они что, на одну базу натравлены? Тогда я вообще ничего не понимаю.
4 kortun
 
23.12.21
16:12
(3) бывает такое, делают 2 кластера, 1 для пользователей, 2 для веб-сервисов и РЗ и оба смотрят на одну скульную базу, разносят нагрузку таким способом. Не говорю что так правильно, но в целом рабочий вариант
5 fisher
 
23.12.21
16:20
Почитал. Так отказоустойчивый кластер настраивают. ТНФ для ЖР при этом рекомендуют создавать с разными приоритетами. Тогда второй сервак будет писать ЖР только когда первый упадет. Само ничего нигде не склеивается. Руцями, если возникает такая потребность.
6 kortun
 
23.12.21
17:03
Ну и вообще от SQLLite лучше отказаться, от него тормозов больше, чем пользы, вернитесь на старый формат.
7 fisher
 
23.12.21
17:11
Склеить можно попробовать через СкопироватьЖурналРегистрации()
Настроить пользовательское подключение к тому серверу где нужный участок ЖР есть, подключиться, выгрузить его в файл.
Потом подключиться к тому серверу где нужного участка ЖР нет, загрузить из файла.
Вообще странно, что у вас только сейчас проблема возникла. Без явных приоритетов вообще не гарантируется чего когда в какой ЖР писаться будет.
Ну и как советовали выше - старый формат лучше. Вернее, теперь он опять новый :) Потому что его вернули на дефолт и проапгрейдили (индексы добавили). А скулайт теперь нерекомендуемый вроде.
Настраиваешь там сегментацию по дням (или чаще, если нужно) и обслуживать его становится одно удовольствие.
8 pvase
 
23.12.21
19:32
(5) А где можно почитать про данную настройку?
9 pvase
 
23.12.21
21:03
Сервера в строке настройки указаны через запятую, на самом кластере серверов оба сервера прописаны как центральные. Файл журнала пользователей пишется на оба сервера, но они разные. Зачем так сделано - непонятно, наверное какое-то отказоустойчивое решение. Пробовал прописать второй сервер вручную в  строке подключения - результата не дало, видимо срабатывает балансировщик на самом сервере 1С.
10 fisher
 
24.12.21
11:30
(8)(9) https://infostart.ru/1c/articles/307973/
Много полезного в комментариях.
> Пробовал прописать второй сервер вручную в  строке подключения - результата не дало, видимо срабатывает балансировщик на самом сервере 1С.
Хм... Может, действительно балансировщик. А второй в строке подключения прописывается, чтобы клиент знал куда еще ломиться, когда первый ляжет...
Ну, тогда можно подключить копию к тестовому кластеру (можно поднять его на любом из рабочих серверов рядом с рабочим) и подсунуть ему нужный журнал для выгрузки.
11 Dmitrii
 
гуру
24.12.21
13:01
(8) >> где можно почитать про данную настройку?

На ИТС в документации всё ж расписано с примерами и картинками.
https://its.1c.ru/db/v8320doc#bookmark:cs:TI000000024
Сервисы кластера.
Журналов регистрации. Поддерживает доступ к журналам регистрации. Диск, Перенос-, Деление по ИБ.
Диск ‑ ресурсоемкий сервис, создает повышенную нагрузку на дисковую подсистему.
Деление по ИБ ‑ для каждой информационной базы существует свой экземпляр сервиса.
Возможность переноса между рабочими серверами.
Перенос– ‑ сервис может мигрировать между рабочими серверами с потерей данных.

Про отказоустойчивый кластер с несколькими центральными серверами.
https://its.1c.ru/db/v8320doc#bookmark:cs:TI000000035

В любом случае натравливать несколько различных кластеров на одну базу данных нельзя. Так как у каждого кластера свои отдельные сервисы (управления сеансами, блокировками, нумерации объектов, журналов регистрации и пр. и пр.). Они никак между собой не синхронизированы. В результате равно или поздно получим конфликт. Даже если один из кластеров работает с базой только на чтение. Исключения, наверное, возможны, но мне лично очень трудно что-то такое представить. Инструментов для балансировки нагрузки межу серверами в рамках одного кластера (отказоустойчивого или нет - неважно) в большинстве случаев более чем достаточно.
12 fisher
 
24.12.21
13:13
(11) На ИТС фактически ничего нет про настройку нескольких центральных серверов в кластере. Просто вскользь в паре предложений упоминается, что так можно.
13 Dmitrii
 
гуру
24.12.21
13:20
(12) Согласен. На ИТС весьма бестолковое описание. Но вся информация там есть. Просто получается что её надо вычитывать из множества разных мест. Про сервисы кластера - в одном разделе, про ТНФ - в другом, про настройку рабочих серверов - в третьем, и т.д.
В любом случае по проблеме автора из ИТС можно понять, что проблема ЖР вполне ожидаема.
Кстати настройка ЖР через ТНФ - такое себе решение. На синхронизацию будут тратиться лишние ресурсы. Впрочем это надо проверять.
14 fisher
 
24.12.21
13:32
(13) > Кстати настройка ЖР через ТНФ - такое себе решение.
По сравнению с чем? :)
15 fisher
 
24.12.21
13:37
Да и вообще, любая кластеризация - это компромисс между производительностью, надежностью и масштабируемостью.
Компьютеры — это как велосипед. Только для нашего сознания. Стив Джобс