Ошибка создания информационной базы сервер баз данных не обнаружен

Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 1.

Ошибка 1С «Сервер баз данных не обнаружен»

При работе с 1С в клиент-серверном варианте могут возникать ошибки, которые напрямую не связаны с 1С:Предприятием, а связаны непосредственно с сервером управления баз данных.

Одна из распространенных ошибок — «Сервер баз данных не обнаружен…».

Продолжение данного сообщения может быть различным:

1. 1. Could not translate host name «NAME» to address: Temporary failure in name resolution 2. ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident) 3. ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template» 4. Is the server running on host and accepting TCP/IP connections on port 5432? 5. «Породить новый процесс для соединения не удалось: Ресурс временно недоступен» или «ВАЖНО: извините, уже слишком много клиентов.» 6. FATAL: database «base» does not exist

Далее рассмотрим подробнее каждую ошибку.

Could not translate host name «NAME» to address: Temporary failure in name resolution

Пример полного текста ошибки:

6.7 Создание резервной копии и восстановление базы данных в MS SQL Server

Сервер баз данных не обнаружен
could not translate host name «NAME» to address : Temporary failure in name resolution

Описание: Ошибка может возникать как при создании базы, так и при запуске информационной базы. Решение: Настроим DNS-адресацию или пропишем адреса в файл hosts. Обратите внимание, что в данном случае проблема в том, что на сервере 1С нет информации о доменном имени сервера СУБД PostgreSQL. Подробнее о DNS — Настройка DNS-адресации для 1С сервера.

ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Сервер баз данных не обнаружен
ВАЖНО : пользователь «postgres» не прошёл проверку подлинности ( Ident )

Описание: Ошибка возникает при создании базы. Решение: Настроим проверку подлинности.

1. Сконфигурируем доступ к серверу PostgreSQL в файле: pg_hba.conf:

vim / var / lib / pgsql / 11 / data / pg_hba . conf
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all «Указать ip-адрес сервера 1С» md5
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all 0.0.0.0/0 trust
А после удачного старта сервера СУБД разбираться с настройками доступа.

ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»

Сервер баз данных не обнаружен ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template».

Описание ошибки: Ошибка связана с отсутствием прописанного доступа к базе данных в файле pg_hba.conf Решение: Добавим запись в файл pg_hba.conf. Приведем пример содержания файла, который открывает доступ:

Как найти и запустить экземпляр SQL Server

# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all «Указать ip-адрес сервера 1С» md5
Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.

Is the server running on host and accepting TCP/IP connections on port 5432?

Сервер баз данных не обнаружен could not connect to server : No rout to host Is the server running on host and accepting TCP / IP connections on port 5432 ?

Описание: Проблема может возникать как при создании информационной базы из консоли администрирования 1С: Предприятия, так и при ее запуске в процессе эксплуатации уже существующей базы данных. Решение:

В данном случае необходимо понимать, что рабочего процесса: Либо нет; Либо клиент(в нашем случае сервер 1С) его не «видит» по ряду причин: — Отсутствие доступа; — Обращение по другому адресу.

Источник: 1s-on.ru

Записки IT специалиста

Типовые ошибки установки сервера 1С:Предприятие и PostgreSQL на платформе Linux.

Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Общая информация

Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:

В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:

В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУБД. Никаких запросов от клиента к серверу управления базами данных не происходит.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)

Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:

host all all 192.168.31.0/24 ident

и приведите ее к виду:

host all all 192.168.31.0/24 md5

где 192.168.31.0/24 — диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.

Сервер баз данных не обнаружен
could not translate host name «NAME» to address: Temporary failure in name resolution

На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файл hosts на клиенте, что не дает никакого результата.

А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows.

Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.

Ошибка при выполнении операции с информационной базой
server_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.

Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:WindowsSystem32driversetchosts на платформе Windows запись вида:

192.168.31.83 SRV-1C-1204

где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.

Ошибка СУБД: DATABASE не пригоден для использования

Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.

Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.

Ошибка СУБД:
ERROR: could not load library «/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so»

Ошибка СУБД
ERROR: type «mvarchar» does not exist at character 31

Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия

или через средство запуска 1С.

Сервер баз данных не обнаружен
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (по паролю)

Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.

Сервер баз данных не обнаружен
FATAL: database «NAME» does not exist

Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД — две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Источник: interface31.ru

Как заставить Сервер 1С увидеть в сети сервер PostgreSQL ?

Как заставить Сервер 1С (что работает на Windows), увидеть в сети сервер PostgreSQL на Linux UBUNTU?

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Собственно решить такие проблемы как:

• «Ошибка создания информационной базы»
• «Ошибка операции администрирования»
• «Сервер баз данных не обнаружен»
• «Could not connect to server: Connection refused (Ox..00000/0000…)
• Is the server running on host 192.168….x… and accepting TCP/IP connections on port 5432?»

При установке на один физический сервер, «Cервера 1С» (кластер серверов) + СУБД PostgreSQL проблем обычно не возникает. И «Сервер 1С» прекрасно видит PostgreSQL, новые информационные базы создаются, и все работает по умолчанию, конечно если поставили птичку во время установки СУБД на Windows — «Разрешать подключения с любых IP адресов».

Но совсем другая история, когда PostgreSQL у нас работает на Linux!

Ведь в процессе установки PostgreSQL на Linux подобных «птичек» нет )

Как решить проблему?

На самом деле все довольно просто!

Проверим в начале c какого IP принимаются подключения, и какой порт слушает сервис PostgreSQL.

Тут нам поможет команда:

sudo netstat — pant | grep postgres

На картинке ниже, мы четко видим, что наш PostgreSQL слушает только localhost — 127.0.0.1 и порт по умолчанию 5432.

Выражаясь простым языком, «Сервер 1С» может работать в паре с СУБД, только на этом севере (хосте), при текущих настройках (По умолчанию, после установки «Постгреса» на этот сервер).

И так, теперь разобравшись, что проблема действительно есть в настройках PostgreSQL, можно приступить к ее решению!

Сперва нам нужно найти конфигурационный файл postgresql.conf

Местоположение этого файла зависит от версии СУБД PostgreSQL (На примере использую сборку от компании Postgres Professional — PostgreSQL 10.5, сборку установил на UBUNTU server 18.04 LTS).

Найти файл очень просто, используем команду:

ps aux | grep postgres | grep — — D

Нас интересует все что мы видим после -D /var/lib/pgpro/1c-10/data/

Здесь в каталоге /data/ и лежит наш файл postgresql.conf

Идем в этот каталог, откроем для редактирования postgresql.conf, и внесем нужные правки.

Для передвижения по каталогам и редактированию файлов на UBUNTU server 18.04, я использую MC (Midnight Commander).

(Выбрав файл postgresql.conf) далее давим клавишу F4:

Ищем строку #listen_addresses = ‘localhost’.

Раскомментируем строку (убрав #).

И приведем строку к виду: listen_addresses = ‘*’

Давим F2 + Enter и сохраняем файл.

Далее выполним перезапуск сервиса postgresql:

service postgrespro -1c-10 stop

service postgrespro -1c-10 start

(Команда перезапуска у Вас будет отличатся, если версия PostgreSQL другая или другой сборки).

Затем стоит проверить работает ли PostgreSQL:

service postgrespro -1c-10 status

И если видим (как на картинке ниже) зеленым цветом active (running) значит PostgreSQL работает!

Смотрим, что теперь «слушает» PostgreSQL:

sudo netstat — pant | grep postgres

Отлично!

После перезапуска сервиса, PostgreSQL принимает подключения действительно с любых IP адресов на стандартный порт 5432!

Но! не спешите сейчас бежать на Сервер 1С, создавать новую информационную базу, или выполнять подключение.

Сервер 1С встретит Вас новой ошибкой! )

«ВАЖНО: в pg_hba.conf нет записи для компьютера «192.168.128.13», пользователя «postgres», базы «template1″, SSl выкл.»

Сервер 1С требует от нас создать еще одну запись, уже в другом файле pg_hba.conf

«Надо, так надо )»

Открываем для редактирования файл pg_hba.conf, он к слову находится в том же каталоге, что и файл postgresql.conf

Ищем строку: host all all 127.0.0.1/32 md5

И приводим к виду: host all all 192.168.128.13/24 md5

Где 192.168.128.13 ip адрес нашего Сервера 1С. (Тот сервер, где работает Сервер 1С).

Кстати! можно поступить и по-другому.

Просто добавить в строке ниже еще одну запись (Ту которую от нас и требует Сервер 1С):

Вот и все!

Сохраним файл и выполним перезапуск PostgreSQL.

Теперь новая информационная база 1С, будет создана успешно!

Сервер 1С работает на Windows, а PostgreSQL на Linux!

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Похожие записи

Источник: kuharbogdan.com

Сервер баз данных не обнаружен. (пароль пользователя postgres)

Картина выглядит так.
Есть база 1С 8.1 с которой пропал коннект.
При обращении клиента получаем сообщение:

Сервер баз данных не обнаружен
FATAL password authentication failed for user «postgres»

СУБД PostgreSQL.
Из pgAdmin III базу видно.
Владелец базы: postgres пользователь, скорее всего тоже postgres.

Я, как совершенный чайник в этом предмете делаю предположения: если базу видно из админки СУБД, значит
с ней все в порядке, нужно только в консоли управления серверами сбросить (или сменить) слетевший пароль для пользователя postgres. Пароль админа кластера уволился вместе с админом кластера, но это дело решаемое.
Поправлю srvribrg.lst, но для этого мне придется останавливать агент клиента.
Предприятие работает круглосуточно и непрерывно, и в количестве попыток «попробовать» я сильно ограничен.
по этому осторожничаю.

Так вот, правильно ли я мыслю насчет этой проблемы?
И какие здесь могут быть варианты?

Добавлено через 54 минуты
Только что переделал srvribrg.lst, получил доступ к консоли администрирования кластера.
Когда сбрасываю или меняю пароль пользователя базы в «свойствах» — получаю тот же отлуп, только уже от консоли.
Ошибка изменения базы, ошибка соединения и дальше —

Сервер баз данных не обнаружен
FATAL password authentication failed for user «postgres»
Значит искал не там.

Теперь актуальным остался вопрос про «еще варианты»
Спасибо

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

Сервер баз данных не обнаружен
Здравствуйте уважаемые. Подскажите Пожалуйста. Имеется физический сервер win2012 r2(64) на нем.

Технология создания приложений на основе многоуревневой архитектуры клиент — Web-сервер — сервер баз данных
Технология создания приложений на основе многоуревневой архитектуры клиент Web-сервер – сервер.

Куда вписать пароль от баз данных
Установил CMS, после чего поменялись пароли, теперь когда я закидываю файлы сайта назад в doc у.

Список баз данных пользователя
Подскажите пожалуйста как можно получить список баз данных созданных пользователем?

206 / 180 / 31
Регистрация: 24.10.2011
Сообщений: 737
А позвонить админу и спросить пароль никак?
Регистрация: 16.10.2009
Сообщений: 112
А позвонить админу и спросить пароль никак?
Во-первых, никак.
Во-вторых, админский доступ к кластеру я уже сделал.
2954 / 1766 / 82
Регистрация: 03.11.2011
Сообщений: 8,280
создайте новую запись в списке баз
Регистрация: 16.10.2009
Сообщений: 112
создайте новую запись в списке баз

1.В консоли или в pgAdmin? Или везде?
2. «Создать» — штатным образом, сервер — кластеры — ***(кластер) — информационный базы — «создать»?

Добавлено через 11 минут
Собсно, ничего не вышло. В pgAdmin III можно создать все что угодно,
в консоли кластера — нет. Выходит то же, что и при попытке смены пароля пользователя существующей базы.

FATAL password authentication failed for user «.

2954 / 1766 / 82
Регистрация: 03.11.2011
Сообщений: 8,280

просто на клиенте в списке добавить серверную базу и линковаться к существующей. Не получится — ещё одну с другими логинами. и так пока не получится

Регистрация: 16.10.2009
Сообщений: 112

просто на клиенте в списке добавить серверную базу и линковаться к существующей. Не получится — ещё одну с другими логинами. и так пока не получится

Мне кажется мы о разном говорим.
В списке баз на клиенте какие логины?
Там только адрес кластера и имя базы.
Если есть соответствующая база в кластере серверов — будет обращение. После чего сервер начнет подцеплять СУБД и произойдет это только если пользователь базы (а он у нас — postgres) будет аутентифицирован. Чего никак не происходит по причине слёта пароля. Тогда сервер сообщает, что база не обнаружена. Несмотря на то, что база-то как раз существует.

Просто пользователь базы и пользователь 1С в нашем контексте — разные вещи.

206 / 180 / 31
Регистрация: 24.10.2011
Сообщений: 737

Единственный способ это пересадить базу на контролируемы тобой сервер, доступ к базе без пароля админа сервера ты не получишь, хоть все файлы конфига переправь, пароль админа как и в скуле пос будет хранить в зашифрованном виде в системной базе.

Во-первых, никак.
Помер что ли?
Регистрация: 16.10.2009
Сообщений: 112

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

Так. Здесь поподробнее если можно.
Я всё это в своих картинках представлю ибо чайник.
Во первых, что я уже проделывал:
-доступ к базе и в pgAdmin и в консоли у меня теперь есть. Базы я вижу, но изменить ничего не могу без того же пароля пользователя postgres. А чтобы с базой чего-то делать, админом кластера быть мало оказывается.
-из-под pgAdmin выгрузил в файл резервную копию нужной базы.
-создавал новую базу в СУБД с новым владельцем и новой ролью входа (пользователем), мною же созданным; настраивал 1С прописывал в консоли. Все очень хорошо коннектится. Появляется шикарная возможность работать в лысой базе поскольку загрузить туда нечего и неоткуда.
-в pgAdmin попытался сделать восстановление из выгруженной копии в созданную базу. Естественно такой тупой фокус не прошел — параметры разные.

Таким образом:
— «Пересадить базу» — в чем это должно заключаться?
Выгрузить ее детским способом через, конфигуратор чтобы потом разместить где-нибудь файлово я, понятно, не могу, поскольку она недоступна. Другие решения в голову пока не приходят по скудости опыта.
Теоретически, должна же быть возможность прямо на сервере, допустим под root-ом отредактировать какой-нибудь конфиг, удалить или поменять пароль для юзера postgres. Если пароль где-то хранится- значит его можно оттуда удалить. Тогда следующая проблема. Можно пролететь с аутентификацией по пустому паролю.

В общем, если не сложно, что ты подразумеваешь под «пересадить базу»?

Источник: www.cyberforum.ru