Я использую Fedora 15с PostgreSQL 9.1.4. Fedora недавно разбилась, после чего:

Попытка запустить сервер PostgreSQL:

service postgresql-9.1 start

дает

Starting postgresql-9.1 (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                       [FAILED]

Хотя сервер запускается нормально, когда я запускаю сервер в первый раз после перезагрузки системы .
Но попытка использования psqlдает эту ошибку:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

.s.PGSQL.5432файла нет нигде в системе. А locate .s.PGSQL.5432ничего не выводит.

Системный журнал имеет это:

Aug 14 17:31:58 localhost systemd[1]: postgresql-9.1.service: control process exited, code=exited status=1
Aug 14 17:31:58 localhost systemd[1]: Unit postgresql-9.1.service entered failed state.

A

systemctl status postgresql-9.1.service

дает

postgresql-9.1.service - SYSV: PostgreSQL database server.
          Loaded: loaded (/etc/rc.d/init.d/postgresql-9.1)
      Active: failed since Tue, 14 Aug 2012 17:31:58 +0530; 58s ago
     Process: 2811 ExecStop=/etc/rc.d/init.d/postgresql-9.1 stop (code=exited, status=1/FAILURE)
     Process: 12423 ExecStart=/etc/rc.d/init.d/postgresql-9.1 start (code=exited, status=1/FAILURE)
    Main PID: 2551 (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/postgresql-9.1.service

Я не изменил настройку по умолчанию для fsync, поэтому, я думаю, она была установлена ​​на on. Я на HDD. Сбой жесткого диска.

Сбой жесткого диска

Сбой жесткого диска привел к запуску руководства fsckпо подсказке, а не на основе графического интерфейса. С его ремонтом Gazillion дескрипторов и т.д .. После чего я перезагрузил систему с Ctrl+ Alt+ Delete.

Журнал PostgreSQL имеет это:

LOG:  database system was interrupted; last known up at 2012-08-14 17:31:57 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/41A4E58
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13016) exited with exit code 1
LOG:  aborting startup due to startup process failure

Обновить

Попытка запустить сервер после получения копии /var/lib/pgsqlкаталога на уровне файловой системы и запуска ./pg_resetxlog -f /var/lib/pgsql/9.1/data/с результатом xlog -f /var/lib/pgsql/9.1/data/все еще приводит к:

LOG:  database system was interrupted; last known up at 2012-08-14 18:46:36 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/6000078
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13766) exited with exit code 1
LOG:  aborting startup due to startup process failure

Реальный ответ будет в журналах PostgreSQL, в /var/lib/pgsql/data/pg_log.

Однако, прежде чем предпринимать какие-либо действия: жизненно важно, чтобы вы сделали копию своей базы данных на уровне файловой системы, прежде чем пытаться восстановить, если какие-либо из ваших данных представляют для вас ценность . Смотрите http://wiki.postgresql.org/wiki/Corruption . Вы должны скопировать весь каталог данных. На Fedora это /var/lib/pgsql/dataпо умолчанию, но убедитесь, что это правильно для вашей установки.

Судя по опубликованным вами журналам, у вас определенно есть некоторая степень повреждения базы данных. Хранилище, в котором находится база данных (жесткий диск или файловая система), скорее всего, повреждено. Возьмите копию СЕЙЧАС и поместите ее на другой жесткий диск или систему .

Только после того, как вы сделали полную копию своей директории данных на уровне файловой системы, попробуйте использовать pg_resetxlog, чтобы очистить поврежденные журналы транзакций и запустить вашу базу данных. Даже если он начнется, он, скорее всего, будет коррумпированным; Вы должны pg_dumpзатем восстановить initdbего и восстановить дамп на новый экземпляр.

Если вы все еще не можете запустить его после, pg_resetxlogто опубликуйте обновленный журнал попытки запуска после resetxlog. Возможно, вам потребуется запустить Pg в автономном режиме с помощью:

sudo -u postgres postgres --single -D /var/lib/pgsql/data -P -f i postgres

Если это сработает, и вы получите backend>подсказку, попробуйте еще раз, заменив последний «postgres» именем БД, к которой вы хотите подключиться. Вы должны уметь SELECT, COPYданные из таблиц и т. Д.

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

Ваша файловая система, вероятно, повреждена

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

Я бы не стал доверять этой файловой системе fsckили нет fsck.

SMART-проверить свой диск

Я также рекомендую запустить SMARTпроверку жесткого диска с помощью smartctlsmartmontools; при условии, /dev/hdaчто это будет smartctl -d ata -a /dev/sda | less. Ищите неудавшийся тест работоспособности, uncorrectable_sectorsвысокую частоту ошибок чтения, reallocated_sector_count больше 2 или 3 или ненулевой current_pending_sector. Запустите smartctl -d ata -t long /dev/sdaдля выполнения неразрушающего самотестирования на жестком диске; это не нарушит нормальное функционирование системы. По истечении расчетного времени smartctl -d ata /dev/sdaснова запустите программу и посмотрите журнал самопроверки, чтобы узнать, прошло ли оно.

Если что-то выглядит не идеально, замените диск.

В будущем рассмотрите возможность автоматизации этого тестирования с помощью smartdраннего предупреждения об отказах дисков.

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