dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
dbaguide.com
Home/Hata Teşhis Kütüphanesi/postgresql-database-system-is-starting-up
Hatalara Dön
PostgreSQL
PostgreSQL 14–18Kurtarma & Başlatma
8 dk okuma
FATAL: the database system is starting up / in recovery mode (SQLSTATE 57P03)

PostgreSQL "the database system is starting up" — Bekleyeyim mi, Müdahale mi Edeyim?

57P03 hatasında normal açılış ile sıkışmış kurtarmayı ayırma, pg_isready çıkış kodları, pg_controldata ve WAL arşiv beklemesi.

İnceleyen:Principal Database Reliability Architect
Test Edilen Sürümler: PostgreSQL 18.6 & 17.11 (Alpine Linux / Docker 29.7) | Tarihsel: PostgreSQL 14, 15, 16

Operasyonel Doğrulama & Güvenilirlik Standardı

Son Teknik İnceleme: 30 Ekim 2026
Test Edilen SürümlerPostgreSQL 18.6 & 17.11 (Alpine / Docker 29.7) | Tarihsel: 14.10, 15.6, 16.4
Gerekli Yetkiİşletim sistemi erişimi (pg_isready, pg_controldata ve postgresql.log okumak için)
Risk Seviyesi
HighCrash recovery devam ederken sunucuyu kill -9 ile zorla kapatmak veri bozulmasına ve tutarsızlığa yol açar
Beklenen Çıktıpg_isready çıkış kodları (0, 1, 2) ve redo starts/done log analiziyle normal açılış ile sıkışmış kurtarmanın ayrılması
Geri Dönüş (Rollback) Planı:WAL redo ilerlemesini izlemek; döngü varsa restore_command ve disk alanını kontrol etmek
PostgreSQL Docs: pg_isready & Server Startup
İlk 60 Saniye Teşhis Protokolü:

Hata mesajı semptomdur, kök neden değildir. Sunucuyu yeniden başlatmadan veya rastgele ayar değiştirmeden önce aşağıdaki "Nedeni ayırt eden tek sorgu"yu çalıştırarak gerçek senaryoyu netleştirin.

▸Belirti

plaintext
FATAL: the database system is starting up FATAL: the database system is in recovery mode FATAL: the database system is shutting down FATAL: the database system is not yet accepting connections FATAL: the database system is in an inconsistent state

Hepsi PostgreSQL SQLSTATE kodu olan `57P03` (cannot_connect_now) altında toplanır.

Bu hata grubu bir DBA'ye veya SRE mühendisine tek bir kritik karar verdirir: "Beklemeli miyim, yoksa derhal müdahale mi etmeliyim?"

Bu sayfanın ana amacı, hislerle veya panikle hareket etmek yerine ölçülebilir göstergelerle bu kararı verdirmektir.

▸Üç Temel Senaryo

  1. 1Normal Başlatma: Sunucu yeni başlatılmıştır; paylaşımlı bellek tahsis edilmiş, eklentiler yüklenmektedir. Birkaç saniye içinde kendiliğinden bağlantı kabul edecektir. Müdahale etmeyin, bekleyin.
  2. 2Çökme Sonrası Kurtarma (Crash Recovery): Sunucu beklenmedik bir şekilde (elektrik kesintisi, kernel panik, kill -9) kapanmıştır. PostgreSQL veri bütünlüğünü garanti etmek için son kontrol noktasından (checkpoint) bu yana üretilen tüm WAL kayıtlarını yeniden oynatmaktadır (REDO). İşlem süresi bekleyen WAL boyutuna bağlı olarak 30 saniye de sürebilir, 20 dakika da sürebilir.
  3. 3Sıkışmış Kurtarma (Stuck / Crash Loop): Kurtarma süreci ilerlememektedir; döngüye girmiş veya eksik bir WAL dosyasını arşivden çekmeye çalışırken donmuştur. Derhal müdahale gerekir.

▸Ayırt Etme: `pg_isready` Çıkış Kodları

PostgreSQL bu durumu otomasyonla ayırt edebilmeniz için resmi `pg_isready` aracını sunar:

bash
pg_isready -h localhost -p 5432 -d app echo $?

Çıkış kodlarının kesin anlamları:

  • •0: Sunucu tamamen hazır, bağlantı kabul ediyor.
  • •1: Sunucu ayakta ve çalışıyor, ancak henüz bağlantı kabul etmiyor (başlangıç veya kurtarma aşamasında) → Bu sayfanın konusu (57P03).
  • •2: Sunucudan hiçbir yanıt yok (Postmaster süreci hiç çalışmıyor veya ağ kapalı) → H-07 rehberinin konusu.
  • •3: Geçersiz parametre veya yapılandırma hatası.

Eğer çıkış kodu 1 ise PostgreSQL canlıdır; panikle süreci öldürmeyin.

▸Kurtarma İlerliyor mu, Sıkışmış mı?

Cevap PostgreSQL log satırlarındadır:

plaintext
LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/1A2B3C48 LOG: redo done at 0/2F9D11A0 LOG: database system is ready to accept connections
  • •İlerliyor: redo starts at satırından sonra LSN adresleri akıyorsa ve diske yazma işlemi (I/O) devam ediyorsa kurtarma sağlıklıdır. Sabırla bekleyin.
  • •Döngüde (Crash Loop): Aynı redo starts at satırı her birkaç dakikada bir yeniden başlıyorsa, veritabanı kurtarmayı tamamlarken bir hata ile tekrar çökmektedir. Genellikle disk doluluğu veya donanımsal sayfa bozulması vardır.
  • •Arşiv Beklemesi: restore_command bir WAL segmentini çekemediği için sonsuz döngüde bekliyorsa logda could not open file ... satırları akar.

Küme Durumunu pg_controldata ile Okuma

Sunucuya psql ile bağlanamadığınızda diskteki kontrol dosyasını okuyun:

bash
pg_controldata "$PGDATA" | grep -E 'cluster state|Latest checkpoint|REDO'

Database cluster state alanı:

  • •in crash recovery: Otomatik WAL oynatımı sürüyor.
  • •in archive recovery: Standby replika veya PITR kurtarma komutunu bekliyor.
  • •in production: Küme normal çalışmaya hazır.

▸Adım Adım Müdahale Protokolü

DİKKAT / TEHLİKE
Crash Recovery Sırasında Asla `kill -9` Yapmayın! Kurtarma devam ederken PostgreSQL sürecini zorla sonlandırmak veri sayfalarında fiziksel tutarsızlıklara ve kalıcı veri kaybına yol açar. Süreç yanıt vermiyorsa yalnızca standart SIGTERM (kill -15) veya pg_ctl stop -m fast deneyin.

1. Arşiv Komutu Sıkışmasını Çözme

Eğer sunucu PITR veya standby terfi sırasında eksik bir WAL segmenti için bekliyorsa, postgresql.conf (veya recovery.signal) içinde:

ini
recovery_target = 'immediate'

Tanımlayarak kurtarmanın güvenli en son noktada tamamlanıp kümenin açılmasını sağlayın.

2. Bağlantı Havuzunu Kademeli Açın

PostgreSQL ready to accept connections dediği anda, arkada bekleyen 500 uygulama bağlantısı aynı anda veritabanına saldırırsa sunucu yeniden kilitlenebilir. Bağlantı havuzunu (PgBouncer) önce sınırlı bağlantıyla açın, buffer pool ısındıktan sonra trafiği serbest bırakın.

▸İlgili Hata Rehberleri & Hub Bağlantıları

Diğer Veritabanı Hata Teşhisleri

Kriz anında başvurabileceğiniz diğer doğrulanmış hata rehberleri.

Tüm Hatalar (50)
POSTGRESQL7 dk

PostgreSQL Bağlantı Tükenmesi ve too many clients Teşhisi

FATAL: sorry, too many clients already ve remaining connection slots hatalarının üç temel kök nedeni, yetki sınırlarıyla salt okunur pg_stat_activity teşhisi ve kalıcı iki katmanlı havuzlama çözümü.

POSTGRESQL4 dk

PostgreSQL password authentication failed Hatası: Neden ve Çözüm

psql password authentication failed hatasının dört nedeni: yanlış şifre, md5/SCRAM uyuşmazlığı, pg_hba.conf sırası ve yanlış cluster. Adım adım teşhis.

POSTGRESQL4 dk

PostgreSQL connection refused: 8 Adımda Kesin Teşhis

Connection refused, timeout ve "no pg_hba.conf entry" arasındaki fark; listen_addresses, port, firewall ve Docker port yayınlama kontrolleri.