Конфігурація іб не відповідає очікуваній

Здрастуйте, шановні читачі нашого блогу сайт! Сьогодні поговоримо про
виправленні двох помилок, які можуть виникнути при обміні у розподіленій інформаційній базі (РІБ). Такі помилки можуть виникнути, якщо ви змінили конфігурацію вашої бази та намагаєтеся передати ці зміни з центральної бази до периферійної. Наприклад, способом, який був описаний . Давайте приступимо!

Ось такі повідомлення можуть з'явитися при спробі зробити обмін за допомогою РИБ:

«Дані приймаються від вузла, для якого
зареєстровано зміни конфігурації.
Необхідно зробити перенесення змін
Зміни у вузол.»

«Конфігурація вузла розподіленої ІБ
не відповідає очікуваній!»

Розгляньмо кроки, які допоможуть виправити ситуацію. Перед тим як почнемо, зробимо наші інформаційні бази!!!

Візьмемо конфігураційний файл з оновленням, відкриємо центральну базу в Конфігураторі і завантажимо його (Конфігурація-Завантажити конфігурацію з файлу…). Збережемо ІБ (F7).
Зайдемо в і зробимо вивантаження у файл для периферійної бази:
- Виділимо план обміну у списку, потім Правою кнопкою викликати контекстне меню і оберемо пункт «Записати зміни…».
Тепер займемося периферійною ІХ. Відкриємо її в монопольному режимі, щоб нікого користувача не було, а також закриємо Конфігуратор. Тепер необхідно запам'ятати вузол, який є основним для поточної бази. Відкриємо Операції - Плани обміну - Вибрати ваш план обміну (наприклад, "За складом"). У списку планів обміну головним вузлом є елемент із жовтою піктограмою. Ця інформація стане нам у нагоді в сьомому пункті. Відкриємо обробку та натиснемо кнопку «Скасувати призначення головного вузла».
Тепер відкриємо периферійну ІБ у конфігураторі і завантажимо той же файл конфігурації, який ми завантажували на першому кроці в центральній базі (Конфігурація-Завантажити конфігурацію з файлу…). Збережемо ІБ (F7).
Змінимо налаштування підтримки (Конфігурація-Підтримка-Налаштування підтримки...). У діалозі виділимо в таблиці комірку на перетині першого рядка та другого колонки. Потім подвійним натисканням викличемо діалог "Налаштування правил підтримки". У ньому поставимо прапорець «Встановити для підлеглих об'єктів» і натиснемо кнопку «ОК». Закриємо діалог налаштування підтримки, натиснувши кнопку «Закрити». Зберегти ІБ (F7). Закриємо конфігуратор.
Тепер знову відкриємо периферійну ІБ у монопольному режимі 1С:Підприємство, щоб нікого з користувачів не було, а також закриємо Конфігуратор. Відкриємо обробку УстановкаГоловногоВзлаБД.epf і виберемо план обміну, який хочемо встановити головним вузлом (у четвертому пункті ми запам'ятовували цей вузол). Потім натисніть кнопку "Встановити головний вузол". Після цього поточна ІБ знову стане периферійною.
Тепер у поточній ІБ (периферійній) відкриємо плани обміну та завантажимо файл з обміном із Центральної бази, який ми отримали на третьому кроці:
- Операції - Плани обміну - Вибрати наш план обміну (наприклад, "За складом").
Якщо все пройшло успішно, то зробимо розвантаження обміну для Центральної бази у поточній ІБ (периферійній):
- Операції - Плани обміну - Вибрати наш план обміну (наприклад, "За складом").
- Виділимо план обміну у списку, потім Правою кнопкою викликати контекстне меню та оберемо пункт «Записати зміни…».
- У діалозі вкажемо шлях та ім'я файлу обміну. Натисніть кнопку "ОК".
Тепер спробуємо завантажити цей файл у Центральній базі, відкриємо його в режимі 1С:Підприємство:
- Операції - Плани обміну - Вибрати наш план обміну (наприклад, "За складом").
- Виділимо план обміну у списку-Правою кнопкою викличемо контекстне меню та вибрати пункт «Прочитати зміни…»
- У діалозі виберемо файл обміну. Натисніть кнопку "ОК".

Щоб уникнути проблем з робочими копіями, зробіть спочатку

Для початку список скорочень, що використовуються:

РІБ – розподілена інформаційна база
ЦБ - центральна база, кореневий вузол РИБ
УБ - віддалена база, БД віддаленого вузла РИБ

З власного досвіду можу сказати, що стикався з двома причинами виникнення помилки:

під час прийому файлу повідомлення в УБ "впала" база, у зв'язку з чим, мабуть, і відбулася розсинхронізація між конф. ЦП та УБ;
під MSSQL клієнт завантажив копію робочої бази та не вимкнув у копії регл. завдання автообміну, в результаті частина повідомлень у віддалені вузли формувалася з робочої БД, а частина з копії, що й призвело до розсинхронізації конфігурацій

Існує також думка, що до цієї помилки наводить використання механізму динамічного оновлення бази. Тут є сумніви, тому що з одного боку динамічне оновлення ніколи не торкається структури БД, а механізми РІБ таки працюють саме зі структурою БД, а не з прикладною її частиною, проте в РІБ використовується механізм формування цифрового підпису версії конфігурації (у Надалі називатиму її для скорочення хеш), і при зміні прикладної частини хеш природно повинен перерахуватися. Не заперечуватиму цього, ні стверджувати, т.к. якщо і стикався із цією ситуацією, то явних доказів цього не знайшов.

Для виправлення використовую 2 методики, залежно від ситуації.

ПЕРША МЕТОДИКА

Перша (найпоширеніша) неодноразово згадується і в партнерській конференції, і на інших інтернет-ресурсах, пов'язаних з 1С. Застосовується здебільшого, коли попри повідомлення про розбіжних змін, при порівнянні вручну видається, що вони ідентичні.

Послідовність дій:

вивантажуємо з ЦП cf-файл;
відв'язуємо УБ від РИБ (метод ВстановитиГоловнийВузол, готову обробку можна знайти у додатку чи інших публікаціях);
замінюємо конф. УБ на вивантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівняння-об'єднання!!!);
відновлюємо ознаку РИБ для УБ.

У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди...

ДРУГА МЕТОДИКА

Застосовується у разі, якщо перша методика не спрацювала, а вивантажити заново вузол неможливо.

Передісторія: у клієнта налаштовували каскадну РИБ і помилка виникла у першому рівні каскаду (другий рівень увесь цей час працював бездоганно). Розробка конфігурації велася разом з IT-службою клієнта і з виникнення помилки конфігурація ЦБ встигла кілька разів помінятися. Варіант з відкатом змін розглядався навіть у принципі, т.к. втрата частини даних та зупинення роботи кількох підрозділів були абсолютно неприйнятними. Перший варіант виправлення помилки якихось відчутних результатів не дав. У зв'язку із чим довелося шукати інші шляхи вирішення.

Прийшла думка спробувати замінити хеш файлів конфігурацій безпосередньо в XML-файлах обміну. Опис структури файлу обміну з книги "Професійна розробка в системі 1С:Підприємство 8" дало слабке уявлення про формування цифрових підписів конфігурацій та змін у них, але визначило напрямок пошуку: значення Digest1 та Digest2. Решта з'ясовував суто емпіричним шляхом (тобто методом спроб і помилок), але закономірність встановити таки вийшло.

Тестові експерименти пройшли вдало. На робочих базах теж все пройшло благополучно.

Отже, послідовність дій:

виконуємо дії 1 – 4 першої методики;
вивантажуємо з УБ файл обміну, але з завантажуємо їх у ЦБ;
вивантажуємо з ЦП файл обміну, але з завантажуємо їх у УБ;
у файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації та хеш (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
робимо завантаження файлу з 4-го пункту в УБ;
обов'язково перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений під час обміну в ЦП!
для перевірки робимо кілька послідовних обмінів.

Якщо під час обміну використовується стиск даних, або відключаємо стиск, або спочатку розпаковуємо файл, змінюємо, потім запаковуємо назад і відправляємо.

Блок файлу обміну із ЦБ

106.0
...тут йдуть блоки опису змін конфігурації...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

потрібно замінити на блок файлу обміну з УБ (зверніть увагу Digest1 у файлу з УБ завжди дорівнює "000000000000000000000000000000000"!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Перелічені дії необхідно виконувати з граничною обережністю, некоректна послідовність загрожує повною непрацездатністю РИБ. Тому перед цими діями створення резервних копій ОБОВ'ЯЗКОВО!

Файл із повідомленням вже завантажувався до бази-приймача. Необхідно вивантажити його з бази-джерела заново.

Помилка «Помилка при копіюванні файлу з FTP ресурсу… Помилка роботи з Інтернетом: Timeout was reached»

З сайту, через який відбувається обмін, не вдається скопіювати потрібний файл. Це може бути пов'язане з повільною роботою вашого інтернету або проблемами самого сайту.
Потрібно повторити обмін через 15-30 хвилин.

Помилка «Редагування даних цього періоду заборонено. Зміни не можуть бути записані...»

Завантажені дані містять документи із закритого періоду.
Потрібно здійснити обмін під користувачам, які мають право на зміну документів у цьому періоді.

Помилка «Необхідне оновлення конфігурації бази даних. Оновлення може бути виконане у режимі конфігуратора»

Причина: Програмісти змінили конфігурацію у центрі. Рішення: Оновити змінену конфігурацію у периферійній базі. Для цього:

Зайти до конфігуратора.
Виконати пункт меню "Конфігуратор / Оновити конфігурацію бази даних".
Якщо ви запитуєте відповіді лише «Повторити», «Скасувати», «Оновити динамічно», натисніть кнопку «Оновити динамічно».
Якщо видається запитання з відповідями лише «Повтор» та «Скасувати».
- всім користувачам вийти із 1С.
- натиснути кнопку "Повтор".
На запитання відповісти ствердно: «Так», «Прийняти», «ОК».
Закрити конфігуратор.
Повторити завантаження із центру.

Помилка «Конфігурація не відповідає очікуваній», «Спроба зміни від невідомої конфігурації»

Помилка у базі даних.
Необхідно звернутися до спеціалістів.

Для початку наводжу список скорочень, що використовуються мною:

РІБ – розподілена інформаційна база
ЦБ - центральна база, кореневий вузол РИБ
УБ - віддалена база, БД віддаленого вузла РИБ

З власного досвіду можу сказати, що стикався з двома причинами виникнення помилки:

під час прийому файлу повідомлення в УБ "впала" база, у зв'язку з чим, мабуть, і відбулася розсинхронізація між конф. ЦП та УБ;
під MSSQL клієнт завантажив копію робочої бази та не вимкнув у копії регл. завдання автообміну, в результаті частина повідомлень у віддалені вузли формувалася з робочої БД, а частина з копії, що й призвело до розсинхронізації конфігурацій

Для виправлення використовую 2 методики, залежно від ситуації.

ПЕРША МЕТОДИКА

Послідовність дій:

вивантажуємо з ЦП cf-файл;
відв'язуємо УБ від РИБ (метод ВстановитиГоловнийВузол, готову обробку можна знайти у додатку чи інших публікаціях);
замінюємо конф. УБ на вивантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівняння-об'єднання!!!);
відновлюємо ознаку РИБ для УБ.

У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди...

ДРУГА МЕТОДИКА

Застосовується у разі, якщо перша методика не спрацювала, а вивантажити заново вузол неможливо.

Тестові експерименти пройшли вдало. На робочих базах теж все пройшло благополучно.

Отже, послідовність дій:

виконуємо дії 1 – 4 першої методики;
вивантажуємо з УБ файл обміну, але з завантажуємо їх у ЦБ;
вивантажуємо з ЦП файл обміну, але з завантажуємо їх у УБ;
у файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації та хеш (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
робимо завантаження файлу з 4-го пункту в УБ;
обов'язково перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений під час обміну в ЦП!
для перевірки робимо кілька послідовних обмінів.

Блок файлу обміну із ЦБ

106.0
...тут йдуть блоки опису змін конфігурації...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

В іншому можу лише побажати удачі!

Розподілена інформаційна база (РІБ) досить часто використовується для організації роботи філій та підрозділів, дозволяючи оперативно обмінюватися інформацією, зберігаючи необхідний ступінь автономності. Незважаючи на те, що ця технологія досить надійна, іноді ламається і вона. Сьогодні ми розглянемо одну з досить поширених помилок: Розкажемо про причини її виникнення та методи боротьби з нею.

Почнемо, як завжди, спочатку. Після того, як ви створили РІБ, всі зміни в конфігурацію інформаційної бази можна вносити тільки в головному вузлі. Згодом, при наступному обміні всі зміни будуть передані в підпорядковані вузли і автоматично застосовані там. Але гладко було на папері.

На практиці іноді трапляється так, що між сеансами обміну, якщо на периферії погано з каналом, конфігурація головного вузла встигає змінитися двічі. Наприклад, внесли зміни, вивантажили, периферійна база зміни отримала, але ще не застосувала їх, що може зайняти деякий час, і підтвердження ще не надіслала. Якщо в цей проміжок внести зміни ще раз і знову вивантажити обмін, то вийде, що центр очікує побачити у периферійному вузлі конфігурацію №1 та спробує оновити її на конфігурацію №3, а за фактом зіткнеться там із конфігурацією №2. Іноді подібна ситуація виникає за динамічного оновлення центральної бази. В результаті обмін стане неможливим, і ви отримаєте повідомлення про те, що Конфігурація вузла розподіленої ІБ відповідає очікуваної!

Загалом мораль цієї історії проста – не ведіть активне доопрацювання робочої бази, а якщо ведете, то завершуйте всі сеанси обміну до внесення наступних змін. Але як бути, якщо така проблема все-таки відбулася?

Рішення "в лоб" - створити новий образ підлеглого вузла, проте на практиці він зазвичай не застосовується. Як правило, виникнення серйозної помилки при обміні фіксується не відразу, а через деякий час після того, як перестали надходити оперативні дані з периферійних баз. Залежно від розкладу обміну між моментом виникнення проблеми та її виявленням може пройти цілий робочий день, а то й більше.

Тут варто кинути камінь у город розробників, які видають як помилку і так само підсвічують червоним ситуацію. Номер повідомлення менший або дорівнює номеру раніше прийнятого повідомлення, яка загалом є цілком нормальною. У результаті у користувачів сприйняття помилок притупляється, і вони просто перестають читати повідомлення, що виводяться, вважаючи, що все добре і просто інша сторона ще не зробила обмін у себе.

Але повернемось до нашої помилки. Рішення просте і лежить на поверхні: привести конфігурацію периферійної бази до очікуваної, тобто. привести її у відповідність до конфігурації центрального вузла. Але на практиці це зробити не так просто. Якщо ми відкриємо периферійну базу конфігуратора, то побачимо, що зміни заблоковані засобами управління РИБ.

Щоб змінити конфігурацію підлеглого вузла, потрібно тимчасово відключити його від центральної бази. Для цього можна скористатися однією з обробок, яких достатньо представлено в мережі, або відключити ІБ від центрального вузла за допомогою параметра запуску Конфігуратора/ResetMasterNode.

Відкрийте командний рядок та введіть (з урахуванням версії платформи та реального шляху встановлення):

"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNode

Після виконання цієї команди з'явиться звичайне вікно стартера, виберіть потрібну базу і натисніть кнопку Коніфгуратор.

Запуск ІБ при цьому не станеться, тобто. може здатися, що нічого не сталося, але відкривши базу в конфігураторі повторно, можна переконатися, що вона відключена від головного вузла і доступна для внесення змін.

Увага!На платформах 8.3.7 – 8.3.9 виконання цієї команди призводить до аварійного завершення роботи. Помилка виправлена у платформі 8.3.10.

Якщо ви не хочете возитися з командним рядком, то можна скористатися однією з обробок, нижче представлена та, яку ми використовуємо, вона була знайдена на просторах мережі, і ми внесли в неї лише косметичні правки. Зверніть увагу, що обробка підходить лише для звичайної програми, для конфігурацій на керованій програмі використовуйте ключ запуску Конфігуратора.

Робота з нею гранично проста, запускаємо її в режимі 1С:Підприємства, через Файл - Відкритипотім просто натискаємо потрібну кнопку, в нашому випадку Вимкнути головний вузол.

Тепер нам буде потрібна актуальна конфігурація з центрального вузла. Для цього відкриємо центральну ІБу Конфігураторі та виконаємо Конфігурація - Зберегти конфігурацію до файлу. Отриманий файл із розширенням cfпотрібно передати в периферійний вузол.

Потім у периферійному вузлі запускаємо ІБ (попередньо відключивши її від головного вузла) у конфігураторі та знімаємо з підтримки. Для цього вибираємо: Конфігурація - Підтримка - Налаштування підтримки.

У вікні спочатку включаємо можливості зміни.

А потім знімаємо конфігурацію із підтримки.

Тепер можна завантажувати конфігурацію із файлу, для цього виберіть Конфігурація - Завантажити конфігурацію з файлута вкажіть не переданий із центрального вузла cf-Файл. Після цього ви отримаєте попередження про те, що поточна конфігурація не порожня. Звертаємо вашу увагу, що маніпуляції, які ми робимо, потенційно небезпечні і можуть призвести до незворотного пошкодження ІБ, тому перед тим, як продовжувати переконайтеся, що у вас є актуальна резервна копія.

Категорії

Популярне