Я використовую 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.

А

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. Я на жорсткому диску. Збій жорсткого диска.

Збій жорсткого диска

Збій жорсткого диска призвів до запуску посібника fsckпідказок, а не на основі gui. З його допомогою відновлюють gazillion inodes тощо. Після цього я перезапустив систему з 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/Крупція . Ви повинні скопіювати весь каталог даних. У 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перевірку вашого жорсткого диска за smartctlдопомогою smartmontools; припускаючи, /dev/hdaщо це було б smartctl -d ata -a /dev/sda | less. Шукайте невдалий тест на здоров'я, uncorrectable_sectorsвисокий показник помилки читання, перерозподілений_сектор_счет понад 2 або 3 або ненульовий сектор current_pending_sector. Запустіть, smartctl -d ata -t long /dev/sdaщоб виконати неруйнівний самотест на вашому жорсткому диску; це не перерве нормальне функціонування системи. Коли минув орієнтовний час, запустіть smartctl -d ata /dev/sdaще раз і подивіться журнал самотестування, щоб побачити, чи минув він.

Якщо щось виглядає менш ніж ідеально, замініть привід.

Надалі розглянемо автоматизацію цього тестування smartdдля раннього попередження відмов диска.

(Вміст у цій публікації застарів оновленнями запитання. Якщо ви вирішили подібну проблему, перегляньте історію редагування цієї відповіді).