Здравствуйте. Есть 2 сервера 1С, оба настроеные как главные, подключены как рабочие сервера. Заметил интересный момент. Журнал регистрации пишется как на один так и на другой сервер. Файлы разные на каждом сервере. В какой-то момент случился сбой (пользователи не могут сказать какой) и пропали записи в журнале регистрации за один месяц. ЖУрнал регистрации в формате SQLLite. Файлы по содержанию на обеих серверах разные, на одном сервере есть данные за определенный день, а на втором нет. В Режиме 1С при просмотре журнала регистрации нет записей, и вот при просмотре напрямую в SQLLite на одном из серверов - записи есть. Подскажите может кто сталкивался, как 1С-ка обрабатывает такие служачи, как она объединяет журналы с разных серверов, в чем может быть проблема?

Может есть где описание, как 1С работает в таком случае, как она объединяет эти журналы, как она вообще работает с журналами в таком случае, может есть где описание тонкостей работы 1С в таком режиме?

Ничего не понял. Речь про одну конкретную базу? В одном кластере два центральных рабочих сервера? Как такое может быть? Мне казалось, в кластере только один центральный рабочий сервер может быть. На то он и центральный.

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

(3) бывает такое, делают 2 кластера, 1 для пользователей, 2 для веб-сервисов и РЗ и оба смотрят на одну скульную базу, разносят нагрузку таким способом. Не говорю что так правильно, но в целом рабочий вариант

Почитал. Так отказоустойчивый кластер настраивают. ТНФ для ЖР при этом рекомендуют создавать с разными приоритетами. Тогда второй сервак будет писать ЖР только когда первый упадет. Само ничего нигде не склеивается. Руцями, если возникает такая потребность.

Ну и вообще от SQLLite лучше отказаться, от него тормозов больше, чем пользы, вернитесь на старый формат.

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

(5) А где можно почитать про данную настройку?

Сервера в строке настройки указаны через запятую, на самом кластере серверов оба сервера прописаны как центральные. Файл журнала пользователей пишется на оба сервера, но они разные. Зачем так сделано - непонятно, наверное какое-то отказоустойчивое решение. Пробовал прописать второй сервер вручную в  строке подключения - результата не дало, видимо срабатывает балансировщик на самом сервере 1С.

(8)(9) https://infostart.ru/1c/articles/307973/
Много полезного в комментариях.
> Пробовал прописать второй сервер вручную в  строке подключения - результата не дало, видимо срабатывает балансировщик на самом сервере 1С.
Хм... Может, действительно балансировщик. А второй в строке подключения прописывается, чтобы клиент знал куда еще ломиться, когда первый ляжет...
Ну, тогда можно подключить копию к тестовому кластеру (можно поднять его на любом из рабочих серверов рядом с рабочим) и подсунуть ему нужный журнал для выгрузки.

(8) >> где можно почитать про данную настройку?

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

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

В любом случае натравливать несколько различных кластеров на одну базу данных нельзя. Так как у каждого кластера свои отдельные сервисы (управления сеансами, блокировками, нумерации объектов, журналов регистрации и пр. и пр.). Они никак между собой не синхронизированы. В результате равно или поздно получим конфликт. Даже если один из кластеров работает с базой только на чтение. Исключения, наверное, возможны, но мне лично очень трудно что-то такое представить. Инструментов для балансировки нагрузки межу серверами в рамках одного кластера (отказоустойчивого или нет - неважно) в большинстве случаев более чем достаточно.

(11) На ИТС фактически ничего нет про настройку нескольких центральных серверов в кластере. Просто вскользь в паре предложений упоминается, что так можно.

(12) Согласен. На ИТС весьма бестолковое описание. Но вся информация там есть. Просто получается что её надо вычитывать из множества разных мест. Про сервисы кластера - в одном разделе, про ТНФ - в другом, про настройку рабочих серверов - в третьем, и т.д.
В любом случае по проблеме автора из ИТС можно понять, что проблема ЖР вполне ожидаема.
Кстати настройка ЖР через ТНФ - такое себе решение. На синхронизацию будут тратиться лишние ресурсы. Впрочем это надо проверять.

(13) > Кстати настройка ЖР через ТНФ - такое себе решение.
По сравнению с чем? :)

Да и вообще, любая кластеризация - это компромисс между производительностью, надежностью и масштабируемостью.