gifts2017

Корректное отключение от главного узла РИБ и создание самостоятельной БД. Быстрое создание/восстановление узла РИБ без выгрузки начального образа для конфигураций на основе БСП

Опубликовал aleks (asg.aleks) в раздел Администрирование - Распределенная БД (УРИБ, УРБД)

В публикации описан один из способов создания тестовой БД для разработки с актуальными данными, быстрого восстановления работоспособности РИБ при "падении" одного из узлов, или "быстрого" создания/восстановления узла РИБ без выгрузки начального образа для конфигураций на основе БСП.

Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай - для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.

!!!ВАЖНО!!! Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!

Убедиться, что в главном узле обмена (из которого создаем) нет зарегистрированных изменений для подчиненного узла (который создаем/восстанавливаем), в подчиненном, соответственно, не должно быть
зарегистрированных изменений для главного узла.


Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).

В качестве "исходного узла" выберем "Корневой узел" (см. схему РИБ). В нем аккумулируются данные всех узлов.

ВАЖНО!!! В качестве "исходного узла" рекомендуется выбирать узел, который впоследствии станет главным узлом для вновь созданного/восстановленного узла. 

Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.

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:port\BDname" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically


для Windows-клиента "файловый" вариант БД:

"C:\Program Files (x86)\1cv83\8.3.6.2390\bin\1cv8.exe" DESIGNER /F"PathToLocalDB" /N"AdminUser" /P"AdminUserPass" /SetPredefinedDataUpdate -DoNotUpdateAutomatically


для Windows-клиента "клиент-серверный" вариант БД:

"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


P.S.

Проверялось на "Управление торговлей, редакция 11.1 (11.1.10.185)".

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Knopodav (Knopodav) 16.02.16 21:24
Статья хорошая, разжёвано доступно. Раньше бы её повстречать...
2. Александр Окулов (PowerBoy) 17.02.16 06:21
3. Роман Ершов (MRAK) 17.02.16 09:07
А причём здесь БСП? На любых конфигурациях должно работать
4. Иван Иванов (kosmo0) 17.02.16 13:00
Уже в который раз появляется статья как сделать подчиненный узел без стандартной выгрузки (так как это очень долго).
Только, и это стандартно, не осознаются некоторые нюансы этого вновь изобретенного велосипеда.

Хотите ли вы чтобы АБСОЛЮТНО вся информация из исходной базы была во вновь созданной? Как-то - персональные данные, финансовые данные, зарплатные данные и прочие данные не для всех. Если у вас нет такой "информации не для всех" - замечательно.
Рассмотрим ситуацию когда такая информация существует. Многие сразу указывают на права доступа. Опять же покажем на грабли. В типовых конфигурациях (более-менее ковырял УПП и за все конфигурации ручаться не буду) обновление конфигурации (которые регулярные) не редко требует первого захода в программу под полными правами (чтобы при изменении структуры данных произвести некоторые обработки, а если нет доступа к этим данным - не хорошо получится). И либо приходится пользователю на удаленном узле давать полные права либо придумывать механизм обновления без участия пользователя. Плюс всегда возможны ошибки при раздаче прав- и увидит пользователь то, чего видеть не должен.

Поэтому имейте в виду описанные особенности.
5. aleks (asg.aleks) 17.02.16 16:33
(4) kosmo0, В статья рассмотрен случай, когда данные во всех узлах синхронизируются полностью (см. описание). "Многие сразу указывают на права доступа" - да, именно правами и ограничивайте что и кому можно видеть.
А исключить ошибки при раздаче прав - это задача грамотного админа. При создании подчиненного узла "копированием" и права скопируются - так что процент ошибки сводится опять-таки к грамотной первоначальной настройке прав. А с утверждением "приходится пользователю на удаленном узле давать полные права" вообще не согласен - обычный пользователь априори не должен обладать полными правами, для этого есть администратор, в задачи которого и входит создание/восстановление узлов РИБ.
6. Капитан Немо (capitan) 18.02.16 13:41
В окне запуска 1С, в параметрах базы данных есть поле "Дополнительные параметры запуска", так что заморачиваться с командной строкой на мой взгляд смысла нет.
Проверял год назад -DoNotUpdateAutomatically корректно не отрабатывало. Из подчиненного узла, если сделать отдельную базу, обновлениями как раз задваивало предопределеннные элементы справочников при следующих обновлениях.
Бухгалтерия 3.0
Так что пока не проверю плюс ставить не буду :)
7. aleks (asg.aleks) 18.02.16 17:13
(6) capitan, у меня не отрабатывало как раз из дополнительных параметров запуска, а из командной строки работает =)
8. Капитан Немо (capitan) 10.05.16 18:35
Забавно, но на последних релизах БП и платформе 8.3.7 не отрабатывает ключ /ResetMasterNode
Крашится конфигуратор и все.
Буду пробовать на ранних релизах 8.3.6
9. Капитан Немо (capitan) 11.05.16 14:11
Может кому пригодится.
Попробовал на
8.3.6.2530
8.3.7.1917
8.3.7.2027
8.3.8.1652
/ResetMasterNode корректно отрабатывает только на 8.3.6
остальные просто рушатся при вызове
/SetPredefinedDataUpdate -DoNotUpdateAutomatically
вообще никакого эффекта не дает
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа