Не запускается postgresql windows после аварийного завершения

Инцидент: в ситуации, когда сервер был выключен аварийно, через кнопку выключения или при отсутствии электропитания, то после его включения служба PostgreSQL в некоторых случаях не запускается.

Для версий PostgreSQL:

  • 9.X
  • 11.X

Некорретное завершение работы службы

Как исправить:

1. Запустите сеанс командной строки от Администратора.

2. Выполните последовательно следующие команды и внимательно следите за их работой.

3. Определить домашний каталог PostgreSQL.

set PGDATA=%SET_POSTGRES_BIN%/../data/

4. Проверьте реальный статус экземпляра службы PostgreSQL.

%SET_POSTGRES_BIN%/pg_ctl.exe status

5. Выполните команду для полной остановки процесса PostgreSQL.

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

%SET_POSTGRES_BIN%/pg_ctl.exe stop -m fast

6. Запустите приложение СУБД.

%SET_POSTGRES_BIN%/pg_ctl.exe start

7. После этого заново остановите процесс. Повтор данного шага вызван тем, что таким образом запуска приложение сервера СУБД корректно завершит недостающие транзакции.

%SET_POSTGRES_BIN%/pg_ctl.exe stop -m fast

8. После выполненных шагов по перезапуску и правильной остановке экземпляра СУБД запустите службу PostgreSQL.

net start postgresql-x64-9.4
net start postgresql-x64-11

Служба не запускается. Есть сообщения об ошибках. Отсутствуют исполняемые файлы и DLL-библиотеки СУБД

В некоторых случаях после аварийной перезагрузки или в результате срабатывания антивирусных программ при запуске ОС Windows несколько файлов, которые необходимы для работы СУБД PostgreSQL могут отсутствовать. Это может объясняться критическим сбоем ОС.

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

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

2. Скачайте и разместите файл скрипт в папку с PostgreSQL: {Disk}:/Папка_PostgreSQL/bin/.

  • PostgreSQL 11: check_v11.bat.
  • PostgreSQL 9: check_v9.bat.

3. Запустите файл скрипта. В результате выполнения будет сформирован файл отчета report.txt.

4. Откройте файл отчета и проверьте, что все компоненты присутствуют.

Обязательно должны присутствовать такие библиотеки и исполняемые файлы, а также все библиотеки DLL.

  • libintl-9.dll
  • pg_ctl.exe
  • postgres.exe
  • psql.exe

5. Если какие-либо файлы отсутствуют. Тогда загрузите архив для соответствующей версии PostgreSQL и скопируйте недостающие файлы в папку СУБД {Disk}:/Папка_PostgreSQL/bin/.

  • Сборник файлов для PostgreSQL 11
  • Сборник файлов для PostgreSQL 9

6. После копирования недостающих файлов:

  1. Остановите службы сервера приложений SetRetail10 и МУК.
  2. Запустите службу PostgreSQL.
  3. Запустите службы сервера приложений SetRetail10 и МУК.

Дополнительная информация

Сравнительная таблица списка исполняемых файлов в версиях PostgreSQL

PostgreSQL 9.4 PostgreSQL 11.7
clusterdb.exe clusterdb.exe
createdb.exe createdb.exe
createlang.exe createuser.exe
createuser.exe dropdb.exe
dropdb.exe dropuser.exe
droplang.exe ecpg.exe
dropuser.exe icudt53.dll
ecpg.exe icuin53.dll
iconv.dll icuio53.dll
initdb.exe icule53.dll
isolationtester.exe iculx53.dll
libeay32.dll icutest53.dll
libintl-8.dll icutu53.dll
libpq.dll icuuc53.dll
libxml2.dll initdb.exe
libxslt.dll isolationtester.exe
oid2name.exe libcrypto-1_1-x64.dll
pg_archivecleanup.exe libcurl.dll
pg_basebackup.exe libcurl.lib
pg_config.exe libecpg.dll
pg_controldata.exe libecpg_compat.dll
pg_ctl.exe libiconv-2.dll
pg_dump.exe libintl-9.dll
pg_dumpall.exe libpgtypes.dll
pg_isolation_regress.exe libpq.dll
pg_isready.exe libssl-1_1-x64.dll
pg_receivexlog.exe libwinpthread-1.dll
pg_recvlogical.exe libxml2.dll
pg_regress.exe libxslt.dll
pg_regress_ecpg.exe oid2name.exe
pg_resetxlog.exe pg_archivecleanup.exe
pg_restore.exe pg_basebackup.exe
pg_standby.exe pg_config.exe
pg_test_fsync.exe pg_controldata.exe
pg_test_timing.exe pg_ctl.exe
pg_upgrade.exe pg_dump.exe
pg_xlogdump.exe pg_dumpall.exe
pgAdmin3.exe pg_isolation_regress.exe
pgbench.exe pg_isready.exe
postgres.exe pg_receivewal.exe
psql.exe pg_recvlogical.exe
reindexdb.exe pg_regress.exe
ssleay32.dll pg_regress_ecpg.exe
stackbuilder.exe pg_resetwal.exe
vacuumdb.exe pg_restore.exe
vacuumlo.exe pg_rewind.exe
wxbase28u_net_vc_custom.dll pg_standby.exe
wxbase28u_vc_custom.dll pg_test_fsync.exe
wxbase28u_xml_vc_custom.dll pg_test_timing.exe
wxmsw28u_adv_vc_custom.dll pg_upgrade.exe
wxmsw28u_aui_vc_custom.dll pg_verify_checksums.exe
wxmsw28u_core_vc_custom.dll pg_waldump.exe
wxmsw28u_html_vc_custom.dll pgbench.exe
wxmsw28u_stc_vc_custom.dll postgres.exe
wxmsw28u_xrc_vc_custom.dll psql.exe
zic.exe reindexdb.exe
zlib1.dll stackbuilder.exe
vacuumdb.exe
vacuumlo.exe
wxbase28u_net_vc_custom.dll
wxbase28u_vc_custom.dll
wxbase28u_xml_vc_custom.dll
wxmsw28u_adv_vc_custom.dll
wxmsw28u_aui_vc_custom.dll
wxmsw28u_core_vc_custom.dll
wxmsw28u_html_vc_custom.dll
wxmsw28u_xrc_vc_custom.dll
zic.exe
zlib1.dll

Иногда, в результате неправильного выключения сервера (пропало электричество, уборщица выдернула вилку из розетки и т.п.) перестает запускаться служба PostgresSQL. При попытке запуска появляется сообщение Служба была запущена, а затем остановлена.

Если до аварийного отключения СУБД работала нормально, то скорее всего такое сообщение возникает из-за ошибки в логах. В этом случае их нужно просто сбросить. Рассмотрим подробнее, как это сделать.

Прежде всего, потребуется определить два адреса:

  1. Адрес СУБД PostgresSQL. Обычно это папка Program Files. Нас будет интересовать папка Bin. Адрес может отличаться, в зависимость от версии СУБД. Например, он может выглядеть так: C:\Program Files\PostgreSQL\9.4.2-1.1C\bin
  2. Адрес, где хранятся сами базы данных. По умолчанию, это папка Data в папке с СУБД: C:\Program Files\PostgreSQL\9.4.2-1.1C\data. Но базы данных могут располагаться и по другому адресу. Чтобы точно узнать место расположения баз данных PostgresSQL, нужно зайти в свойства службы и посмотреть на командную строку ее запуска:
    Не запускается Служба PostgresSQL

Далее нужно запустить командную строку windows и набрать там следующие команды:

  1. cd «C:\Program Files\PostgreSQL\9.4.2-1.1C\bin» — эта команда осуществляет перевод в папку с приложениями СУБД. Используется первый адрес, который мы определили ранее.
  2. pg_resetxlog.exe -f «C:\Program Files\PostgreSQL\9.4.2-1.1C\data» — эта команда очищает логи СУБД. Здесь используется второй определенный нами адрес: адрес баз данных. После выполнения этой команды должно появиться сообщение Transaction log reset.
    Сброс логов PostgresSQL

Теперь можно запускать службу PostgresSQL.

Внимание! Для PostgresSQL версии 11 следует вместо файла pg_resetxlog.exe использовать файл pg_resetwal.exe

POSTGRESQL. Загадочные явления. ☑ 0

bvn-2005

04.02.19

15:59

Win 2008R2 + PostgreSQL + 1C. После аварийного отключения питания postgre не стартует. При попытке вручную запустить службу выдается сообщение: «Службы была запущена и сразу остановлена». Но самое интересное то, что в какой-то момент 1С запустилась, хотя служба postgre по-прежнему не запущена…

Собственно, 2 вопроса:

почему не запускается postgre  и почему запустилась 1С?

1

mikecool

04.02.19

16:09

почему не запускается postgre — смотреть журналы событий, скорее всего — логин пароль юзера не походят для запуска или прав нет

почему запустилась 1С — какая разница, главное чтобы работало постоянно

2

Valkyrie

04.02.19

16:14

(0) Было такое, разбираться не стали, помогла переустановка PostgreSQL

3

bolero

04.02.19

16:22

(2) отличный подход!

ТС, в логи смотреть ни в коем случае не надо! просто переустанови!

(0) кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен. Как только sql появится — рестарт сервера 1с не понадобится.

4

Valkyrie

04.02.19

16:24

(3) :)

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

5

eklmn

04.02.19

16:42

(4) ну значит в логах ничего не нашли или ничего не поняли, если все равно советуете переустановить?

Выхлоп и анализ логов привели к чему то?

6

Valkyrie

04.02.19

16:48

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

Так что советую сразу покупать новый сервер!

7

Valkyrie

04.02.19

16:49

(5) А если серьезно, то анализ логов дал понять, что накрывались жесткие диски в стойке, что и подтвердилось впоследствии.

8

bvn-2005

05.02.19

08:26

» смотреть журналы событий»

В виндовом журнале событий куча сообщений такого вида:

«FATAL:  the database system is starting up»

«анализ логов»

Можно про это подробнее… хотя бы где искать эти логи?

» кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен»

ТАк база-то доступна и полноценно работает…???

9

Nikoss

05.02.19

08:53

(8) ты в гугле был?

https://forum.lissyara.su/bazy-dannyh-f52/srochno-nujna-pomosch-upal-posgresql-t37927.html

[При ошибках в логах транзакций сервер postgresql не запускается.

Т.е. их необходимо почистить т.е. сделать pg_resetxlog.]

10

DrLekter

05.02.19

09:29

Встречался с таким. При этом процессы postgre активны и работают с процом, но служба не стартует. Если оставить его в покое на некоторое время, запустится само. Время зависит от базы и производительности машины. На i7 это занимало минут двадцать, на дохленьком компе с копией той же базы — полдня.

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

11

bvn-2005

05.02.19

09:39

«запустится само»

Прошли почти сутки — не запустилось…

«что-то в базах ломается и он перед запуском службы восстанавливает базу»

Сейчас обнаружил: в журнал событий непрерывно пишутся сообщения такого вида:

LOG:  autovacuum: found orphan temp table «pg_temp_21».»tt5″ in database «rzp2»

Действительно, восстанавливает?

12

bolero

05.02.19

15:45

(8) «system is starting up» — это он время от времени говорит, что пытается стартовать, чтобы не молчать

FATAL в этом случае лишь уровень, чтобы в лог упало при любых настройках логов

«system is ready to accept connections» — это стартанул

(8) > хотя бы где искать эти логи?

В том же каталоге, где лежит база, каталог pg_log (либо просто log в версии 10)

(11) вряд ли, просто симптомы

(10) > перед запуском службы восстанавливает базу

верно, при нормальной работе сначала падает на диск лог транзакций, а потом заменяются файлы таблиц. Если питание пропало после записи лога транзакций, но до записи таблиц — из WAL пытается восстановить правильное состояние базы.

Самая стрёмная ситуация — когда лог транзакций записался с ошибкой, что видимо и произошло. В таком случае (9) может помочь, но несколько последних документов/действий будет потеряно.

13

igork1966

05.02.19

16:00

(10) +1000

Тоже не раз бывало… чего-то оног там делает с незавершенными транзакциями судя по всему.

14

ansh15

05.02.19

16:02

(11) >>Действительно, восстанавливает?

Не всегда, иногда приходится что-нибудь делать вручную — https://habr.com/ru/company/postgrespro/blog/282770/

15

igork1966

05.02.19

16:03

(13) + пишет что-то вроде:

2018-12-10 11:30:02 MSK СООБЩЕНИЕ:  работа системы БД была прервана; последний момент работы: 2018-12-10 11:18:41 MSK

2018-12-10 11:30:02 MSK ВАЖНО:  система баз данных запускается

2018-12-10 11:30:03 MSK ВАЖНО:  система баз данных запускается

2018-12-10 11:30:04 MSK ВАЖНО:  система баз данных запускается

…..

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  система БД была остановлена нештатно; производится автоматическое восстановление

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  запись REDO начинается со смещения C1/3C3B7548

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  запись нулевой длины по смещению C1/3C3C69E0

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  записи REDO обработаны до смещения C1/3C3C69B0

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  последняя завершённая транзакция была выполнена в 2018-12-10 11:27:51.952+03

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  Защита от наложения мультитранзакций сейчас включена

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  система БД готова принимать подключения

2018-12-10 11:31:06 MSK СООБЩЕНИЕ:  процесс запуска автоочистки создан

2018-12-10 11:47:40 MSK NOTICE:  table «tt1» does not exist, skipping

2018-12-10 11:47:40 MSK STATEMENT:  drop table if exists tt1 cascade;create temporary table tt1 (_Fld29433RRef bytea, _Fld29434 numeric(14, 0), _Fld29435 numeric(15, 0), _Fld29436 timestamp, _Fld29437 numeric(15, 3), _Fld29438 numeric(10, 0), _Fld29439 mvarchar(1000), _Fld29440 timestamp, _Fld29441 numeric(14, 0), _Fld29442 mvarchar(128), _Fld29443 timestamp, _Fld29444 boolean ) without oids

2018-12-10 11:50:21 MSK NOTICE:  table «tt2» does not exist, skipping

2018-12-10 11:50:21 MSK STATEMENT:  drop table if exists tt2 cascade;create temporary table tt2 (_Fld28213 numeric(1, 0), _Fld28214 timestamp, _Fld28215 mvarchar(100), _Fld28216 bytea, _Fld28217 numeric(15, 3), _Fld28218 timestamp ) without oids

2018-12-10 11:50:22 MSK NOTICE:  table «tt3» does not exist, skipping

2018-12-10 11:50:22 MSK STATEMENT:  drop table if exists tt3 cascade;create temporary table tt3 (_Q_000_F_000RRef bytea ) without oids

2018-12-10 11:50:22 MSK NOTICE:  index «tmpind_0» does not exist, skipping

…..

16

ansh15

05.02.19

16:19

Опубликовал | Дата 30 сентября, 2021

Служба postgresql после сбоя перестала запускаться…
Соответственно, базы 1C оказались недоступны. Все это крутится на Windows Server 2012.
Надо сказать, что в интернете много подобных ошибок, но мало их решений.
Итак, варианты решений:
1. Перезагрузить сервер.
2. Почистить журналы Postgre командой  C:\Program Files (x86)\PostgreSQL\9.6.1-4.1C\bin>pg_resetxlog.exe -f «D:\PostgreSQL\data» (pg_resetwal -f -D <Путь к папке БД>) — команда зависит от версии postgre.
3. Удалить файл postmaster.pid.
4. Прописать права пользователя postgres (или СОЗДАТЕЛЬ/ВЛАДЕЛЕЦ) на каталог Data.
5. Переустановить postgreSQL (ту же версию поверх имеющейся).
6. Ну и самый последний вариант — восстановить базы 1С из бэкапа.
Причем, нет гарантий, что базы 1С, при этом,  полностью восстановятся (в последнем случае восстановление будет только на момент бэкапа).
Встретил еще вот такой способ:
Заходим в Users/ваш юзер/appdata/roaming/pgadmin, открываем файл логов pgadmin4.txt, смотрим ошибку
У меня была: (0x0000274D/10061)
Причина ошибки либо недостаток прав, либо занятость порта другими процессами
Почистил и поотключал антивирусы, не помогло.
Командой netstat -ano узнал id процесса на порту 5432 (порт postgresql), узнал его id (столбец PID)
Дальше открываем диспетчер задач, вкладка подробности и смотрим, каким процессом занят порт с нужным id (у меня id был 12856), кликаем на процесс и жмём снять задачу.
В результате, служба запустилась.
Мне повезло, помог самый первый способ — перезагрузка сервера.

Due to a sudden power outage, the Postgres server running on my local machine shut down abruptly. After rebooting, I tried to restart Postgres and I get this error:

$ pg_ctl -D /usr/local/pgsql/data restart

pg_ctl: PID file "/usr/local/pgsql/data/postmaster.pid" does not exist
Is server running?
starting server anyway
server starting
$:/usr/local/pgsql/data$ LOG:  database system shutdown was interrupted at 2009-02-28 21:06:16 
LOG:  checkpoint record is at 2/8FD6F8D0
LOG:  redo record is at 2/8FD6F8D0; undo record is at 0/0; shutdown FALSE
LOG:  next transaction ID: 0/1888104; next OID: 1711752
LOG:  next MultiXactId: 2; next MultiXactOffset: 3
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 2/8FD6F918
LOG:  record with zero length at 2/8FFD94A8
LOG:  redo done at 2/8FFD9480
LOG:  could not fsync segment 0 of relation 1663/1707047/1707304: No such file or directory
FATAL:  storage sync failed on magnetic disk: No such file or directory
LOG:  startup process (PID 5465) exited with exit code 1
LOG:  aborting startup due to startup process failure

There is no postmaster.pid file in the data directory. What possibly could be the reason for this sort of behavior and of course what is the way out?

asked Feb 28, 2009 at 15:53

3

You’d need to pg_resetxlog. Your database can be in an inconsistent state after this though, so dump it with pg_dumpall, recreate and import back.

A cause for this could be:

  • You have not turned off hardware
    write cache on disk, which often
    prevents the OS from making sure data is written before it reports successful write to application. Check with

    hdparm -I /dev/sda

    If it shows «*» before «Write cache» then this could be the case. Source of PostgreSQL has a program src/tools/fsync/test_fsync.c, which tests speed of syncing data with disk. Run it — if it reports all times shorter than, say, 3 seconds than your disk is lying to OS — on a 7500rpm disks a test of 1000 writes to the same place would need at least 8 seconds to complete (1000/(7500rpm/60s)) as it can only write once per route. You’d need to edit this test_fsync.c if your database is on another disk than /var/tmp partition — change

    #define FSYNC_FILENAME "/var/tmp/test_fsync.out"

    to

    #define FSYNC_FILENAME "/usr/local/pgsql/data/test_fsync.out"

  • Your disk is failing and has a bad block, check with badblocks.

  • You have a bad RAM, check with memtest86+ for at least 8 hours.

answered Mar 2, 2009 at 10:58

Tometzky's user avatar

TometzkyTometzky

22.7k5 gold badges60 silver badges74 bronze badges

4

Reading a few similar messages in the archives of the PostgreSQL
mailing list («storage sync failed on magnetic disk: No such file or
directory») seems to indicate that there is a very serious hardware
trouble, much worse than a simple power failure. You may have to prepare yourself to restore from backups.

answered Feb 28, 2009 at 17:57

bortzmeyer's user avatar

bortzmeyerbortzmeyer

34.3k12 gold badges68 silver badges91 bronze badges

2

Had db corruption too, my actions

docker run -it --rm -v /path/to/db:/var/lib/postgresql/data postgres:10.3 bash
su - postgres
/usr/lib/postgresql/10/bin/pg_resetwal -D /var/lib/postgresql/data -f

answered Apr 30, 2018 at 20:31

srghma's user avatar

srghmasrghma

4,8502 gold badges38 silver badges54 bronze badges

I had this same problem and I was about to dump, reinstall and import from db dump (a really painfull process), however I just tried this as the last resource and it worked!

brew services start postgresql

Then I restarted and that was it.

answered Jul 6, 2020 at 16:21

Alexander Quiceno's user avatar

Run start instead of restart.
Execute the below command:

$pg_ctl -D /usr/local/pgsql/data start

answered Aug 7, 2009 at 5:06

1

Had this problem a couple of times, when my laptop turned off unexpectedly, when on very low battery while running PSQL in the background.

My solution after searching all over was, Hard delete and Reinstall, then import data from db dump.

Steps for Mac with brew to uninstall and reinstall psql 9.6

brew uninstall [email protected]
rm -rf rm -rf /usr/local/var/[email protected]
rm -rf .psql.local .psql_history .psqlrc.local l.psqlrc .pgpass

brew install [email protected]

echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> ~/.bash_profile
source ~/.bash_profile

brew services start [email protected]

createuser -s postgres
createuser {ENTER_YOUR_USER_HERE} --interactive

answered Jun 26, 2020 at 12:49

czarss's user avatar

czarssczarss

1218 bronze badges

As others stated, a stop + start instead of a restart worked for me. In a Docker environment this would be:

docker stop <container_name>
docker start <container_name>

or when using Docker Compose:

docker-compose stop
docker-compose start

answered Aug 4, 2020 at 1:23

Sicco's user avatar

SiccoSicco

6,1875 gold badges45 silver badges61 bronze badges

  • Не запускается icloud на windows 10
  • Не запускается mozilla firefox на windows 10
  • Не запускается minecraft windows 10 edition
  • Не запускается hoi 4 на windows 10
  • Не запускается microsoft word на windows 10