Установка главного узла риб 8.3. Делать указанные шаги желательно тогда, когда в базе не будет работающих пользователей
Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай - для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
ВАЖНО!!! Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
Убедиться, что в главном узле обмена (из которого создаем) нет зарегистрированных изменений для подчиненного узла (который создаем/восстанавливаем), в подчиненном, соответственно, не должно быть
зарегистрированных изменений для главного узла.
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).
В качестве "исходного узла" выберем "Корневой узел" (см. схему РИБ). В нем аккумулируются данные всех узлов.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.
0. В режиме предприятия создаем новый узел РИБ в "исходном узле".
Данное действие необходимо, если создается новый
узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из "исходного узла" в файл (*.dt).
Для "пухлых" БД можно просто скопировать 1Cv8.1CD, для клиент-серверных БД - например, скопировать средствами СУБД.
2. Загружаем полученную в п. 1 выгрузку в "чистую" БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных в подчиненной БД.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже "приезжают" с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /S"SRVname:port\BDname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /S"SRVname:port\DBname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
Соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
PathToLocalDB - путь к файловой БД
AdminUser - администратор БД
AdminUserPass - пароль Администратора БД
SRVname - имя сервера БД (либо IP адрес)
port - порт агента сервера (по-умолчанию 1540)
BDname - имя БД в кластере серверов
5. Отключаем главный узел обмена.
Как и в предыдущем пункте, для этого необходимо запустить конфигуратор из командной строки с параметрами и дождаться его выполнения:
Для Linux-клиента "файловый" вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
Для Linux-клиента "клиент-серверный" вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /S"SRVname:port\BDname" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
Для Windows-клиента "файловый" вариант БД:
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
Для Windows-клиента "клиент-серверный" вариант БД:
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /S"SRVname:port\DBname" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
6. Запускаем 1С в режиме предприятия и, в появившемся предложении о восстановлении связи с "главным узлом обмена", подтверждаем ОТКЛЮЧЕНИЕ.
7. Настраиваем узлы.
Если нам необходима БД для разработки - удаляем лишние узлы обмена и сценарии синхронизации. Все БД готова. Можно переходить к п. 8
Если создаем новый узел РИБ:
- Удаляем лишние узлы обмена и сценарии синхронизации так, чтобы осталось 2 узла: узел, полученный в п. 0 (У0) и главный узел для полученного узла (ГУ). ГУ - будет "текущим" узлом, т.е. в форме списка возле него будет зеленая точка/кружок.
- В настройках синхронизации данных изменяем свойство "Префикс этой информационной базы" на префикс У0.
- Меняем местами (переименовываем) кода и наименования У0 и ГУ так, чтобы У0 стал "текущим" узлом.
- Восстанавливаем связь с главным узлом (для этого есть масса обработок на просторах инфостарта, интернета или можно нарисовать свою)
- Перезапускаем 1С в У0 в режиме предприятия и отказываемся от помощи мастера настройки синхронизации.
- Настраиваем сценарии синхронизации.
- Сбрасываем регистрацию изменений в У0 и ГУ.
- Устанавливаем номера сообщений отправки/получения в 0.
- Восстанавливаем настройки и возможность входа пользователей.
Проверяем синхронизацию данных У0 с ГУ.
Если восстанавливаем узел РИБ - действия такие же как и для создания нового узла, только в качестве У0 необходимо использовать восстанавливаемый узел.
8. Восстанавливаем автоматическое обновление предопределенных данных в подчиненном узле.
Как и в п. 4, для этого необходимо запустить конфигуратор из командной строки с параметрами и дождаться его выполнения:
Для Linux-клиента "файловый" вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
Для Linux-клиента "клиент-серверный" вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /S"SRVname:port\BDname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
Для Windows-клиента "файловый" вариант БД:
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
Для Windows-клиента "клиент-серверный" вариант БД:
"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /S"SRVname:port\DBname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!! !)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
В остальном могу только пожелать удачи!
Ошибки динамического обновления (или другие глюки платформы) могут быть причинами ошибок обмена распределенных информационных баз:
"Данные принимаются от узла, для которого зарегистрированы изменения конфигурации"
"Конфигурация узла распределенной ИБ не соответствует ожидаемой"
Как восстановить обмен?
Но начнем не с воостановления, а с возможности провести о
бмен "вручную", что бывает важно в течении дня, потому что, как всегда, всё должно работать "еще вчера":) Сделать это можно с помощью замечательных обработок, которые я не пом
ню где скачал(авторы, откликнитесь — оставлю ссылки на ваш ресурс, а с моего, если нужно — удалю
). Обработки дают возможность выгрузить только зарегистрированные изменения данных в базе(по указанному плану обмена для определенного узла!) в XML без выгрузки изменений конфигурации и, если объекты конфигурации не сильно видоизменились, то есть очень большие шансы на загрузку этих данных. Обрабокти эти можно скачть по ссылке в конце статьи.