Can not start the base.

This was the log when trying to run an archived version:

Starting PostgreSQL Cluster 9.6-main... The PostgreSQL server failed to start. Please check the log output: 2018-03-12 11:22:36.633 MSK [7789] СООБЩЕНИЕ: работа системы БД была прервана; последний момент работы: 2018-03-07 06:00:04 MSK 2018-03-12 11:22:37.022 MSK [7790] [н/д]@[н/д] СООБЩЕНИЕ: неполный стартовый пакет 2018-03-12 11:22:37.536 MSK [7793] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:38.049 MSK [7796] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:38.565 MSK [7799] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:39.080 MSK [7802] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:39.595 MSK [7805] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:40.106 MSK [7808] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:40.625 MSK [7812] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:41.136 MSK [7815] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:41.651 MSK [7818] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:42.163 MSK [7821] postgres@postgres ВАЖНО: система баз данных запускается 2018-03-12 11:22:42.172 MSK [7789] СООБЩЕНИЕ: неверная запись контрольной точки 2018-03-12 11:22:42.172 MSK [7789] ВАЖНО: не удалось считать нужную запись контрольной точки 2018-03-12 11:22:42.172 MSK [7789] ПОДСКАЗКА: Если вы не восстанавливаете БД из резервной копии, попробуйте удалить файл "/var/lib/postgresql/9.6/main/backup_label". 2018-03-12 11:22:42.174 MSK [7788] СООБЩЕНИЕ: стартовый процесс (PID 7789) завершился с кодом выхода 1 2018-03-12 11:22:42.174 MSK [7788] СООБЩЕНИЕ: прерывание запуска из-за ошибки в стартовом процессе 2018-03-12 11:22:42.176 MSK [7788] СООБЩЕНИЕ: система БД выключена postgresql@9.6-main.service: Control process exited, code=exited status=1 Failed to start PostgreSQL Cluster 9.6-main. postgresql@9.6-main.service: Unit entered failed state. postgresql@9.6-main.service: Failed with result 'exit-code'.

Here is a link to the wal, which is not in the bakup (or are they renamed?)

 root@zaschita-zal-p:~# cat /var/lib/postgresql/9.6/main/backup_label START WAL LOCATION: 7D/3C000028 (file 000000010000007D0000003C) CHECKPOINT LOCATION: 7D/3C0040D0 BACKUP METHOD: streamed BACKUP FROM: master START TIME: 2018-03-07 06:00:05 MSK LABEL: pg_basebackup base backup root@zaschita-zal-p:~#

There is one in the archive. But did not restore_command with restore_command in recovery.conf .

  • Well, since the spirit raised the question - in recovery.conf what was at the time of launch? - Shallow
  • I added a command there to take the shafts from the archive, but the command did not even try to launch this command - eri

2 answers 2

Actually, the picture is unequivocally clear from the above log and the source code of the database. There is only one place to get messages.

2018-03-12 11: 22: 42.172 MSK [7789] IMPORTANT: the necessary checkpoint record could not be read 2018-03-12 11: 22: 42.172 MSK [7789] TIP: If you are not restoring the database from the backup, try deleting the file "/var/lib/postgresql/9.6/main/backup_label".

And a little bit above this place there is a code that will mark the log of the LOG level in the log, always if the database has read the recovery.conf file.

You do not have any of these messages in the log. The only possible explanation is that you do not have a recovery.conf file. This is the only way to leave the call to the readRecoveryCommandFile function without receiving a FATAL error and setting the ArchiveRecoveryRequested variable.

And since recovery.conf not at the start of the startup process - it doesn’t have any meaning what you might want to specify in restore_command because it was not read.

recovery.conf should be strictly in the root of the PGDATA directories, on the same level as the rest of the PG_VERSION , pg_xlog , pg_clog , postgresql.auto.conf and other parts of the database.

    Not an answer, but a temporary solution:

    Changed the command to

     pg_basebackup -x --write-recovery-conf --format=t -z --pgdata=$BACKPATH$($DATE)/pg_basebackup/

    Now the base is fully archived and starts.

    It would be more correct to teach PG to pull the shafts from the archive itself.