Ошибка чтения файла сообщения обмена конфигурация узла распределенной иб не соответствует ожидаемой
Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой!
Конфигурацию выгружал, в удаленный узел загрузил. Такая же фигня. Что можно еще сделать?
Релиз платформы 8.3.12.1790, есличо
Методика 2 вот отсюда звучит страшновато, да и собсно я так понимаю, она именно для другого случая, когда изменения не идут в удаленный узел
(4) Тем, что не работает. Я сделал несколько раз уже. В удаленный узел идут изменения, обратно главный не принимает.
(5) в ЦБ какие-то изменения конфигурации делаются?
Если да, то пересохрани всю конфигурацию в ЦБ - заставь ее заново примениться к базе с реструктуризацией и регистрацией всех своих объектов. Только после этого проведи по шагам методики 1-го пункта.
(6) Делаются. ОНи всасываются успешно в удаленный узел
А обратно шиш.
(7) Что-то я не понял. "Удаленный" - это в смысле "подчиненный"? Тогда не понял. Такая ошибка может возникнуть в подчиненных узлах, но не в центральном. Как узел может "всосать успешно", если проверка соответствия - перед началом обмена?
(11) может, я такое тоже видел, на куче точек норм получает. а в центр хрен. Делал выгрузку CF из узла в Центр. норм заработало. По поводу сабжа в (0). Платформы одинаковые? Тоже недавно на 13-й парился с этим, пока одинаковые платформы не поставил, не проходил обмен.
источник ошибки - в файле от ПБ содержится значение хэш-функции, которое попадает в файл от сохраненной конфигурации в ПБ.
Если это файл для загрузки в ЦБ то ЦБ тоже указывает, что конфигурация не соответствует ожидаемой.
По поводу не совпадения платформ - тоже допускаю, что и в этом может быть причина, т.к. формула для получения хэшфункции в разных платформах может (в теории) давать разные значения. Но часто видел такое, что платформы разные и режим работы с базами разные, а ошибок нет.
Как только конфигурации в ЦБ и в ПБ полностью, абсолютно идентичны - ошибка исчезает.
(10) а как же.
(11) А вот так. Подчиненный узел считает что все ок. Все изменения, что в конфигурации тут навертел - там есть и работают. А главный изменения не принимает.
(13) Одинаковые. Насчет из ПУ в ГУ выгрузки цф это мысль, я попробую потом, как если ща с обновлением версии УТ не взлетит.
(15) замена Digest2 на значение из выгрузки главного узла кстати не помогла, главный узел сказал не приму эту выгрузку.
(17) Имхо, если демоны в базе шалят, то выгрузка/загрузка конфигурации через пустую базу может поможет (из ПБ в ЦБ).
Версии платформы в ЦБ и ПБ одинаковые?
5. Установить другой допустимый релиз платформы (предыдущий или следующий). Повторить шаги 1-4.
Есть мнение, что количество пользователей использующих РИБ, ничтожно мало и релизы в которых есть баги связанные с РИБ 1С не отзывает.
(24) "ну только релизы не менялись" - это тоже важно. Есть релизы - в которых тупо РИБ не работает из-за багов.
(14) за последние 5 лет минимум дважды сталкивался с релизом на котором РИБ не работает именно из-за багов платформы.
После обмена данными из 12 баз была получена информация только от 10.
1 периферийная база не обновилась и от одной уже центральный узел не мог получить данные, хотя сама база обновилась.
А что было? А было динамическое обновление.
Внести МОНОПОЛЬНО какое-то изменение в центральную базу (можно поставить пробел в любом месте) и сохранить базу. Выгрузить cf и загрузить во все периферийные базы, сделать монопольно обмен и монопольно обмен в центральной.
1. Выгрузить из главной базы конфигурацию: Зайти в конфигуратор, пункт "Конфигурация", "Выгрузить в файл" и переписать конфигурацию в филиал.
2. Закрыть в филиале все сессии 1С и открыть в режиме Предприятие под полными правами обработку "УстановитьГлавныйУзел", ничего не выбирая, нажать кнопку "Выполнить".
3. Запустить Конфигуратор, пункт "Конфигурация", "Загрузить конфигурацию из файла", после загрузки нажать сохранить (дискетка) и нажать F7 (Обновить)
4. Снова открыть в режиме Предприятие под полными правами обработку "УстановитьГлавныйУзел", выбрать центральный узел и нажать кнопку "Выполнить".
5. Сделать обмен в этой базе, после чего выполнить обмен в центральной. Все изменения должны загрузиться.
P.S. Через неделю еще у одного клиента возникла та же проблема. Решение помогло.
Специальные предложения
Но мы к сожалению не смогли определить причину возникновения этой ошибки. Она у нас появлялась и при отсутствии динамических обновлений.
Поэтому мы сделали следующее. Все изменения, которые хотим внести, собираются в отдельной копии сотрудниками отдела. А потом разом переносятся в главный узел через сравнение и объединение. Ну а потом уже обновление. Логика в том, что бы не нажимать на кнопку сохранить(дискета) в главной узле более одного раза. Такое чувство, что ошибка кроется там.
(1) Возможно. При описанных мною действиях кнопка сохранить нажимается 1 раз.
(1) ЭЭЭЭЭЭ.
Хранилищем не пробовали пользоваться. всеми сотрудниками отдела из 20 человек работаем уже 5 лет с одной базой ,
никаких проблем нет и не было ни когда ) Центральная база накатывается из хранилища, потом идут обмены со всеми.
Ну разве , что само хранилище падает раз в год!) Но это ни на, что не влияет ни на наши копии ни на рабочие базы.
Создаем новое и понеслась.
К сожалению, Ответа на вопрос: "Как делать так, что бы базы не "заболевали"?" -мы так и не нашли, И не даёт ответ на этот вопрос данная статья! Заметил такую особенность, что если платформа главного узла и подчиненного отличается, то данная ситуация происходит намного чаще.
Вместо обработки "УстановитьГлавныйУзел" можно использовать параметр запуска конфигуратора ResetMasterNode - помогает когда после неудачного обновления не получается войти в режиме предприятия.
Внимание! После платформы 8.3.4.1860 ResetMasterNode перестал работать, а разработчики никак не починят. Поэтому используйте старые версии платформы если в текущей не отстегнулось.
И еще из личного опыта:
Не всегда удается загрузить cf в подчиненный узел. Т.е. он загружается, но в файле обмена все равно присутсвует старый идентификатор версии конфигурации. Либо головная база "теряет" у себя этот идентификатор. И после того как вгрузили cf - ничего не работает.
В этом случае помогает чистка кеша.
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением. );
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда.
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000". )
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
Механизм распределенных информационных баз 1С в свое время был очень популярен в компаниях, где были филиалы, но не было связи через Интернет. Сейчас Интернет есть почти везде, и большинство удаленных отделов через него подключаются и работают с основной базой. Тем не менее, механизм РИБ до сих пор используется, пользователи работают, и иногда возникают ошибки. Одна из самых распространенных среди них – «Конфигурация не соответствует ожидаемой».
Причины возникновения ошибки
Чаще всего подобные ошибки возникают в процессе загрузки данных из основной в дочернюю базу. Как правило, это говорит о том, что существуют проблемы в настройке дочерней БД. С большой вероятностью, ошибки не избежать повторением операции, она никуда не денется и будет преследовать вас при каждом обмене. Поэтому многие специалисты рекомендуют после подобных ошибок заново создавать периферийную ИБ.
Кроме вышеперечисленных вариантов на практике также замечены проблемы после динамических обновлений баз. Однако прямых доказательств и объяснений этому явлению на сегодняшний момент нет. Ошибка «Конфигурация распределенного узла не соответствует ожидаемой» в подавляющем большинстве случаев исправляется достаточно легко. Вам не нужно иметь специальных знаний – достаточно базовых знаний администрирования систем 1С.
Если вы первый раз столкнулись с подобной ошибкой, последовательно выполните следующие шаги и, скорее всего, проблема уйдет:
- Почистите кэш и проверьте работоспособность обмена еще раз. Если ошибка не ушла – приступайте к следующим шагам;
- Завершите все сеансы работы с подчиненной базой и сделайте ее копию;
- Выгрузите конфигурацию в файл с расширением .cf с основной ИБ;
- Далее необходимо отключить основной узел – для этого воспользуйтесь многочисленными обработками из Интернета. Они распространяются под именем, подобном «ОтключитьУзелРИБ.epf»;
После вышеописанных действий попробуйте снова запустить обмен между двумя базами. Вероятность успеха очень высока, а проблема может возникать только в критичных ситуациях. Что же можно предпринять в случаях форс-мажора? Весьма действенным оказался вариант с подменой хэша файлов обмена. Для этого необходимо:
- Совершить вышеописанный алгоритм;
- Выгрузить файл обмена из основной базы и дочерней, но не загружать их;
После всех операций проделайте несколько обменов для тестирования. Если не возникнет проблем, значит, все сделано правильно, и ошибка несоответствия узлов РИБ исправлена.
Читайте также: