Bir HDD çökmesinden sonra PostgreSQL sunucusunun başlatılması FAILED STATE ile sonuçlanmıyor


10

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

Postgres günlüğü?
Milen A. Radev

@ MilenA.Radev Soruyu postgres günlüğü ile güncellediniz ..
ThinkingMonkey

pg_resetxloghiç iyi bir şey yapmadı, bu yüzden eğlenceli bölgeye giriyorsun. Çökmeden önce bu veritabanının yedeğini aldınız mı?
Craig Ringer

@CraigRinger Evet Yedeklemem var. Aslında bu sürüşten keyif alıyorum.
ThinkingMonkey

@ThinkingMonkey Harika! İyi yedekleri olan seçkin birkaç kişiden birisiniz. :-). Dürüst olmak gerekirse, DB'niz onarılabilir, ancak dosya sisteminizin bozulması önemli dosyaları yok ettiğinden, muhtemelen verilerinizi almak için biraz zaman harcamak için Pg'nin cesaretlerini bilen birine ihtiyacınız olacak. Hizmetlere buradan ulaşabilirsiniz: postgresql.org/support/professional_support. Belki pg_multixact/offsets/0000bu Pg için bazı kukla içerikle gelebilirsen ...
Craig Ringer

Yanıtlar:


15

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).


Soruya postgres günlüğü ekledim. Ben varsayılan ayarını değiştirmemişti, fsyncbu yüzden tahmin ediyorum, olarak ayarlandı on. HDD'deyim. Evet, HDD çöktü. Disk alanım tükenmedi. Hiçbir bellek hatası / aşırı ısınma / kablo / kerpiç üzerinden attı.
ThinkingMonkey

@ThinkingMonkey Ne tür bir "HDD çökmesi"? Dosyaları yeni bir sürücüye kopyalamak için sabit sürücüde veri kurtarma işlemi yapmak zorunda mıydınız? fsckDosya sistemi onarımını çalıştırmanız gerekiyor mu? Detaylar, lütfen. Kazanın hikayesini yaz.
Craig Ringer

HDD çökmesi fsckiçin bir kılavuz çalıştırıldı . Bununla birlikte gazilyon inotları vb. Onarılıyor. Bundan sonra sistem yeniden başlatıldı. Yukarıdaki soruları da güncelledik.
ThinkingMonkey

@ThinkingMonkey Tamam, cevap güncellendi. TL; DR: / var / lib / pgsql dosyasının tam dosya sistemi düzeyinde bir kopyasını oluşturun, ardından çalıştırınpg_resetxlog
Craig Ringer

teşekkürler .. kopyala & resetxlog üzerine. yakında sonuçlarla geri dönecek.
ThinkingMonkey
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.