Ben kullanıyorum Fedora 15ile PostgreSQL 9.1.4. Fedora son zamanlarda çöktü ve bundan sonra:

PostgreSQL sunucusunu başlatma denemesi:

service postgresql-9.1 start

verir

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

Rağmen ben sistem yeniden başlatıldıktan sonra sunucuyu ilk kez başlattığınızda sunucu normalde başlar .
Ancak, kullanma denemesi psqlbu hatayı verir:

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.5432dosya sistemin hiçbir yerinde mevcut değil. A locate .s.PGSQL.5432hiçbir şey çıkarmaz.

Sistem günlüğünde şunlar bulunur:

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.

bir

systemctl status postgresql-9.1.service

verir

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

Ben fsync varsayılan ayarını değiştirmemişti, bu yüzden tahmin ediyorum, olarak ayarlandı on. HDD'deyim. HDD çöktü.

HDD çökmesi

HDD çökmesi fsckbir GUI tabanlı değil, bir istem üzerinde bir kılavuz çalıştırılması ile sonuçlandı . Onunla gazilyon inotlarını tamir etmek vb .. Daha sonra sistemi bir Ctrl+ Alt+ ile yeniden başlattım Delete.

PostgreSQL'in günlüğü şuna sahiptir:

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

Güncelleme

/var/lib/pgsqlDizinin bir dosya sistemi düzeyinde kopyasını aldıktan sonra sunucuyu başlatmaya çalışmak ./pg_resetxlog -f /var/lib/pgsql/9.1/data/ve sonuçla çalışmak xlog -f /var/lib/pgsql/9.1/data/hala sonuç verir:

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

Asıl cevap, PostgreSQL günlüklerinde olacak /var/lib/pgsql/data/pg_log.

Ancak, herhangi bir işlem yapmadan önce: Verilerinizden herhangi biri sizin için değerliyse, onarımdan önce veritabanınızın dosya sistemi düzeyinde bir kopyasını almanız çok önemlidir . Bkz. Http://wiki.postgresql.org/wiki/Corruption . Tüm veri dizinini kopyalamanız gerekir. Fedora'da /var/lib/pgsql/datavarsayılan olarak budur, ancak bunun kurulumunuz için doğru olduğunu doğrulayın.

Gönderdiğiniz günlüklere dayanarak kesinlikle bir dereceye kadar veritabanı bozulması vardır. Veritabanının bulunduğu depolama alanı (sabit sürücü veya dosya sistemi) büyük olasılıkla zarar görür. ŞİMDİ bir kopya alın ve farklı bir sabit sürücüye veya sisteme koyun .

Veri dizininizin tam dosya sistemi düzeyinde bir kopyasını oluşturduktan sonra, hasarlı işlem günlüklerini temizlemek ve veritabanınızı başlatmak için pg_resetxlog'u kullanmayı deneyin . Başlasa bile bozulma olasılığı yüksektir; Eğer gereken pg_dumpo zaman yeniden initdbonu ve taze örneğine dökümü geri yükleyin.

Sonra hala pg_resetxlogbaşlatamıyorsanız, resetxlog'dan sonra başlangıç ​​girişiminin güncellenmiş bir günlüğünü gönderin. Pg'yi aşağıdakilerle bağımsız modda başlatmanız gerekebilir:

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

Bu işe yararsa, bir backend>komut istemi verirseniz , son "postgres" i bağlanmak istediğiniz DB'nin adıyla değiştirdikten sonra tekrar deneyin. Sen muktedir olmalıdır SELECT, COPYtablolardan veri, vb

O takdirde değil sen mantıklı yeterince onlara sahip olmak beri - işi, o zaman muhtemelen yedeklerden geri yükleme zamanı, bir backendden başlayamaz yani. Bunu okuyan başka biri aynı konumdaysa, veritabanınızdan veri kurtarabileceklerini görmek için deneyimli bir PostgreSQL danışmanına başvurun . Zaman ve uzmanlık için ödeme yapmaya hazır olun.

Dosya sisteminiz muhtemelen zarar görmüş

PostgreSQL kurulumundaki hasarın şiddeti, tüm dosya sisteminizin muhtemelen hasar gördüğünü gösterir. Tüm sistemi bir yedekten geri yüklemeyi veya yeniden yüklemeyi düşünebilirsiniz.

Bu dosya sistemine güvenmem fsckya da hayır fsck.

Sürücünüzü AKILLI test edin

Ayrıca smartmontools SMARTile sabit diskinizde bir kontrol yapmanızı smartctlöneririz; /dev/hdaolacağını varsayarsak smartctl -d ata -a /dev/sda | less. Başarısız bir sağlık testi, uncorrectable_sectorsyüksek okuma hatası oranı, 2 veya 3'ten fazla yeniden tahsis edilmiş_sector_count veya sıfır olmayan bir current_pending_sector arayın. HDD'nizde smartctl -d ata -t long /dev/sdatahribatsız bir otomatik test yürütmek için çalıştırın; sistemin normal işleyişini kesintiye uğratmaz. Tahmini süre geçtikten sonra smartctl -d ata /dev/sdatekrar çalıştırın ve geçip geçmediğini görmek için kendi kendine test günlüğüne bakın.

Mükemmel olandan daha az görünen bir şey varsa, sürücüyü değiştirin.

Gelecekte, smartdsürücü arızalarına ilişkin erken uyarı için bu testi otomatikleştirmeyi düşünün .

(Bu yayındaki içerik, sorudaki güncellemeler nedeniyle eskiydi. Benzer bir sorunu gideriyorsanız, bu yanıtın düzenleme geçmişine bakın).