Не запускается база 1с на postgresql
почему не запускается postgre - смотреть журналы событий, скорее всего - логин пароль юзера не походят для запуска или прав нет
почему запустилась 1С - какая разница, главное чтобы работало постоянно
ТС, в логи смотреть ни в коем случае не надо! просто переустанови!
(0) кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен. Как только sql появится - рестарт сервера 1с не понадобится.
(3) :)
База была нужна срочно, поэтому анализ логов проводился после. Запустить нужно было здесь и сейчас.
(4) ну значит в логах ничего не нашли или ничего не поняли, если все равно советуете переустановить?
Выхлоп и анализ логов привели к чему то?
(5) Хехе, там после этого проблемы с отключением питания продолжились, упал рейдконтроллер и клиент купил новый сервер)
Так что советую сразу покупать новый сервер!
(5) А если серьезно, то анализ логов дал понять, что накрывались жесткие диски в стойке, что и подтвердилось впоследствии.
"анализ логов"
Можно про это подробнее. хотя бы где искать эти логи?
" кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен"
ТАк база-то доступна и полноценно работает.
[При ошибках в логах транзакций сервер postgresql не запускается.
Т.е. их необходимо почистить т.е. сделать pg_resetxlog.]
Встречался с таким. При этом процессы postgre активны и работают с процом, но служба не стартует. Если оставить его в покое на некоторое время, запустится само. Время зависит от базы и производительности машины. На i7 это занимало минут двадцать, на дохленьком компе с копией той же базы - полдня.
Предполагаю, при аварийном отключении что-то в базах ломается (там же в памяти многое происходит) и он перед запуском службы восстанавливает базу.
(8) "system is starting up" - это он время от времени говорит, что пытается стартовать, чтобы не молчать
FATAL в этом случае лишь уровень, чтобы в лог упало при любых настройках логов
"system is ready to accept connections" - это стартанул
(8) > хотя бы где искать эти логи?
В том же каталоге, где лежит база, каталог pg_log (либо просто log в версии 10)
(10) > перед запуском службы восстанавливает базу
верно, при нормальной работе сначала падает на диск лог транзакций, а потом заменяются файлы таблиц. Если питание пропало после записи лога транзакций, но до записи таблиц - из WAL пытается восстановить правильное состояние базы.
Самая стрёмная ситуация - когда лог транзакций записался с ошибкой, что видимо и произошло. В таком случае (9) может помочь, но несколько последних документов/действий будет потеряно.
Алгоритм резервного копирования баз 1С: 8 средствами PostgreSQL.
Текстовые файлы, созданные pg_dump предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:
где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой , так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД)
PostgreSQL не восстанавливает текущую базу из дампа.
Поэтому, я восстанавливаю базу так:
dropdb имя_базы
createdb имя_базы
psql имя_базы < файл_дампа
Мой скрипт восстановления для Linux (работает под пользователем postgres):
if [ -z "$1" ] ; then
echo "Скрипт восстановления базы 1С. Параметры: 1 имя директории бэкапа, 2 имя базы 1С" 1>&2
exit
fi
dropdb $base_name
createdb $base_name
gunzip -c $archive_name | psql $base_name
У нас с восстановлением базы из дампа проблем вроде не вылезает, не ругается:
dropdb -U postgres [имя базы]
createdb -U postgres [имя базы]
pg_restore -U postgres -d [имя базы] [имя файла]
Для разграничения архивов по дням: namebase_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup
Если у пользователя установлен пароль: SET PGPASSWORD=123
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\ut11_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "ut11"
pg_dump — это программа для создания резервных копий базы данных Postgres Pro. Она создаёт целостные копии, даже если база параллельно используется. Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи).
Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных.
(14) Не вводите людей в заблуждение.
Не только можно, но и в большинстве случаев это единственный вариант. Например если база весит пару терабайт, работает 24/7/365 и каждый час простоя стоит N килобаксов.
А по поводу длительности операции - там снэпшот создается, так что итоговый бэкап получается вполне себе консистентным.
Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже.
(16), А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения? Вы считаете что все движения, связанные с проведением документа в 1С происходят в одной 1С транзакции?
А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?
Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.
Ага, не понял вас сразу. То есть фактически плюсом этого решения является то, что боевая база не тормозит в момент бэкапа? Но вот в плане надёжности такого решения я испытываю сильные сомнения. В момент обрыва связи между серверами postgre вероятность потерять данные не меньше чем при снепшоте. То что потом бэкап делается средствами 1С не панацея. Сталкивался я со случаями, когда бэкап из dt не разворачивался из-за сбойных данных внутри.
Добрый день,
Выполнял выше указанные скрипты. Дамп отрабатывает без ошибок, но при попытки сделать восстановление в пустую созданную БД отрабатывает не корректно с ошибками, база не запускается.
Так же создаю резервные копии как писали в коментах.
Но есть один вопрос. Иногда требуется срочно восстановить какую нибудь копию базы за определенный день. с командной строки я ее восстанавливаю в новую базу созданную посредством psql, но в 1ске то она не появиться надо вручную ее создать или с помощью 1с или через консоль администрирования 1с. А как через командную строку создать базу в 1с?
Хотелось бы рассказать про еще один "чудесный" способ передачи файла с дампом базы от облачного хостера 1С сервера. Возможно это сможет кому-то съэкономить часов 5 драгоценного времени, особенно для таких как я, которые за 15 лет работы с 1С - за ненадобностью postgre в глаза не видели, да и с линуксообразными тоже не особо.
Речь пойдет про Windows платформу, а именно server 2012.
Съезжая с хостинга клиент попросил отдать ему выгрузку базы 1С. В итоге со словами "Вот, могу отдать только SQL дамп. Но без СУБД вы все равно ничего не сможете сделать" - прилетает архив размером 700 мег формата bla_bla_bla_UT11.sql.gz
SQL дамп это прекрасно, подумал я, запуская SQL management studio.
Распаковав это хозяйство получил 1,5 гиг файл формата .sql
Попытки подпихнуть это в MS SQL успехом не увенчались.
Пришлось первый раз разбираться с postgre. Последняя на текущий момент версия была 10, но так как ей нужна была платформа не ниже 8.3.14 - была отправлена в корзину.
Поставил 9.6.7 с сайта 1С.
Ставится запуском postgresql-9.6.7-1.1C(x64).msi все параметры по умолчанию, предлагает указать некий пароль (даже не показывая к какому юзеру/уч.записи он относится), не менее 4х знаков, и после инсталляции запускает Stack Builder который предлагает поставить кучу какого-то не нужного барохла. Закрыл ничего не инсталлируя. pgAdmin 4 это адовая программа, которая открылась всего два раза. Сначала я создал там базу, выбрал в меню "восстановить из бекапа". Меня отправили прописывать какие то пути к скриптам. Что за (. ) - тебе же указали пути при установке! Но нет, надо что-то там в настройках указать. кое как нашел настройки. Попутно хочется добавить, что через 5 минут вглядывания в интерфейс этого . у меня стали болеть глаза. Я почувствовал себя пользователем Windows 3.11 , ни больше ни меньше. Заодно поменял языковую опцию на русский. Это, видимо, было ошибкой - после этого надо было рестартовать сервис, и больше pgAdmin-4 не запустился ни разу. Ну ничего, рядом в папке \bin валялась 3я версия этой чудесной программы. Она всё же согласилась работать, но архив мой открывать и грузить никак не хотела. Кнопка "Загрузить" так активной и не стала.
перерыл кучу всевозможной информации, нашел массу примеров скриптов, которые то запускают pg_restore то psql , причем принципиально понять почему одни используют одно, а другие другое - я никак не мог. Но у всех в примерах дампы были формата *.backup и с моим файлом это никак не хотело работать.
В итоге оказалось, что этот дамп - по сути текстовый набор sql инструкций, который создает таблички и постит туда данные. Некий набор запросов. Очень большой набор запросов.
В итоге строка запука восстановления стала выглядеть так:
система спрашивает пароль, и что бы я ей не указывал - не пускает. Пароль при инсталляции, пароль от системной учетной записи админа, пустой пароль - всё равно валит ошибку
Оказывается он пытается от имени текущей учетной записи windows что то сделать, и наличие у вас хоть прав администратора всея вселенная - его ничуть не смущают, вы всё равно идете лесом.
В итоге команда принимает следующий вид:
, где postgres это по сути SA.
И по экрану радостно побежали заголовки sql запросов. Заняло это минут 30.
Далее прописываем базу в консоле администрирования 1С, пользователь БД - postgres , пароль как раз тот что был при инсталляции.
Добавляем базу в список баз 1С.
И вот, к концу написания данного опуса - у меня на руках уже родимый .dt с которым уже чувствуешь себя хорошо. Работоспособность проверена.
user755340; Gendalf; scanner1980; DFinteX; leks88; eaa; addinaq; defini; goodwill; dimisa; acanta; + 11 – Ответить
При нарушении целостности файловой системы сервера баз данных PostgreSQL, последний выдает “Ошибка СУБД” 1С, и часто сопровождается текстом, типа “ERROR: invalid page header in block ХХХХХ of relation base/ХХХХХ/ХХХХХ”.
Причиной подобных исключений может служить разрушенная файловая система и нарушение логической целостности всей базы данных, произошедшие в результате некорректного завершения работы ОС.
Выводимую 1С “Ошибка СУБД” на самом деле надо начинать исправлять не в 1С, а с проверки файловой системы. Полный алгоритм восстановления будет приблизительно следующий:
- Исправление ошибок файловой системы;
- Выявление неисправных таблиц СУБД и их ремонт;
- Проверка и исправление ошибок на уровне 1С в конфигураторе.
Если “Ошибка СУБД” в 1С произошла после некорректного завершения работы ОС, начинаем с команд Chkdsk в Windows и fsck в Linux. Это позволит устранить ошибки на уровне файловой системы.
Затем надо выяснить в каких таблицах БД PostgreSQL возникает ошибка “ERROR: invalid page header in block…”. Для этого обращаемся к логам или пытаемся снять дамп базы данных, например подключившись к СУБД утилитой pgAdmin. Если возникает ошибка “Ошибка СУБД” в 1С, наверняка найдется хотя бы 1 испорченная таблица. В моем случае ошибка возникла при дампе public._enum332.
Для того, чтобы восстановить сломанную таблицу, выполним 3 запроса:
Далее снова пытаемся снять дамп базы данных, пока база не выгрузится без ошибок.
Следующим этапом исправления ошибки СУБД в 1С будет Тестирование и исправление базы в конфигураторе 1С. Для этого запускаем испорченную БД в конфигураторе. Через пункт Администрирование – Тестирование и исправление ИБ пробуем восстановить логическую целостность нашей базы. Обратите внимание, на галочки, выбранные на изображении.
При большом количестве ошибок СУБД, 1С потребуется помощь программиста или грамотного пользователя 1С помимо системного администратора, поэтому будьте готовы к привлечению подобных специалистов.
На этом процедуру исправления ошибки PostgreSQL “ERROR: invalid page header in block…” при работе с 1С можно считать законченной, однако стоит отметить несколько пунктов, которые позволят не допустить возникновение ошибки СУБД в 1С:
Ошибка 1С «Сервер баз данных не обнаружен»
При работе с 1С в клиент-серверном варианте могут возникать ошибки, которые напрямую не связаны с 1С:Предприятием, а связаны непосредственно с сервером управления баз данных.
Одна из распространенных ошибок — «Сервер баз данных не обнаружен…».
Далее рассмотрим подробнее каждую ошибку.
Could not translate host name «NAME» to address: Temporary failure in name resolution
Пример полного текста ошибки:
Описание:
Ошибка может возникать как при создании базы, так и при запуске информационной базы.
Решение:
Настроим DNS-адресацию или пропишем адреса в файл hosts. Обратите внимание, что в данном случае проблема в том, что на сервере 1С нет информации о доменном имени сервера СУБД PostgreSQL. Подробнее о DNS — Настройка DNS-адресации для 1С сервера.
ВАЖНО: пользователь «postgres» не прошёл проверку подлинности (Ident)
Пример полного текста ошибки:
Описание: Ошибка возникает при создании базы.
Решение:
Настроим проверку подлинности.
- Сконфигурируем доступ к серверу PostgreSQL в файле: pg_hba.conf:
Файл должен содержать только следующие строки (содержащие ip серверов 1С) (остальные удалим или пометим как комментарий):
Строк должно быть, соответственно, несколько, если серверов 1С несколько в кластере.
Последняя колонка указывает на метод авторизации.
Если пока теряетесь в настройках доступа. Для понимания, можно сначала открыть все, запустить сервер.
А после удачного старта сервера СУБД разбираться с настройками доступа.
ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template»
Пример полного текста ошибки:
Сервер баз данных не обнаружен ВАЖНО: в pg_hba.conf нет записи для компьютера «», пользователя «usr1cv8», базы «template».
Описание ошибки:
Ошибка связана с отсутствием прописанного доступа к базе данных в файле pg_hba.conf
Решение:
Добавим запись в файл pg_hba.conf.
Приведем пример содержания файла, который открывает доступ:
Строк должно быть, соответственно, несколько, если серверов 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С) его не «видит» по ряду причин:
— Отсутствие доступа;
— Обращение по другому адресу.
1. Первоначально, конечно, проверим, есть ли на сервере СУБД PostgreSQL в запущенных процессах процесс postmaster/postgres (в зависимости от версии PostgreSQL) на порту 5432.
Либо проверим все ли зависимости были установлены. И установим недостающие.
ERROR: type «tt7» already exists
Пример полного текста ошибки:
HINT : A relation has an associated type of the same name , so you must use a name that doesn ' t conflict .
Описание:
Данная ошибка является «плавающей» и может возникать в различных местах
Решение:
Выгрузим и загрузим базу данных средствами 1С:Предприятия(через файл *.dt).
ERROR: could not read block
Ошибка при выполнении операции с информационно базой по причине : Ошибка СУБД : ERROR : could not read block . . . in file "" Input / output error
Описание ошибки:
База не запускается. Разрушились диски.
Решения:
Переносим базу на другую дисковую систему.
Разворачиваем из резервной копии.
Пример полного текста ошибки:
Не удалось привязаться к адресу . Адрес уже используется . Возможно порт 5432 занят другим процессом postmaster ? Система БД выключена . Не удалось запустить сервер .
Описание:
Такая ситуация часто случается у начинающих администраторов в случае, если они хотят инициализировать сервер в каталог отличный от каталога по умолчанию. При этом сервер уже запустили из каталога по умолчанию.
В этой ситуации при попытке запуска видно ошибку – сервер не запускается.
А при проверке состояния видно, что сервер работает.
Если проверим запущенные процессы пользователя postgres, то можно увидеть, что порт 5432 занят кластером PostgreSQL, только запущенным из каталога по умолчанию.
Решение:
Остановим работающий кластер сервера СУБД.
/ opt / pgpro / ent - 10 / bin / pg_ctl -- locale = ru_RU . UTF - 8 - D / var / lib / pgpro / ent - 10 / data stop
Инициализируем кластер из нового каталога(если он не инициализирован).
Запустим из нового каталога.
Описание:
Длительный запуск, длительный захват объектов в хранилище, длительное сохранение конфигурации 1С:Предприятия.
Решение:
Такая проблема может быть связано с настройками СУБД PostgreSQL.
Рассчитаем настройки СУБД.
Описание настроек приведено на ИТС.
Выполним настройки, для этого перейдем в терминал psql:
Через psql установим параметры командой ALTER SYSTEM SET(параметры необходимо указать для вашей СУБД):
Описание ошибки:
При загрузке данных из файла *.xlsx в 1С отображаются иероглифы. Используемая СУБД PostgreSQL/PostgresPro.
Также возможна проблема с кодировкой в выгружаемом файле из 1С:
Решение:
На сервере СУБД проверим и выполним настройку локали.
1. Проверим наличие локали:
2. Проверим переменную:
Корректное значение результатов выполнения команд 2, 3:
3. Если результат не соответствует, выполним:
5. Выполним перезапуск серверов СУБД
Еще можно посмотреть
Установка PostgreSQL для 1С на Linux
Пошаговый процесс установки СУБД PostgreSQL для 1С на Linux сервер.
Установка двух версий сервера 1С на Linux
Пошаговый процесс установки и запуска двух версий сервера 1С на Linux. Полное описание настройки второго экземпляра сервера 1С.
Очистка кэша: серверного и клиентского для 1С:Предприятия
Лечим непонятные ошибки 1С Предприятия чисткой так называемого кеша - служебных файлов с настройками 1С
Администрирование серверов 1С на Linux
Привычным для нас инструментом управления кластером серверов 1С является консоль «Администрирование серверов 1С Предприятия» — «Microsoft Management Console». Данная консоль позволяет выполнять все необходимые действия по администрированию кластеров серверов 1С:Предприятия. Но, она имеет один недостаток – её невозможно использовать под ОС Linux. Но не все так плохо. Альтернативными средствами администрирования серверов 1С на Linux являются: […]
Установка сервера 1С Предприятие 8.3 на Linux
Пошаговый процесс установки 1С сервера на Linux. Подготовка Linux к установке. Инсталяция дистрибутива 1С сервера. Его настройка и запуск.
Ошибки сервера 1С на Linux
Описание типичных ошибок которые возникают при запуске службы сервера 1С на Linux и пути их исправления
Ошибки СУБД. 1С+PostgreSQL+Linux. Часть 1.
Читайте также: