Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай — для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
!!!ВАЖНО!!! Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
зарегистрированных изменений для главного узла.
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).
В качестве «исходного узла» выберем «Корневой узел» (см. схему РИБ). В нем аккумулируются данные всех узлов.
ВАЖНО!!! В качестве «исходного узла» рекомендуется выбирать узел, который впоследствии станет главным узлом для вновь созданного/восстановленного узла.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.
0. В режиме предприятия создаем новый узел РИБ в «исходном узле».
Данное действие необходимо, если создается новый узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из «исходного узла» в файл (*.dt).
Для «пухлых» БД можно просто скопировать 1Cv8.1CD, для клиент-серверных БД — например, скопировать средствами СУБД.
2. Загружаем полученную в п. 1 выгрузку в «чистую» БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных в подчиненной БД.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже «приезжают» с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
для Linux-клиента «файловый» вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
для Linux-клиента «клиент-серверный» вариант БД:
/opt/1C/v8.3/x86_64/1cv8 DESIGNER /S"SRVname:portBDname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
для Windows-клиента «файловый» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
для Windows-клиента «клиент-серверный» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /S"SRVname:portDBname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically
соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
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:portBDname" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
для Windows-клиента «файловый» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /ResetMasterNode
для Windows-клиента «клиент-серверный» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /S"SRVname:portDBname" /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:portBDname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
для Windows-клиента «файловый» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
для Windows-клиента «клиент-серверный» вариант БД:
"C:Program Files (x86)1cv838.3.6.2390in1cv8.exe" DESIGNER /S"SRVname:portDBname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -Auto
P.S.
Проверялось на «Управление торговлей, редакция 11.1 (11.1.10.185)».
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Статья хорошая, разжёвано доступно. Раньше бы её повстречать…
К статье обработка:
А причём здесь БСП? На любых конфигурациях должно работать
Уже в который раз появляется статья как сделать подчиненный узел без стандартной выгрузки (так как это очень долго).
Только, и это стандартно, не осознаются некоторые нюансы этого вновь изобретенного велосипеда.
Хотите ли вы чтобы АБСОЛЮТНО вся информация из исходной базы была во вновь созданной? Как-то — персональные данные, финансовые данные, зарплатные данные и прочие данные не для всех. Если у вас нет такой «информации не для всех» — замечательно.
Рассмотрим ситуацию когда такая информация существует. Многие сразу указывают на права доступа. Опять же покажем на грабли. В типовых конфигурациях (более-менее ковырял УПП и за все конфигурации ручаться не буду) обновление конфигурации (которые регулярные) не редко требует первого захода в программу под полными правами (чтобы при изменении структуры данных произвести некоторые обработки, а если нет доступа к этим данным — не хорошо получится). И либо приходится пользователю на удаленном узле давать полные права либо придумывать механизм обновления без участия пользователя. Плюс всегда возможны ошибки при раздаче прав- и увидит пользователь то, чего видеть не должен.
Поэтому имейте в виду описанные особенности.
(4) kosmo0, В статья рассмотрен случай, когда данные во всех узлах синхронизируются полностью (см. описание). «Многие сразу указывают на права доступа» — да, именно правами и ограничивайте что и кому можно видеть.
А исключить ошибки при раздаче прав — это задача грамотного админа. При создании подчиненного узла «копированием» и права скопируются — так что процент ошибки сводится опять-таки к грамотной первоначальной настройке прав. А с утверждением «приходится пользователю на удаленном узле давать полные права» вообще не согласен — обычный пользователь априори не должен обладать полными правами, для этого есть администратор, в задачи которого и входит создание/восстановление узлов РИБ.
В окне запуска 1С, в параметрах базы данных есть поле «Дополнительные параметры запуска», так что заморачиваться с командной строкой на мой взгляд смысла нет.
Проверял год назад -DoNotUpdateAutomatically корректно не отрабатывало. Из подчиненного узла, если сделать отдельную базу, обновлениями как раз задваивало предопределеннные элементы справочников при следующих обновлениях.
Бухгалтерия 3.0
Так что пока не проверю плюс ставить не буду 🙂
(6) capitan, у меня не отрабатывало как раз из дополнительных параметров запуска, а из командной строки работает =)
Забавно, но на последних релизах БП и платформе 8.3.7 не отрабатывает ключ /ResetMasterNode
Крашится конфигуратор и все.
Буду пробовать на ранних релизах 8.3.6
Может кому пригодится.
Попробовал на
8.3.6.2530
8.3.7.1917
8.3.7.2027
8.3.8.1652
/ResetMasterNode корректно отрабатывает только на 8.3.6
остальные просто рушатся при вызове
/SetPredefinedDataUpdate -DoNotUpdateAutomatically
вообще никакого эффекта не дает
Подскажите, пожалуйста, куда записываются измененные данные для последующего обмена?
Можно ли их посмотреть и очистить выборочно?
Ситуация: Создали распределенную БД. Некоторое время с ней работали, затем произошел сбой. Отключили основную базу и еще раз создали РИБ, наименование узлов оставили. Сейчас база очень быстро растет, может ли быть, что измененные данные записываются для двух баз (старой распределенной обмены не делаются и новой)?
Отработают ли эти ключи на платформе 8.2 конфигурация УПП?
(10) Изменения записываются в таблицу регистрации изменений (виртуальная таблица каждого объекта метаданных, который участвует в обмене). Посмотреть какие объект зарегистрированы к обмену можно. Есть специальная обработка «Регистрация изменений для обмена данными» (в настройках синхронизации — команда «Состав отправляемых данных» или ищите через «все функции»). Ключи не зависят от конфигурации — следовательно отработают.
(9)Код ошибки: 10171274
Код(ы) обращения: SW1097699
Статус: Исправлена в выпущенной версии Зарегистрирована: 01.12.2016
Исправлена: «Технологическая платформа», версия 8.3.10.2252
И в серверном варианте «наступил». 8.3.8.2322. Поставил «исправленную». Отключился от узла. Вернулся на «любимую»(8.3.8.2322). Подключился к узлу. Все дальше заработало.