Как отключить узел риб 1с от центрального
Обновлено: 20.05.2024
Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай - для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
. ВАЖНО. Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).
В качестве "исходного узла" выберем "Корневой узел" (см. схему РИБ). В нем аккумулируются данные всех узлов.
ВАЖНО. В качестве "исходного узла" рекомендуется выбирать узел, который впоследствии станет главным узлом для вновь созданного/восстановленного узла.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.
0. В режиме предприятия создаем новый узел РИБ в "исходном узле".
Данное действие необходимо, если создается новый узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из "исходного узла" в файл (*.dt).
Для "пухлых" БД можно просто скопировать 1Cv8.1CD, для клиент-серверных БД - например, скопировать средствами СУБД.
2. Загружаем полученную в п. 1 выгрузку в "чистую" БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных в подчиненной БД.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже "приезжают" с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
для Linux-клиента "файловый" вариант БД:
для Linux-клиента "клиент-серверный" вариант БД:
для Windows-клиента "файловый" вариант БД:
для Windows-клиента "клиент-серверный" вариант БД:
соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
У одного клиента встала необходимость отключить базы от главного узла и перевести их в работу как самостоятельной информационной базы. Вроде ничего сложного нет, но столкнулся с такой проблемой, что параметр ResetMasterNode не работает на платформе 8.3.16.1148. Ни через запуск через параметр, ни через запуск с ярлыка с запуском от прав администратора.
В итоге выяснилось чисто экспериментальным путём что, ключ ResetMasterNode РАБОТАЕТ на версиях платформы 8.3.12.х и 8.3.13.х, на платформах выше с 8.3.14х-8.3.16.х запуск с параметром приводит просто к закрытию конфигуратора.
Теперь по этапность действий которые 100% рабочие для отвязки периферийной базы от главного узла:
- Ставим любую платформу из линейки 8.3.12.х-8.3.13.х (мною были опробованы платформы 8.3.12.1529, 8.3.12.79, 8.3.13.1644). Так как версия розницы 2.3.3.19 не запускается ниже чем на 8.3.12.х, то работоспособность параметра ResetMasterNode на нижних версиях платформы не представилась возможной. ну и ладно ))
- Далее я создал отдельный ярлык с указанием явного пути до платформы с параметром config /ResetMasterNode (см. рисунок)
- Запускаем конфигуратор и вуаля, он у нас запрашивает аутентификацию пользователя (если в ИБ она есть) и также не запускается (хотя по описанию на ИТС должен открыться конфигуратор с вопросом об отмене главного узла) ))
- Далее запускаем из штатного ярлыка 1С нашу конфигурацию в режиме предприятия (на любой платформе) и нам уже предлагается отвязать или восстановить связь с главным узлом
После того, как произведутся действия по отключению периферийной базы от главного узла РИБ, проверяем для уверенности в том, чтобы всё было в порядке, проверяем две константы через меню Все функции:
первая константа Это автономное рабочее место
и вторая константа Настройка подключенного узла РИБ Завершена.
У обоих констант галки должна быть сняты.
Ну вот как бы и всё. Надеюсь, что кому-то написанное выше сэкономило время в решении возникшей проблемы
1. Создаешь внешнюю обработку или отчет в ней форме пишешь
Код 1C v 8.х
2. Сохраняешь обработку.
3. Закрываешь конфигуратор
4. Запускаешь пользовательский режим.
5. Запускаешь обработку.
Еще Вариант кода:
Код 1C v 8.х
Похожие FAQ
Еще в этой же категории
Конвертация данных 3.0. Настройка правил конвертации в формате Enterprise Data. Пример использования 63Задача Передать информацию о контрагентах из УП в БП . Данные передаются в одностороннем порядке, идентификация производится по уникальному идентификатору.Настройка правил конвертации выполняется с помощью специальной конфигурации Конвертация Планы обмена и их использование 12
Для того чтобы существовала возможность обмена какими-либо данными с кем-либо, необходимо некоторым образом идентифицировать тех, с кем мы будем обмениваться, и для каждого из них описать перечень обмена Обе эти задачи позволяет решать прикладной об Автоматическая выгрузка загрузка данных используя регламентное задание 11
Для обмена данными между программами необходимо сделать следующее: 1. При помощи Конвертации Данных создать правила выгрузки данных 2. Нужно чтобы в конфигурации была обработка УниверсальныйОбменДаннымиXML , желательно последней версии! (При помо Автоматизация обмена данных используя обработку "Универсальный обмен данными в формате XML" 10
Автоматизация обмена между базами используя обработку " Универсальный обмен данными в формате XML" В основу данной публикации положены найденные мною материалы по cозданию обмена между двумя базами с использованием обработки " Универсальный обме Импорт - экспорт данных через XML. Обработка обмена документами 7
Восстановление документов 1С из архива в рабочую базу (XML обмен) Не редко требуется восстановить данные испорченного документа 1С из архива базы после не умышленных, а зачастую ошибочных, действий удачливого пользователя. Самым простым способом я Посмотреть все в категории Конвертация данных, Обмен, Перенос
Ключевые слова и Изображения
Слова упорядочены по частоте использования в тексте
Изображения
Ну и ничего не произошло. База как была подчиненной, так и осталась.
Кстати забыл сказать привинтил обратно базу к главной при помощи вышеописанной обработки. Спасибо E_MigachevДоброе время суток. Хочу поделиться с вами своим горьким опытом по обмену между узлами.
Дело было так:
Была база(Как потом выяснилось - главная), в базе была ошибка, вылетала при переходе на новый релиз (где-то в зарплате, какая - то дата не определялась), правдами и не правдами - я её додумался как обойти(в конфигураторе - все же программист 1с), потом таки обновил. Через некоторое время - мне звонят и говорят "Наша подчиненная база не запускается вообще. Разберись с этим".
Захожу к ним по удаленке, смотрю - точно не запускается, та же ошибка что и в главной базе.
Итого:
1.есть главный узел - с новым релизом и новыми документами;
2.есть подчиненный узел - тоже с новыми документами и старым релизом.
Подчиненная запускается и сразу просит обновиться(Окно обновлений открывается модально - никуда не залезешь, Ctr + O - тоже не работает.)
Решение: Как оказалось все на много проще чем я думал. Есть такая полезная штука ка "Запуск 1с из командной строки". К стати если кто знает где есть более полная инфа по запуску 1с из командной строки - поделитесь пож., а то в инете только некоторые параметры.
Итак лечение подчиненной базы -
Запустить конфигуратор с параметром командной строки /ResetMasterNode (для базовых версий не используется).
В этом материале подробная инструкция по настройке обмена РИБ для 1С:Предприятие 8 и проблемы, с которыми столкнулся автор.
1. Создание узлов
Создаем новые узлы (главный и подчиненный): в пользовательском режиме "Операции / Планы обмена/Полный"
Выберем план обмена "Полный"
Создаем две записи:
- первую запись назовем "ЦБ" (главный узел), код укажем "ЦБ",
- вторую запись назовем "Подчиненный узел", код укажем "ПУ".
Значек с зеленным кружком - "ЦБ" (главный узел)
2. Настройка префиксов
Для каждой базы, в настройках параметров учета (в УПП "Сервис / Параметры учета") на закладке "Обмен данными", устанавливаем префиксы. Это делается для того чтобы не возникало конфликтов в номерах и кодах документов и справочников, созданных в двух базах.
Для автообмена, устанавливаем галочку "Использовать механизм автоматического обмена. "
Закладка "Обмен данными"
Нажимаем на значок "Выполнить обмен по текущей настройке"
Выполнить обмен по текущей настройке
Теперь о "подводных камнях"
1. Обмен данными может выполняться в автоматическом режиме и может быть инициализирован в следующих случаях:
* При запуске программы. Обмен будет выполняться при запуске программы,
* При завершении работы с программой. Обмен будет выполняться перед завершением пользователем работы с программой,
* При появлении каталога. Обмен будет выполнен только в том случае, если каталог указанный пользователем был невиден, а в настоящий момент стал виден. Настройка может быть использована для выполнения автоматического обмена при подключении к локальной сети или flash карты. Программа периодически будет проверять видимость указанного в настройках каталога и отмечать его текущее состояние,
* При появлении файла. Рекомендуется использовать данные режим, когда нужно выполнить обмен, если появляется входящий файл обмена данными. В этом случае, достаточно указать полный путь к входящему файлу обмена данными. Программа периодически анализирует наличие файла, и как только он появится, будет выполнен обмен, а после обмена этот файл будет принудительно УДАЛЕН (это делается для того, что бы процедура обмена не выполнялась постоянно),
* Периодический обмен данными. Обмен будет выполняться согласно настройкам периодического обмена данными. Если информационная база работает в файл-серверном режиме, то периодический обмен выполняется только у пользователя, который указан в параметрах учетной политики как "Пользователь для регламентных заданий в файловом режиме". В Клиент-серверном варианте обмен выполняется на сервере 1C:Предприятия.
У меня Клиент-серверный вариант - для работы регламентного автообмена пришлось перегружать сервер
2. Кодировка Windows.
Обмен прерывался ошибкой - так как не происходит сжатие файла. Это из-за ошибки кириллицы в командной строке при сжатии.
Лечится исправлением кодировок в реестре.
Например, для Windows Server 2008 -
Код
3. Создавая копию базы (например, для доработки) в клиент-серверном варианте, НЕОБХОДИМО, чтобы РЕГЛАМЕНТНЫЕ ЗАДАНИЯ КОПИИ базы были ВЫКЛЮЧЕНЫ.
Блокировка регламентных заданий для копии ВКЛ
Для чего это нужно? Допустим необходимо создать тестовую БД для разработки с актуальными данными или необходимо быстро восстановить работоспособность РИБ при "падении" одного из узлов, или для "быстрого" создания нового узла РИБ .
Имеем: 1С:Предприятие 8.3 (8.3.6.2390), РИБ по следующей схеме:
Данные во всех узлах синхронизируются полностью. Это идеальный случай - для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
. ВАЖНО. Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения)
Приступим. В качестве "исходного узла" выберем "Центральный узел обмена" (см. схему РИБ). В нем аккумулируются данные всех узлов.
ВАЖНО. В качестве "исходного узла" рекомендуется выбирать узел, которой в последствии станет главным узлом для вновь созданного/восстановленного узла.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными, но это более сложный процесс. Возможно он будет рассмотрен в будущем.
0. Создать новый узел РИБ.
Данное действие необходимо если создается новый узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из "исходного узла" в файл (*.dt).
2. Загружаем полученную в п. 1 выгрузку в "чистую" БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже "приезжают" с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
для Linux-клиента "файловый" вариант БД:
для Linux-клиента "клиент-серверный" вариант БД:
для Windows-клиента "файловый" вариант БД:
для Windows-клиента "клиент-серверный" вариант БД:
соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
5. Отключаем главный узел обмена.
Как и в предыдущем пункте, для этого необходимо запустить конфигуратор из командной строки с параметрами и дождаться его выполнения:
для Linux-клиента "файловый" вариант БД:
для Linux-клиента "клиент-серверный" вариант БД:
для Windows-клиента "файловый" вариант БД:
для Windows-клиента "клиент-серверный" вариант БД:
6. Запускаем 1С в режиме предприятия и, и в появившемся предложении о восстановлении связи с "главным узлом обмена", подтвердить ОТКЛЮЧЕНИЕ.
7. Настраиваем узлы.
Если нам необходима БД для разработки - удаляем лишние узлы обмена и сценарии синхронизации. Все БД готова. Можно переходить к п. 8
Если создаем новый узел РИБ:
Восстанавливаем настройки и возможность входа пользователей.
8. Восстанавливаем автоматическое обновление предопределенных данных.
Как и в п. 4, для этого необходимо запустить конфигуратор из командной строки с параметрами и дождаться его выполнения:
Читайте также: