Dashboard > СУБД > Home > PostgreSQL, could not locate a valid checkpoint record > Information > Сравнение Страницы
  СУБД Вход | Зарегистрироваться   Вариант для печати.  
  PostgreSQL, could not locate a valid checkpoint record
Версия 1 shixaro
на Sep 14, 2011 22:50.


 
сравнено с
Ключ
Эти линии были удалены. Это слово было удалено.
Эти линии были добавлены. Это слово было добавлено.

Просмотреть историю страницы


there.are.num.changes

 При нештатном завершении работы слоник может завалиться на бок ввиду испорченного журнала транзакций и более не хотеть запускаться.
 Один из способов оживить - сбросить журнал транзакций:
  Бывают случаи, когда файлы журнала транзакций (pg_xlog) могут быть повреждены или случайно удалены. В таком случае PGSQL не сможет работать и просто не запустится с подобной ошибкой:
 {noformat}
pg_resetxlog -f
  Jul 4 11:30:18 database postgres[92997]: [1-1] LOG: database system was interrupted at 2009-07-04 11:24:30 MSD
  Jul 4 11:30:18 database postgres[92997]: [2-1] LOG: could not open file "pg_xlog/000000010000031A00000027" (log file 794, segment 39): No such file or directory
  Jul 4 11:30:18 database postgres[92997]: [3-1] LOG: invalid primary checkpoint record
  Jul 4 11:30:18 database postgres[92997]: [4-1] LOG: could not open file "pg_xlog/000000010000031A00000026" (log file 794, segment 38): No such file or directory
  Jul 4 11:30:18 database postgres[92997]: [5-1] LOG: invalid secondary checkpoint record
  Jul 4 11:30:18 database postgres[92997]: [6-1] PANIC: could not locate a valid checkpoint record
 {noformat}
  
 Найти поврежденный xlog-файл вряд ли получится, поэтому выход один - очистить информацию в БД об используемых логах. Для этого есть штатная утилита pg_resetxlog
  
  
  Но перед ее использованием надо узнать что именно вытирать из БД. Для этого делаем:
 {noformat}
 # pg_controldata /var/db/pgsql/
  pg_control version number: 822
  Catalog version number: 200611241
  Database system identifier: 5208761103136292066
  Database cluster state: in production
  pg_control last modified: Sat Jul 4 11:24:30 2009
  Current log file ID: 794
  Next log file segment: 41
  Latest checkpoint location: 31A/27FFF7B8
  Prior checkpoint location: 31A/26139600
  Latest checkpoint's REDO location: 31A/27FFF7B8
  Latest checkpoint's UNDO location: 0/0
  Latest checkpoint's TimeLineID: 1
  Latest checkpoint's NextXID: 0/2400998005
  Latest checkpoint's NextOID: 75014368
  Latest checkpoint's NextMultiXactId: 1101236
  Latest checkpoint's NextMultiOffset: 2360801
  Time of latest checkpoint: Sat Jul 4 10:27:08 2009
  Minimum recovery ending location: 0/0
  Maximum data alignment: 8
  Database block size: 8192
  Blocks per segment of large relation: 131072
  WAL block size: 8192
  Bytes per WAL segment: 16777216
  Maximum length of identifiers: 64
  Maximum columns in an index: 32
  Date/time type storage: floating-point numbers
  Maximum length of locale name: 128
  LC_COLLATE: C
  LC_CTYPE: C
 {noformat}
  
 С этой информации нам интересны эти две строчки:
 {noformat}
 Latest checkpoint's NextXID: 0/2400998005
  Latest checkpoint's NextOID: 75014368
 {noformat}
  
 Переходим в пользователя от имени которого выполняется PGSQL (в моем случае, это pgsql)
 {noformat}
 # su pgsql
 {noformat}
  
 И теперь сбрасываем логи, указав в параметрах наши цифры из данных pg_control
 {noformat}
 $ pg_resetxlog -o 75014368 -x 2400998005 -f /var/db/pgsql/
  Transaction log reset
 {noformat}
  
 Все, PGSQL теперь не помнит, что у него были когда-то логи транзакций и спокойно запустится, начав создавать их по-новой.
  
  
  
  
 http://www.mironovs.com/databases/vosstanovlenie-postgresql-posle-povrezhdeniya-fajlov-xlog.html
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5 Build:#805 Apr 26, 2007) - Запрос Bug/feature - Связаться с администраторами