Postgresql важно файлы базы данных не совместимы с сервером

Обновлено: 25.11.2022

Дано: Кластеры PostgreSQL 9.6.7-1.1C и 1С, где "9.6.7-1.1C" - это версия установленного старого кластера, а "10.5-24.1C" - это версия нового кластера.

Задача: обновить 9.6.7-1.1C до 10.5-24.1C.

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

1. Для тех, кому время не критично или базы не много весят, рекомендую сделать копии всех баз через конфигуратор 1С.

2. Копируем файлы настроек доступа к хосту pg_hba.conf и настроек кластер postgresql.conf из C:\Program Files\PostgreSQL\9.6.7-1.1C\data в любое место, в нашем случае в D:\temp. Файлы нам понадобятся для внесения изменений в новые файлы настроек от 10.5-24.1C, если таковые у вас есть.

3. Заходим в cmd под администратором и вводим
C:\Program Files\PostgreSQL\9.6.7-1.1C\bin\pg_dumpall -U postgres > D:\temp\db.out

Где db.out - файл дампа всего кластера (всех баз). Во время процесса будет запрошен пароль от пользователя PostgreSQL postgres, который вы вводили при установке 9.6.7-1.1C.

Полученный файл будет сжат. Если у вас совсем мало места, тогда можно через команду | и gzip или 7zip заархивировать файл D:\temp\db.out.

Рассмотрим 3 варианта обновления кластера

I вариант через pg_dumpall и psql

4. Останавливаем службы сервера 1С и службу от 9.6.7-1.1C

5. Устанавливаем 10.5-24.1C (установка по умолчанию в каталог 10.5-24.1C), пароль postgres оставляем прежним для удобства. Если установка происходит на тот же самый порт, то нет необходимости менять правила брендмауэра Windows. Я заведомо не деинсталирую 9.6.7-1.1C и не удаляю файлы баз PostgreSQL, т.к. я могу в любой момент вернуться к старому кластеру и запустить его без проблем.

Для кого-то критично место на диске, тогда следует на данном этапе деинсталировать кластер 9.6.7-1.1C и удалить файлы баз.

6. Файлы настроек из п. 2 мы сравниваем с аналогичными файлами из в C:\Program Files\PostgreSQL\10.5-24.1C\data и переносим необходимые изменения в новый файл. Не забываем сделать копию изначальных файлов 10.5-24.1C. Если у вас не было изменений в файлах 9.6.7-1.1C, то этот пункт делать не нужно.

7. Перезапускаем службу 10.5-24.1C, для применения новых настроек конфигурационных файлов.

8. Заходим cmd под администратором и проходим в
C:\Program Files\PostgreSQL\10.5-24.1C\bin\psql -U postgres -f D:\temp\db.out

Для минимизации времени отключения кластера можно сделать следующим образом:

- в п.5, устанавливая 10.5-24.1C мы ставим новый порт 5433 и службы кластеров должны быть запущены

- далее в cmd запускаем:

C:\Program Files\PostgreSQL\9.6.7-1.1C\bin\pg_dumpall -U postgres -p 5432 > D:\temp\db.out |

C:\Program Files\PostgreSQL\10.5-24.1C\bin\psql -U postgres -p 5433 -f D:\temp\db.out

Возможно, придется настроить брендмауэр для порта 5433

Во время процесса восстановления периодически нужно вводить пароль от пользователя postgres.

11. Стартуем службу сервера 1С.

10. После восстановления необходимо сделать переиндексацию в конфигураторе 1С или с помощью команды reindex database или с помощью PGAdmin 4.

Если у вас не работает PGAdmin 4, одно из решений, установить его отдельно с сайта разработчика

После перезапуска MacBook Pro я не могу запустить сервер базы данных:

Я проверил журналы, и снова и снова появляется следующая строка:

9.0.4 была версией, которая была предустановлена ​​на Mac, 9.2 [.4] - это версия, которую я установил через Homebrew. Как уже упоминалось, раньше это работало до перезапуска, поэтому на самом деле это не может быть проблемой компиляции. Я также повторно запустил initdb /usr/local/var/postgres -E utf8 , но файл все еще существует.

К сожалению, я новичок в Postgres, поэтому буду очень признателен за любую помощь.

Если вы недавно обновились до 11 или 12 с 10.x , вы можете выполнить следующую команду, чтобы обновить каталог данных postgres, сохранив все данные:

Приведенная выше команда взята из вывода brew info postgres

Мне работает эта команда:

Затем запустил Postgres:

Вы также можете проверить, прослушивается ли порт 5432 :

Причиной этого стал устаревший файл postmaster.pid .

Просто перейдите в свой каталог postgres /Users/st/Library/Application Support/Postgres/ , для меня это:

Затем удалите файл postmaster.pid . Перезапустите postgres, и все заработает.

Это случилось со мной, когда я пытался запустить Postgres12 с установленным томом postgres11. Просто удаление смонтированного тома для postgres11 и перезапуск сработали для меня.

Раньше я использовал:

Я удалил / Users / champ / postgres и перезапустил postgres 12, используя

Подобно этим ответам (1, 2), мои файлы базы данных Postgres были несовместимы с моей версией Postgres после обновления до postgresql 13.3 .

К сожалению, обновить мой каталог данных Postgres не удалось.

Я решил переустановить postgresql 12.7 .

brew info postgres подскажет, как To migrate existing data from a previous major version of PostgreSQL run:

Итак, в моем случае удаление старого rm -rf /usr/local/var/postgres.old и обновление БД brew postgresql-upgrade-database

Если вы хотите сохранить предыдущую версию postgres, используйте brew switch :

В противном случае рассмотрите эту команду brew для переноса существующих данных: brew postgresql-upgrade-database . Ознакомьтесь с исходным кодом .

Я нашел это решение в Интернете.

Когда я попытался запустить сервер postgresql после обновления до OS X 10.10 Yosemite, я столкнулся со следующей проблемой:

pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start

Хорошо, давайте заглянем в логи сервера:

Итак, нам нужно выполнить несколько шагов после обновления postgresql:

У меня это сработало отлично. В конце концов, он также генерирует вам 2 сценария bash для проверки вашей БД и удаления старого кластера. Действительно удивительным.

Если вы ищете ядерный вариант (удалите все данные и получите новую базу данных), вы можете:

rm -rf /usr/local/var/postgres && initdb /usr/local/var/postgres -E utf8

А затем вам нужно будет rake db:setup и rake db:migrate из вашего приложения Rails, чтобы снова начать настройку.

Я использовал sudo netstat -nlp | grep 5432 , чтобы увидеть статус, но ничего не показалось. И я поискал в Интернете, кто-то сказал мне изменить pg_hba.conf , но я не могу locate этот файл. И я тоже пробовал эту команду sudo ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432 . Не может работать.

Шаг 2: перезапустите pg_ctlcluster

Шаг 5. Убедитесь, что пользователь postgres принадлежит к группе пользователей ssl-cert.

У меня была такая же проблема с Devuan ascii (может быть, и с Debian?). Файл конфигурации /etc/postgresql/9.6/main/postgresql.conf содержит директиву unix_socket_directories , которая по умолчанию указывает на /var/run/postgresql . Изменение его на /tmp , куда большинство клиентов смотрят по умолчанию, исправило это для меня.


Для перехода PostgreSQL с версии 9 на версию 10 недостаточно установить новые пакеты и подсунуть имеющийся каталог данных кластера.

При обновлении основных версий Postgres Pro внутренний формат данных может меняться, что усложняет процедуру обновления. Традиционный способ переноса данных в новую основную версию — выгрузить данные из старой версии, а затем загрузить их в новую (это не самый быстрый вариант). Выполнить обновление быстрее позволяет pg_upgrade. Также для обновления можно использовать репликацию.

В связи с тем, что у PostgresPro изменились правила лицензирования, и для свободного использования доступна лишь версия Postgres Pro Standard “для тестирования, разработки ПО, ознакомления с функциональностью СУБД, использования в образовательном процессе”, и для коммерческих целей ее использовать низя.

Поэтому планируется устанавливать уже готовые “пропатченные” пакеты, собранные самим 1С, и использовать pg_upgrade не будем.

Один из вариантов обновления заключается в выгрузке данных из одной основной версии Postgres Pro и загрузке их в другую — для этого необходимо использовать средство логического копирования, например pg_dumpall ; копирование на уровне файловой системы не подходит. В самом сервере есть проверки, которые не дадут использовать каталог данных от несовместимой версии Postgres Pro, так что если попытаться запустить с существующим каталогом данных неправильную версию сервера, никакого вреда не будет.

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

[38003] ВАЖНО: файлы базы данных не совместимы с сервером
[38003] ПОДРОБНОСТИ: Каталог данных инициализирован сервером PostgreSQL версии 9.6, не совместимой с данной версией (10.9 (Ubuntu 10.9-5.1C)).

Шаг 3. Если служба запущена, но вы не видите сокет

Если вы не можете найти сокет, но видите, что служба запущена, убедитесь, что в файле pg_hba.conf разрешены локальные сокеты.

Перейдите к datadir , и вы должны найти файл pg_hba.conf .

По умолчанию в нижней части файла вы должны увидеть следующие строки:

Если вы его не видите, вы можете изменить файл и перезапустить службу postgres.

В моем случае я увидел эту ошибку, и postgres не запущен.

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

Решением было создать папку /etc/postgres//main

А затем создайте кластер с помощью:

После этого, просто перезапустив службу postgresql, все должно работать.

У меня возникла эта проблема при работе с PostgreSQL в Ubuntu 18.04.

Я проверил свой статус PostgreSQL и понял, что он работает нормально, используя:

Я также попытался перезапустить сервер PotgreSQL на машине, используя:

Но проблема не исчезла:

После ответа Noushad я сделал следующее :

Перечислите все кластеры Postgres, запущенные на вашем устройстве:

Это дало мне этот вывод красного цвета, показывая, что все они не работают, а статус также показывает не работает :

Перезапустите pg_ctlcluster для одного из кластеров серверов. Для меня я перезапустил PG 10 :

Однако он вызвал ошибку ниже, и та же ошибка возникла, когда я попытался перезапустить другие кластеры PG:

Проверьте журнал на наличие ошибок, в данном случае мой - PG 10 :

Я увидел следующую ошибку:

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

Я исправил это, выполнив команду ниже. Я выполнил команду для 3 кластеров PG на своей машине:

После чего я перезапустил каждый из кластеров PG:

И вот, наконец, я снова проверил работоспособность кластеров:

На этот раз все снова было хорошо, так как статус показал онлайн :

Надеюсь, это поможет

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

Оказывается, всякий раз, когда вы используете синтаксис ALTER SYSTEM SET . , PostgreSQL записывает в файл с именем postgresql.auto.conf . Этот файл читается в дополнение к обычным файлам postgresql.conf и pg_hba.conf . В моем дистрибутиве Ubuntu (18.04) они находятся в разных папках (!):
- pg_hba.conf и postgresql.conf оба находятся в /etc/postgresql/12/main
- Автоматически созданный файл: /var/lib/postgresql/12/main/postgresql.auto.conf

Я пытался изменить конфигурацию с помощью ALTER SYSTEM SET listen_addresses = , но допустил ошибку, в результате чего возникла некорректная конфигурация «призрак», которую я не смог найти. Как только я стер оскорбительную строку в postgresql.auto.conf , он все исправил.

Я мог бы решить эту проблему, установив правильные разрешения для datadir. Так должно быть

Убедитесь, что Postgres работает, используя:

Проверьте каталог данных и postgresql.conf .

В моем случае каталог данных в -D отличался от каталога в postgresql.conf

Итак, я изменил каталог данных в postgresql.conf , и это сработало.

У меня была аналогичная проблема, и проблема была в файле конфигурации pg_hba.conf. Ранее я внес некоторые изменения, из-за которых сервер отказывался от ошибок при попытке его запуска. Комментирование лишних дополнений решило проблему.

У меня такая же проблема. Вроде нет сокета, когда нет кластера.

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

Это может вызвать что угодно, например, моя проблема была вызвана опечаткой в ​​файлах конфигурации. Некоторые люди говорят, что это вызвано файлами сертификатов, другая группа считает, что причиной этого являются несогласованные местные жители.

Если вы не можете найти решение своей проблемы, удалите postgres и переустановите его. Это лучшее решение.

Во время новой установки postgresql. По умолчанию имя пользователя и пароль назначаются как «postgres». Эта СУБД предоставляет возможность добавить роль для нового пользователя и создать базу данных. Если вы получаете такие ошибки:

логин по умолчанию логин:

ype psql для интерактивной подсказки

postgres @ kalilinux: ~ $ psql

Чтобы выйти из режима быстрого использования

Чтобы создать новую роль пользователя

postgres @ kalilinux: ~ $ createuser --interactive

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

Итак, для меня и моих друзей, работающих над приложением Node.js (с Postgres и Sequelize), нам пришлось

brew services start postgresql **** (используйте Homebrew для запуска postgres)

Просто хочу сделать небольшое дополнение: если ваш экземпляр жалуется на сокет, вы также можете проверить unix_socket_directories в файле /data/postgresql.conf , который мог быть установлен в /tmp , например, если вы использовали сторонний дистрибутив. Вы можете изменить его на /var/run/postgresql и перезапустить службу. Для этого также может потребоваться создать каталог postgresql в /var/run и subsys/postgresql-9.6 в /var/lock , если они еще не существуют (работало для меня с postgresql 9.6).

Ошибка означает, что сервер Postgres не запущен. Попробуйте запустить его:

Убедитесь, что сервер запускается при загрузке:

Краткое руководство по debian для удаленного доступа к базе данных postgres на сервере из клиента psql: (измененная конфигурация документирована в файлах):

sudo /etc/init.d/postgresql restart изменения вступают в силу

войдите со стороны клиента с помощью psql --host=ipofserver --port=5432 --username=remoteuser --password --dbname=mydb

Я решил эту проблему, проверив свою файловую систему, диск был полностью заполнен, поэтому база данных не запускалась

Подключения к сокету домена Unix "/var/run/postgresql/.s.PGSQL.5432" ?

Я пробовал несколько способов устранения неполадок, пока не проверил использование своего диска и не обнаружил, что он заполнен, используется 100%,

Решено! Хотя я не знаю, что случилось, но я просто удалил все и переустановил. Это команда, которую я использовал, чтобы удалить sudo apt-get --purge remove postgresql\* и dpkg -l | grep postgres . Последний - найти все пакеты, если он не чистый.

Я столкнулся с той же проблемой и

Это сработало для меня.

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

Я был полон решимости получить настоящее исправление сегодня. Перезапуск PostgreSQL разрешил это на ubuntu. sudo /etc/init.d/postgresql restart

Если при запуске службы Postgres ошибок нет, выполните следующие действия.

2. Создание резервной копии данных

Для создания копии рекомендуется применять программы pg_dump и pg_dumpall от новой версии Postgres Pro , чтобы воспользоваться улучшенными функциями, которые могли в них появиться. Хотя этот совет может показаться абсурдным, ведь новая версия ещё не установлена, ему стоит последовать, если вы планируете установить новую версию рядом со старой. В этом случае вы сможете выполнить установку как обычно, а перенести данные позже. Это также сократит время обновления.

привет коллеги
после обновления с 8.3.16 до 8.3.18.1128 c базами на postgrespro 12.1 получил "Ошибка СУБД: DATABASE не пригоден для использования.", в логах постгреса пусто.
проверил работу 8.3.18 с базами на postgres9.6 все работает.
Откатился до 8.3.16 и с postgrespro 12.1 все заработало.

пока собираем стенд для поиска решения, если кто знает как решить, буду очень признателен

PostgreSQL 12.5
PostgreSQL 12.4
PostgreSQL 12.3
PostgreSQL 11.10
PostgreSQL 11.9
PostgreSQL 11.8
PostgreSQL 11.7
PostgreSQL 11.5

Если при попытки создать баз данных 1С на PostgreSQL
появляется ошибка: DATABASE не пригоден для использования

В файле настроек сервера (в windows он находится********\postgresql.conf)
разкомментируем и отредактируем следующие строки:

backslash_quote = on
escape_string_warning = off
standart_conforming_strings = off

Перезапускаем конфигурацию, должно работать.

(3)
а вы чистую базу создавали ?
1.средствами 1с
2.постгресом

в общем решение найдено и если кратно, то установка 12.4.1 поверх 12.1 решила проблему и проверено 8.3.16 и 8.3.18 работают с 12.4.1
интересно что
- 8.3.16 + 12.1 работает
- 8.3.18 + 12.1 НЕ работает
- 8.3.18 + 12.4.1 после обновлением работает
- 8.3.18 + с той же базой после обновления с откатом субд до 12.1 РАБОТАЕТ!, но при этом вновь создаваемые базы не работают.
вероятно изменения касаются самой структуры таблиц база данных
еще немного потестируем и будем планировать обновление рабочего сервера

(6)Это не решение, а удачное стечение обстоятельств.
Данная ошибка может возникать, если поставили постргес на нестандартном порту.
Для подключения к базе или при создании новой базы надо писать в имени сервера конструкцию типа такой:
localhost port=5433

(7) хммм не соглашусь, проблема повторилась еще несколько раз, и каждый раз этот подходи привел к ее решению, а значит это вполне себе решение )

darkultro37: Не совсем по теме, но решение использовать 8.3.18 принципиально? Первый релиз в новой ветке всегда был сыроватым.

Шаг 1. Запуск pg_lsclusters отобразит список всех кластеров Postgres, работающих на вашем устройстве.

Скорее всего, в вашем случае статус будет понижен. Если нет, перезапустите службу PostgreSQL

Шаг 1. Убедитесь, что база данных работает

Команда может отличаться в зависимости от вашей операционной системы. Но в большинстве систем * ix будет работать следующее: он будет искать postgres среди всех запущенных процессов

В моей системе Mac OSX это выплевывает

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

Вы можете просмотреть все варианты, доступные для запуска сервера postgres, используя следующее.

Оттуда вы увидите, что варианты -D и -r - это соответственно datadir и logfilename .

Шаг 4: проверьте право собственности на postgres

Убедитесь, что postgres является владельцем /var/lib/postgresql/version_no/main например: sudo chown postgres -R /var/lib/postgresql/9.6/main/

22 ответа

Шаг 3. Шаг 2 завершился неудачно, и возникла ошибка

Если перезапуск pg_lsclusters не был успешным, он выдаст ошибку. Моя ошибка была (вы можете увидеть ошибки в журналах /var/log/postgresql/postgresql-9.6-main.log )

Шаг 2. Если служба postgres запущена

Используйте find для поиска местоположения сокета, который должен быть где-нибудь в /tmp

Если postgres запущен и принимает подключения к сокету, приведенное выше должно сообщить вам местоположение сокета. На моей машине это оказалось:

Затем попробуйте подключиться через psql, явно указав расположение этого файла, например.

Читайте также: