Запуск сервера PostgreSQL после сбоя жесткого диска приводит к НЕУДАЧНОМУ СОСТОЯНИЮ


10

Я использую 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

И журнал Postgres?
Милен А. Радев

@ MilenA.Radev Обновили вопрос с помощью журнала postgres ..
ThinkingMonkey

pg_resetxlogничего хорошего не сделало, так что вы попадаете на забавную территорию. У вас есть резервная копия этой базы данных до аварии?
Крейг Рингер

@CraigRinger Да, у меня есть резервная копия. Я действительно наслаждаюсь этой поездкой.
ThinkingMonkey

@ThinkingMonkey Удивительно! Вы один из немногих избранных с хорошими резервными копиями :-). Честно говоря, вероятно, ваша БД исправима, но поскольку повреждение вашей файловой системы уничтожило важные файлы, вам, вероятно, понадобится кто-то, кто действительно хорошо знает внутренности Pg, чтобы потратить некоторое время на вывод ваших данных. Услуги доступны здесь: postgresql.org/support/professional_support. Может быть, если бы вы могли придумать какой-нибудь фиктивный контент для того, pg_multixact/offsets/0000что ПГ приняла бы ...
Крейг Рингер

Ответы:


15

Реальный ответ будет в журналах 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раннего предупреждения об отказах дисков.

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


Я добавил журнал postgres в вопрос. Я не изменил настройку по умолчанию, fsyncтак что я думаю, она была установлена ​​на on. Я на HDD. Да, жесткий диск разбился. У меня не осталось свободного места на диске. Нет ошибки памяти / перегрев / отключение по кабелю / Kerpanic.
ThinkingMonkey

@ThinkingMonkey Что за «сбой жесткого диска»? Пришлось ли вам восстанавливать данные на жестком диске, чтобы скопировать файлы на новый диск? Приходилось ли вам запускать fsckи восстанавливать файловую систему? Подробности, пожалуйста. Напишите историю вашего крушения.
Крейг Рингер

Сбой жесткого диска привел к запуску руководства fsckдля. С его помощью восстанавливают gazillion inode и т. Д. После чего система перезагружается. Также обновили вышеупомянутое в вопросе.
ThinkingMonkey

@ThinkingMonkey ОК, ответ обновлен. TL; DR: создайте полную копию уровня файловой системы / var / lib / pgsql, а затем запуститеpg_resetxlog
Крейг Рингер

спасибо .. на копию & resetxlog. скоро вернусь с результатами.
ThinkingMonkey
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.