Доброго дня!

При переходе на сервер 1С 8.3, вынужденно пришлось оставить сервер 8.2. Так, что к одной базе были подключения через два сервера 1С. Слетела автоматическая нумерация документов. Отключил, сейчас восстанавливаю. Вопрос, что еще могло поломаться и, что нужно проверить?

все могло поломаться, особенно если туда одновременно лезть двумя конфигураторами и менять структуру базы

(0) Да не переживай, кроме нумерации больше ничего. Все ж сервер 1С - это сервер приложений, а не базы данных)

(0) Если еще не починил нумерацию, сделай ОбновитьНумерациюОбъектов()

(2) Если серверы одной версии - то может и ничего. А если разных, что ж - естественный отбор же должен как-то работать

(0) Некорректно должны работать любые сервисы, которые делятся по информационным базам - один сервис на базу данных.

К ним относятся:

Блокировок объектов. Хранит пессимистические (не транзакционные) блокировки объектов.

Времени. Поддерживает получение оперативной отметки времени и некоторые вспомогательные функции.

Журналов регистрации. Поддерживает доступ к журналам регистрации.

Нумерации. Обеспечивает генерацию уникальных номеров и кодов объектов.

Полнотекстового поиска. Выполняет полнотекстовый поиск и осуществляет индексирование.

Пользовательских настроек. Обеспечивает доступ к файлам, в которых размещаются некоторые пользовательские настройки.

Сеансовых данных. Обеспечивает хранение и кеширование сеансовой информации, например, информация форм управляемого приложения. Обеспечивает получение клиентских лицензий.

Транзакционных блокировок. Содержит транзакционные блокировки управляемого режима.

Работы с внешними источниками данных через ODBC. Обеспечивает взаимодействие с внешними базами данных с помощью интерфейса ODBC.

Сервис фонового обновления конфигурации базы данных. Сервис обслуживает фоновую реструктуризацию базы данных.
Перемещение данного сервиса на другой менеджер кластера требует остановки всех рабочих процессов. При этом будет остановлено системное фоновое задание. Поэтому после перемещения фоновое обновление будет в приостановленном состоянии.

Сервис внешнего управления сеансами. Сервис управляет возможностью создания сеансов, требующих для своей работы клиентской лицензии.

Сервис работы с внешними источниками данных через XMLA. Обеспечивает взаимодействие с источниками OLAP с помощью интерфейса XMLA.


Как минимум у вас должен разъехаться журнал регистрации. Теперь на каждом из серверов свой кусок журнала. Слепить их малореально. Если критично, то надо просто не забыть выгрузить журнал на том сервере, который будете выключать (8.2).
Аналогичная фигня с полнотекстовым поиском. На каждом из серверов свои индекс ППД. После отключения "лишнего" сервера необходимо полностью очистить и обновить индекс ППД.

Остальное (типа сеансовые данные, пользовательские настройки) - не столь критично. Потеряются у кого-то какие-то настройки.

Позиция фирмы 1С:
Такое использование платформы четко квалифицируется как неверное и недопустимое.
Изучение конкретных проблем, которые из-за этого могут возникнуть, не  имеет большого смысла, так как достаточно четко нами доведено, что платформа не поддерживает такой режим работы.
Внедрение такого решения у заказчика мы считаем категорически неправильным.
Заказчик должен быть проинформирован, что имеет место нарушение требований поставщика, а значит нет никакой речи о поддержке такого решения поставщиком.

Источник:http://www.gilev.ru/ib2db/

Короче, суть позиции 1С: это Ваши проблемы, а проблемы индейцев шерифа не волнуют.

(0) ну с вашей судьбой все ясно, а причины? зачем было оставлять еще один сервис-1с? просто интересно )

Блин, даже не знал, что так можно

(8) >> так можно

))) Нельзя. См. (5) и (6).
Оно конечно как-то работает, но последствия мало предсказуемы, а риски вообще неконтролируемы.

(9) я имел ввиду, что можно так попасть, что сервер 1с даже не поругается, что типа блокировка базы другим сервером или еще как-то))

(7) >> зачем было оставлять еще один сервис-1с?

Тут вариантов немного:
Либо сдуру решили так "подстраховаться".
Либо не сумели обновить 1С-ку на всех клиентских компах и опять таки сдуру решили оставить оба сервака, пока всем не обновят.
Ну и наконец третий вариант - тупо забыли погасить старый сервак (отключить там базу), а некоторые клиенты сумели к нему подключиться.
А еще может быть были настроены какие-нибудь обмены, где были жестко прописаны параметры старого сервера.

(10) А с чего бы ему ругаться. К базе данных может цепляться кто угодно. В том числе другие процессы rphost этого же самого сервера (что является совершенно нормальным).