Инцидент: в ситуации, когда сервер был выключен аварийно, через кнопку выключения или при отсутствии электропитания, то после его включения служба 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. После копирования недостающих файлов:
- Остановите службы сервера приложений SetRetail10 и МУК.
- Запустите службу PostgreSQL.
- Запустите службы сервера приложений 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. При попытке запуска появляется сообщение Служба была запущена, а затем остановлена.
Если до аварийного отключения СУБД работала нормально, то скорее всего такое сообщение возникает из-за ошибки в логах. В этом случае их нужно просто сбросить. Рассмотрим подробнее, как это сделать.
Прежде всего, потребуется определить два адреса:
- Адрес СУБД PostgresSQL. Обычно это папка Program Files. Нас будет интересовать папка Bin. Адрес может отличаться, в зависимость от версии СУБД. Например, он может выглядеть так: C:\Program Files\PostgreSQL\9.4.2-1.1C\bin
- Адрес, где хранятся сами базы данных. По умолчанию, это папка Data в папке с СУБД: C:\Program Files\PostgreSQL\9.4.2-1.1C\data. Но базы данных могут располагаться и по другому адресу. Чтобы точно узнать место расположения баз данных PostgresSQL, нужно зайти в свойства службы и посмотреть на командную строку ее запуска:
Далее нужно запустить командную строку windows и набрать там следующие команды:
- cd «C:\Program Files\PostgreSQL\9.4.2-1.1C\bin» — эта команда осуществляет перевод в папку с приложениями СУБД. Используется первый адрес, который мы определили ранее.
- pg_resetxlog.exe -f «C:\Program Files\PostgreSQL\9.4.2-1.1C\data» — эта команда очищает логи СУБД. Здесь используется второй определенный нами адрес: адрес баз данных. После выполнения этой команды должно появиться сообщение Transaction log reset.
Теперь можно запускать службу PostgresSQL.
Внимание! Для PostgresSQL версии 11 следует вместо файла pg_resetxlog.exe использовать файл pg_resetwal.exe
bvn-2005
04.02.19
✎
15:59
Win 2008R2 + PostgreSQL + 1C. После аварийного отключения питания postgre не стартует. При попытке вручную запустить службу выдается сообщение: «Службы была запущена и сразу остановлена». Но самое интересное то, что в какой-то момент 1С запустилась, хотя служба postgre по-прежнему не запущена…
Собственно, 2 вопроса:
почему не запускается postgre и почему запустилась 1С?
mikecool
04.02.19
✎
16:09
почему не запускается postgre — смотреть журналы событий, скорее всего — логин пароль юзера не походят для запуска или прав нет
почему запустилась 1С — какая разница, главное чтобы работало постоянно
Valkyrie
04.02.19
✎
16:14
(0) Было такое, разбираться не стали, помогла переустановка PostgreSQL
bolero
04.02.19
✎
16:22
(2) отличный подход!
ТС, в логи смотреть ни в коем случае не надо! просто переустанови!
(0) кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен. Как только sql появится — рестарт сервера 1с не понадобится.
Valkyrie
04.02.19
✎
16:24
(3) 
База была нужна срочно, поэтому анализ логов проводился после. Запустить нужно было здесь и сейчас.
eklmn
04.02.19
✎
16:42
(4) ну значит в логах ничего не нашли или ничего не поняли, если все равно советуете переустановить?
Выхлоп и анализ логов привели к чему то?
Valkyrie
04.02.19
✎
16:48
(5) Хехе, там после этого проблемы с отключением питания продолжились, упал рейдконтроллер и клиент купил новый сервер)
Так что советую сразу покупать новый сервер!
Valkyrie
04.02.19
✎
16:49
(5) А если серьезно, то анализ логов дал понять, что накрывались жесткие диски в стойке, что и подтвердилось впоследствии.
bvn-2005
05.02.19
✎
08:26
» смотреть журналы событий»
В виндовом журнале событий куча сообщений такого вида:
«FATAL: the database system is starting up»
«анализ логов»
Можно про это подробнее… хотя бы где искать эти логи?
» кластер 1с запускается при недоступной базе, только не может запустить фоновые задания, и каждому пользователю отвечает, что sql недоступен»
ТАк база-то доступна и полноценно работает…???
Nikoss
05.02.19
✎
08:53
(8) ты в гугле был?
https://forum.lissyara.su/bazy-dannyh-f52/srochno-nujna-pomosch-upal-posgresql-t37927.html
[При ошибках в логах транзакций сервер postgresql не запускается.
Т.е. их необходимо почистить т.е. сделать pg_resetxlog.]
DrLekter
05.02.19
✎
09:29
Встречался с таким. При этом процессы postgre активны и работают с процом, но служба не стартует. Если оставить его в покое на некоторое время, запустится само. Время зависит от базы и производительности машины. На i7 это занимало минут двадцать, на дохленьком компе с копией той же базы — полдня.
Предполагаю, при аварийном отключении что-то в базах ломается (там же в памяти многое происходит) и он перед запуском службы восстанавливает базу.
bvn-2005
05.02.19
✎
09:39
«запустится само»
Прошли почти сутки — не запустилось…
«что-то в базах ломается и он перед запуском службы восстанавливает базу»
Сейчас обнаружил: в журнал событий непрерывно пишутся сообщения такого вида:
LOG: autovacuum: found orphan temp table «pg_temp_21».»tt5″ in database «rzp2»
Действительно, восстанавливает?
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) может помочь, но несколько последних документов/действий будет потеряно.
igork1966
05.02.19
✎
16:00
(10) +1000
Тоже не раз бывало… чего-то оног там делает с незавершенными транзакциями судя по всему.
ansh15
05.02.19
✎
16:02
(11) >>Действительно, восстанавливает?
Не всегда, иногда приходится что-нибудь делать вручную — https://habr.com/ru/company/postgrespro/blog/282770/
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
…..
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 withhdparm -I /dev/sdaIf 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
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
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
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
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
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
SiccoSicco
6,1875 gold badges45 silver badges61 bronze badges