1️⃣🔤 Консоль администрирования кластера 1С и чудеса её кэша

Недавно столкнулся с ситуацией, когда поговорки "Не верь глазам своим" и "Доверяй, но проверяй" звучат очень актуально)

Было замечено что Рабочие процессы сервера 1С не перезапускаются уже несколько дней

Скриншот на 12/08/2025

Что мы тут видим:

▫️Установлен параметр Интервал перезапуска в 86400 секунд (одни сутки).
▫️При этом в кластере все Рабочие процессы, которые родились 07/08/2025 (Время запуска), т.е. почти 5 дней назад, до сих пор имеют статус Активен.

Первая мысль: Ошибка в платформе и кластер перестал реагировать на Интервал перезапуска
НО, по своему опыту я знаю, что в 99% случаев когда кажется что это ошибка, оказывается что платформа тут не при чём и ошибка где-то в другом месте или мы просто не пониманием механизма работы.

При этом факты на лицо и спорить с ними очень сложно.

Давайте разбираться.
Информация о настройках и составе кластера 1С платформа хранит в файле Реестра кластера 1CV8Clst.lst https://its.1c.ru/db/v8327doc#bookmark:adm:TI000000372
К сожалению описания состава этого файла в документации нет, поэтому обратимся к практике

В первых двух строках файла Реестра кластера видим:

{0,
{a2e908eb-b732-4807-ac75-166a8ee4c099,"server-1c",1541,"server-1c",0,0,0,30,0,0,0,

Тут важно подчеркнуть что ситуация была на платформе 8.3.26, в платформе 8.3.27 параметр перезапуска полностью изменился как внешне так и по механике поведения.

Итак, что мы тут видим?
Очень знакомая цифра 30, подозрительно похожая на значения параметра кластера "Проблемные процессы завершать через"...
И при этом нигде в файле реестра не видно цифры 86400

Что делать:
1. Верить файлу реестру кластера
2. Перезапустить консоль или как минимум перейти на самый верх в консоле и нажать Обновить (но это не всегда помогает)

После перезапуска в консоли видим что Интервал перезапуска оказывается 0. а не 86400

И в файле реестра кластера теперь запись:

{0,
{a2e908eb-b732-4807-ac75-166a8ee4c099,"server-1c",1541,"server-1c",0,0,86400,30,0,0,0,

Надеюсь это поможет вам разобраться с "чудесным" поведением казалось бы Платформы, а на самом деле mmc-консоли

1️⃣🔤 Как проверить применены ли ТНФ в кластере?

При настройке ТНФ (Требований назначения функциональности) в консоле администрирования и в обработке Управление серверами невозможно отличить уже применённое ТНФ от просто созданного.

Это приводит к неоднозначности понимания работы кластера.
Так как кажется что он работает не так как его настроили.

Опять же, в 99% случаев Платформа работает верно, это просто мы не понимаем почему сейчас верно работать именно так, а не иначе 😁

Итак, возьмём кластер состоящий из двух серверов:
▫️ Server1c - сервис программного лицензирования
▫️ Server1c-2 - центральный сервер

Уже настроенные и применённые ТНФ этих серверов на (скриншоте 1)

Добавляем ТНФ для Server1c: Сервис Дата акселератора - Не назначать (скриншот 2)

❗️ И вот теперь попробуйте догадаться, применено это требование или нет?

И тут нам на помощь опять приходит файл реестра кластера.

При применённых ТНФ с первого скриншота часть файла, относящаяся к ТНФ выглядит так:

{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{2,
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}
},
{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{2,
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}

Теперь создадим ТНФ для Server1c: Сервис Дата акселератора - Не назначать

{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{3,
{46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0},
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}
},
{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{2,
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}

Тут видно что в верхнем блоке у нас появилась запись: {46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0},

А теперь выполним полное применение ТНФ:

{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{3,
{46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0},
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}
},
{2,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
},a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{3,
{46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0},
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}
}

И вот теперь запись {46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0}, появилась не только в пером, но и во втором блоке!
❗️Именно наличие записи в двух блоках говорит о том что ТНФ применено

1️⃣🔤 Как понять к какому серверу какие ТНФ относятся по файлу реестра?

В файле есть состав кластера:

{2,
{aef09594-d129-4af5-8760-d29b3cadb460,"server1c",1,0,1000,a51a9c1e-cfdc-464e-a966-c526cf9c41d7,1},
{1fee5301-406f-4669-8111-6f3922040417,"SERVER1C-2",1,0,1000,0cd2713d-8663-4ce1-8c43-8823ebfae4a4,0}

▫️server1c имеет id a51a9c1e-cfdc-464e-a966-c526cf9c41d7
▫️server1c-2 имеет id 0cd2713d-8663-4ce1-8c43-8823ebfae4a4

И каждый блок ТНФ так же имеет запись, к какому id он относится:

0cd2713d-8663-4ce1-8c43-8823ebfae4a4,
{2,
{e53260f6-2ad5-4562-935a-a17ad4db3220,1,1,1,1,1,0},
{a963ead5-cc11-41bc-b89b-c02d2c16bf80,0,"DataAcceleratorService",1,1,0,3,0}
}

Тут видим что к id 0cd2713d-8663-4ce1-8c43-8823ebfae4a4 (server1c-2) относятся 2 ТНФ (цифра 2 после id) и затем описание этих ТНФ

Соответственно следующий блок описывает 3 ТНФ для Server1c:

a51a9c1e-cfdc-464e-a966-c526cf9c41d7,
{3,
{46d69966-6805-4689-8768-b6f89aa3cbdb,0,"DataAcceleratorService",1,1,0,1,0},
{f029efbd-99d9-4b39-a678-43fe969d1bcb,0,"LicenseService",1,1,2,1,0},
{4204e792-f02f-452d-b2a8-9c3b60ac8581,1,1,1,0,1,0}

Таким образом, чтобы увидеть какие ТНФ созданы, а какие уже применены у нас есть хоть и не удобный, но инструмент,

❗️ВАЖНО: Состав файла реестра кластера не документирован и может поменяться, поэтому необходимо обязательно тестировать свои предположения на новых платформах

1️⃣🔤 Чудеса с пользователями при работе в apache linux + AD

Переход на Linux инфраструктуры 1С это уже не какие-то непонятные слова, а реальность от которой убегать всё сложнее.
И в процессе эксплуатации таких систем случаются "чудеса", которые не то что в документации по 1С не отражены, но и не находятся в поисковиках интернета и даже не решаются с помощью ИИ 😁

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

Для получения такого эффекта нам нужна база 1С опубликованная на Linux+apache и авторизация в 1С настроенная на Active Directory

❗️И тогда, при нажатии в браузере F5 у вас неожиданно может измениться пользователь под которым вы работаете в 1С.
Очень опасное поведение, но как ни странно - опять платформа 1С не при чём!

А кто виноват?
Виновата связка apache и mod_auth_gssapi (модуль авторизации AD) + режим работы mpm (модуль многопоточности, Multi-Processing Modules)

Модуль mpm может работать в 3-х режимах:
▫️ Event
▫️ Worker
▫️ Perfork

Каждый из этих режимов имеет свои плюсы и минусы и возможности тонкой настройки, но для 1С обычно хватает настройки по умолчанию.

На разных Linux, а их десятки, по умолчанию при установке apache или уже на установленном может быть выбран любой из них.
Проверить какой именно можно командами:

httpd -V | grep MPM

или
```shell
apachectl -V | grep -i mpm`


Так вот, для корректной работы авторизации нам требуется режим prefork

Как переключиться на этот режим mpm с режима event:
▫️sudo a2dismod mpm_event (отключаем текущий режим)
▫️sudo a2enmod mpm_prefork (включаем нужный нам режим prefork)
▫️sudo systemctl restart apache2 (перезапускаем apache)

Эта проблема очень сложно выявляется на тесте, так как редко тестируется под несколькими пользователями.
Надо знать про наличие такой проблемы чтобы специально её тестировать.
❗️Будьте внимательны!

🗓 Выступления на конференциях в ближайшие пару месяцев

✅11-12 Сентября, Hackathon в ИнфоСофт, Новосибирск, Было круто!
▫️27-28 Сентября - Партнёрский семинар 1С, Москва
▫️29 Сентября - PGConf.СПб 2025, Санкт-Петербург
▫️09-12 Октября - Infostart Tech Event 2025, Санкт-Петербург
▫️17-19 Октября - Merge.Baltic, Калининград/Светлогорск
▫️24 Октября - Жёлтая конфа, Москва

Не знаю почему для организаторов не существует в году месяцев кроме Сентября и Октября 😁

🔤🔤🔤 Когда Dump базы PostgreSQL при восстановлении может содержать данные на гораздо ранний период чем вы ожидали?

Сразу оговорюсь - dump это крайне надёжный и очень гибкий способ создания резервных копий!

Но, есть нюансы...

Рекомендуемая в том числе и мной схема организации резервного копирования:
▫️Мастер
▫️Реплика для отказоустойчивости
▫️Реплика для резервных копий

Соответственно резервные копии, например с помощью утилиты pg_dump (а в PostgreSQL есть ещё и другие способы сделать backup) рекомендуется делать с "Реплики для резервного копирования".
Так как dump это длительная транзакция, а длительные транзакции для PostgreSQL это плохой сценарий для мастера приводящий к блокировке работы autovacuum (процесс автоочистки "мёртвых" строк).
Помимо этого dump это ещё и достаточно большая нагрузка на диски, что так же не зачем мастеру, его работа пользователей обслуживать, а не ит-шные хотелки 😁

Итак, осознавая зачем и почему мы прилежно делаем dump-ы с реплики и считаем что всё хорошо. В целом оно так и есть при одном условии:
❗️Если реплика не отстаёт от мастера

Давайте на цифрах:
▫️Время на мастере - 12:00:00
▫️Время на которое реплика уже "проиграла" в себя данные - 11:59:59.389
▫️Время старта dump с реплики - 12:00:00
✅В этом случае всё прекрасно, делаем dump, и при восстановлении данные в базе будут на 11:59:59.389. так как dump консистентен на начало транзакции.

Теперь другой сценарий:
▫️Время на мастере - 13:00:00
▫️Время на которое реплика уже "проиграла" в себя данные - 11:59:59.389
▫️Время старта dump с реплики - 13:00:00
❗️В этом случае при восстановлении данные в базе будут на 11:59:59.389 и это неожиданно! Ведь мы то думали что они будут на момент старта dump-а 13:00:00!

Как такое произошло?
Всё дело в отставании реплики, оно на момент старта dump-а составило чуть более 1 часа.

Откуда может взяться отставание?
Дело в том, что в отличии от мастера, реплика однопоточная и ничего не знает о версиях, номерах транзакций и т.д., очень нужных вещей для мастера и совершенно бесполезных для реплики.
И если на реплики идёт транзакция, то "проигрывание" данные в базу останавливается (начинается накопление WAL - журнала предзаписи), "проигрывание" продолжится как только транзакция будет завершена. И так до следующей транзакции.
И как ни странно, этой первой транзакцией может легко оказаться наш первый dump, который просто длился более 1 часа

Второй вариант отставания - это чисто "железное" отставание, когда не справляется сеть между мастером и репликой. В этом случае на реплику просто не поступили ещё WAL-ы с мастера и ей нечего записать в базу.

Как получить отставание реплики от мастера?
Для этого есть специальное представление pg_stat_replication

select replay_lag from pg_stat_replication

Вернёт нам отставание реплики от мастера. например 00:00:00.003122

Но отставание как мы выше поняли может быть 2х типов (на самом деле больше, но это уже экзотика), получить отставание, которое обосновано не транзакциями на реплике, а сетью можно тем же представлением:

select wtite_lag from pg_stat_replication

❗️Что с этим со всем делать?

1. Следить за отставанием реплик
2. Иметь более одной реплики от мастера
3. Использовать другие средства резервного копирования (pg_basebackup, probackup и ещё штук 10 вариантов открытого ПО)
4. При крайней необходимости сделать dump с мастера, он всегда будет содержать данные на момент начала dump-а

🔤🔤🔤 PostgreSQL, symlink, неожиданность с репликацией и бэкапами

Есть довольная распространённая практика переноса каталога Журнала предзаписи транзакций (WAL) на другой диск, что даже рекомендуется разработчиками Postgres и звучит эта рекомендация так:
Имеет смысл размещать WAL на другом диске, отличном от того, где находятся основные файлы базы данных. Для этого можно переместить каталог pg_wal в другое место (разумеется, когда сервер остановлен) и создать символическую ссылку из исходного места на перемещённый каталог.

И тут всё хорошо. Действительно в Postgres нет настройки расположения каталога pg_wal и его перенос решается через создание символической ссылки на каталог (symlink).

По всей видимости лёгкость, понятность и распространённость такого подхода повлияла на то что Администраторы СУБД либо Системные администраторы помимо каталога pg_wal так же этим способом переносят и другие каталоги Postgres.

А тут нас ждёт очень интересная проблема...
Дело в том, что утилита pg_basebackup с помощью которой создаются резервные копии кластера PostgreSQL и реплики (для них создание резервной копии кластера это первый шаг создания) не учитывает символические ссылки.

Что в итоге мы можем получить:
Допустим что установили Postgres и он по умолчанию создал каталог с базой данный в /var/lib/postgres/data.
Далее мы создали в нём базу ERP (пока пустую) её OID пусть будет 358924. Соответсвенно все данные этой базы будут у нас располагаться в каталоге /var/lib/postgres/data/base/358924

Заранее зная что база будет большой, админы выделили место под базу в каталоге /data, а место под wal в каталоге /wal_data
Опираясь на опыт переноса каталог pg_wal:
▫️Останавливаем postgres
▫️Переносим каталог var/lib/postgres/data/pg_wal в /wal_data/pg_wal
▫️Делаем symlink между этими каталогами

❗️Переносим каталог var/lib/postgres/data/base/358924 в /data/358924 (каталог нашей ERP)
▫️Делаем symlink между этими каталогами

Стартуем postgres - всё работает!!!

Казалось бы, что может пойти не так? 😁

Рассказываю:
Как правильные админы, после создания мастера мы делаем реплику
Утилитой pg_basebackup заливаем данные с мастера на реплику.

Стартуем реплику и тоже всё стартует и работает!!!
И даже когда мы начнём заливать в базу ERP данные - они послушно побегут на реплику, так как передаются посредством трансляции WAL.

Так мы счастливо работаем какое-то время и затем наступает момент когда нам потребовалось сделать резервную копию кластера с мастера:

❗️Мы запускаем pg_basebackup. она выполняется, вот только копия не содержит нашу базу ERP.
Поскольку база на мастере располагается в каталоге с символической ссылкой и вместо данных, утилита в бэкап кластера скопирует просто пустой каталог /358924.
❗️Тоже самое нас ждёт при попытке создать новую реплику.
Она создастся, но вот только без базы ERP.

Как же правильно вынести какую-то базу или несколько баз, а может и все сразу в другое место?

Для этого необходимо использовать Таблиные пространства (tablespace)
Т.е. в нашем сценарии мы должны были сначала создать табличное пространство

CREATE TABLESPACE erp_data LOCATION '/data'

а затем создать базу ERP уже в этом табличном пространстве

CREATE DATABASE ERP WITH OWNER = postgres ENCODING = 'UTF8' TABLESPACE = erp_data

Если же мы хотим чтобы все базы по умолчанию создавались в нужном нам каталоге, то есть 2 варианта:

1. Заново инициализировать кластер Postgres через Initdb указав в качестве расположения каталог /data
2. Переопределить табличное пространство по умолчанию в конфигурационном файле postgresql.conf переопределив параметр default_tablespace = '/data'

❗️Будьте очень осторожны с символическими ссылками не смотря на то, что это очень удобный и быстрый инструмент!

1️⃣🔤 Сколько реально сеансов можно запустить на одной пользовательской лицензии?

Согласно документации:
Вариант расходования лицензии - Лицензия получена клиентским приложением на локальном компьютере, Программная/Аппаратная - На компьютер

"Под термином «на компьютер» понимается следующее: если лицензия получена в варианте «на компьютер», то на компьютере, получившим лицензию, допускается запуск произвольного количества клиентских приложений, работающих с произвольным количеством информационных баз."

Для нас тут важно слово "произвольное".
Обычно это понимается как бесконечное, но на практике это не так.

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

Потом этот факт подтвердился на партнёрском форуме, у кого есть доступ, почитайте: https://partners.v8.1c.ru/forum/message/2241411

❗️Итак, в реальности ограничение равно 256 запускам приложений (Конфигуратор, Толстый клиент, Тонкий клиент).
Для некоторых сценариев это очень важное недокументированное ограничение.

1️⃣🔤 + 🔤🔤🔤 Когда реструктуризация 2.0 или перенос базы между СУБД через ibcmd replicate может завершиться с ошибкой при том что всё работает штатно?

Представьте, запустили вы реструктуризацию своей любимой 1С-ки через оптимизированный механизм реструктуризации 2.0 , всё идёт хорошо и вдруг получаем ошибку обрыва соединения, реструктуризация прерывается и достаточно сложно вернуть базу в начальное состояние без восстановления на резервную копию ДО реструктуризации (а резервные копии же у вас есть всегда!?).

Такая же ситуация может произойти и когда идёт репликация базы между СУБД с помощью утилиты ibcmd replicate...

Причём ошибка может звучать либо очень странно - что-то там про таймаут либо в случае ibcmd будет просто сообщение что репликация завершилась с ошибкой.

❗️Главная особенность именно этой ошибки, что она происходит по истечении более чем ДВУХ часов!

Что за волшебные 2 часа и что вообще происходит?

В операционных системах Windows и почти во всех Linux есть ограничение на ожидание последнего пакета, отправленного по сети.
По прошествии этого времени соединение помечается как требующее проверки, затем несколько раз проверяется и если проверки закончились неудачно. то оно разрывается.

А с чего это вдруг система решила что прошло уже 2 часа?
Это будет в том случае, если мы натолкнулись на создание огромного индекса .т.е. команду CREATE INDEX.
Эта команда вернёт обратно утилите своё состояние только по завершению создания индекса, т.е. это одна транзакция., а не несколько (единиц, десятков, сотен, тысяч и т.д.) как в случае когда мы заполняем таблицы данным при реструктуризации или репликации.

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

Для Linux:
▫️sysctl net.ipv4.tcp_keepalive_time узнаём какой сейчас стоит таймаут, обычно ответ будет 7200
▫️Если он меньше чем нам нужно, то устанавливаем новое значение в секундах, которое заведомо больше нашего времени создания индекса sysctl -w net.ipv4.tcp_keepalive_time=14400 в секундах!
▫️Если мы хотим установить этот параметр так чтобы он подтянулся и после перезагрузки, то нужно в файле /etc/sysctl.conf добавить строчку: net.ipv4.tcp_keepalive_time = 14400

Для Windows:
▫️В разделе реестра

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

создаём параметр DWORD с именем KeepAliveTime и значением 14400000 в миллисекундах!
▫️Перезагружаем систему

Какое время необходимо вам для создания индекса конечно нужно смотреть в логах СУБД заранее настроив их на сбор длительных запросов.

1️⃣🔤 Как сделать так, чтобы при добавлении http-сервиса даже в расширение не нужно было переопубликовывать базу на веб-сервере?

Большинство из нас привыкло, что при изменении состава публикуемых web или http сервисов нужно заново публиковать базу на веб-сервере чтобы новшества заработали.

При этом файл default.vrd выглядит очень большим и сложным:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    base="/buh"
    ib="Srvr=&quot;server1c:1541&quot;;Ref=&quot;buh&quot;;">
  <standardOdata enable="false"
      reuseSessions="autouse"
      sessionMaxAge="20"
      poolSize="10"
      poolTimeout="5"/>
  <ws>
    <point name="AccHRMDataTransfer"
        alias="AccHRMDataTransfer.1cws"
        enable="true"
        reuseSessions="dontuse"
        sessionMaxAge="20"
        poolSize="10"
        poolTimeout="5"/>
    <point name="EnterpriseDataExchange_1_0_1_1"
        alias="EnterpriseDataExchange_1_0_1_1.1cws"
        enable="true"
        reuseSessions="dontuse"
        sessionMaxAge="20"
        poolSize="10"
        poolTimeout="5"/>
    <point name="EnterpriseDataUpload_1_0_1_1"
        alias="EnterpriseDataUpload_1_0_1_1.1cws"
        enable="true"
        reuseSessions="dontuse"
        sessionMaxAge="20"
        poolSize="10"
        poolTimeout="5"/>
...

Но если внимательно прочитать ИТС, то можно обнаружить что для работы всех возможных сервисов публикации, в том числе и тех, которые в расширениях, достаточно сделать вот такой файл default.vrd:

<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    base="/buh"
    ib="Srvr=server1c:1541;Ref=buh;"
  <ws pointEnableCommon="true"
      publishExtensionsByDefault="true"/>
  <httpServices publishExtensionsByDefault="true"/>
  <standardOdata enable="true"
      reuseSessions="autouse"
      sessionMaxAge="20"
      poolSize="10"
      poolTimeout="5"/>
  <analytics enable="true"/>
</point>

❗️Помимо того что это просто красиво, такая настройка позволяет ничего не переопубликовывать при добавлении нового web или http-сервиса, всё сразу работает!

Так зачем же тогда Платформа 1С делает такую развёрнутую публикацию?
Ответ достаточно прост - чтобы была возможность что-то исключить из публикации, например какому-то одному или нескольким сервисам установить значение enable="false" либо наоборот, запретив всё разрешить только некоторые

  <httpServices publishByDefault="false"
      publishExtensionsByDefault="false">
    <service name="ПолучениеЗаказовПоAPI"
        rootUrl="Marketplace_API"
        enable="true"
        reuseSessions="autouse"
        sessionMaxAge="20"
        poolSize="10"
        poolTimeout="5"/>
  </httpServices>

1️⃣🔤 + 🔤🔤🔤 Запись не найдена в менеджере имён базы данных

Достаточно редкая, но очень "противная" и непонятная ошибка.
Что только не делают чтобы её убрать:
▫️Удаляют базу с кластера 1С и регистрируют заново.
▫️Добавляют базу в другой кластер 1С.
▫️Останавливают службу 1С с очисткой сеансовых данных.

Все эти способы почти никогда не помогают.

❗️Что было замечено?
▫️Эта ошибка практически в 100% случаев возникает только с базами PostgreSQL.
▫️Так же практически всегда она возникает после того как базу восстановили из дампа с помощью pg_restore.

Давайте разбираться в чём же проблема? Неужели виновата "православная" СУБД?

Проблема в том, что по умолчанию pg_restore НЕ УДАЛЯЕТ базу перед восстановлением в неё дампа.
Т.е. в восстановленной базе есть "ошмётки" от старой базы и новые данные из дампа.

Именно это и приводит к появлению ошибки "Запись не найдена в менеджере имён базы данных".

Почему ошибка не всегда и не у всех?
Потому что если вы восстанавливаете базу в её же "старый вариант", то возможно вам повезёт и платформа не обнаружит нарушений в своих системных данных и всё будет работать.

Как сделать так чтобы ошибка возникла с вероятностью 99%?
▫️На СУБД не должно быть нашей базы test.
▫️Добавить базу в кластере 1С с установленной галкой "Создать в случае отсутствия".
▫️Восстановить дамп в эту базу, причём дамп сливался с базы с названием отличным от test.

В отличии от PostgreSQL, MS SQL наоборот всегда УДАЛЯТ базу, СОЗДАЁТ заново пустую и в неё уже восстанавливает резервную копию - поэтому при использованию MS SQL этой ошибки и не возникает.

Как же правильно восстанавливать/обновлять существующую базу 1С на PostgreSQL?
❗️Вариант 1 (универсальный):
▫️Удалить базу с кластера 1С
▫️Удалить базу с СУБД PostgreSQL
▫️Создать пустую базу 1С на PostgreSQL скриптом (пример для PG 17):

CREATE DATABASE test
    WITH
    OWNER = postgres
    ENCODING = 'UTF8'
    LC_COLLATE = 'ru_RU.UTF-8'
    LC_CTYPE = 'ru_RU.UTF-8'
    ICU_LOCALE = 'ru-RU'
    LOCALE_PROVIDER = 'icu'
    TABLESPACE = pg_default
    CONNECTION LIMIT = -1
    IS_TEMPLATE = False;

▫️Восстановить дамп через pg_restore в базу test
▫️Добавить базу в кластер 1С

❗️Вариант 2:
▫️Удалить базу с кластера 1С
▫️Восстановить дамп через pg_restore в базу с тем названием, которое было у оригинальной базы с которой делался дам с параметрами --clean --create
▫️Добавить базу в кластер 1С

❗️Небольшая, но важная особенность:
С параметром --create база, заданная параметром -d, применяется только для подключения и выполнения начальных команд DROP DATABASE и CREATE DATABASE. Все данные восстанавливаются в базу данных, имя которой записано в архиве.

❗️Так же обратите внимание что во всех вариантах при восстановлении базы на уровне СУБД (не перезаливкой dt) необходимо удалять базу с кластера 1С и добавлять заново. Так как кластер 1С не в курсе что ему подсунули новую базу и вся система кэширования в итоге оказывается проблемой, а не помощником.
Эта особенность не зависит от того какую СУБД использовать PostgreSQL или MS SQL