Home/Hata Teşhis Kütüphanesi/postgresql-terminating-connection-administrator-command

PostgreSQL

PostgreSQL 14–18Bağlantı & Oturum

8 dk okuma

FATAL: terminating connection due to administrator command (57P01)

PostgreSQL "terminating connection due to administrator command" — Bağlantıyı Kim Kesti?

57P01 hatasının gerçek kaynakları: pg_terminate_backend, sunucu yeniden başlatma, bulut failover'ı ve pooler. Hangi log satırının hangi olayı gösterdiği.

İ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 Linux / Docker 29.7) | Tarihsel: PostgreSQL 14.10, 15.6, 16.4

Gerekli YetkiSUPERUSER veya pg_read_all_stats / pg_signal_backend (log_disconnections için ALTER SYSTEM)

Risk Seviyesi

MediumKörlemesine yapılan retry istekleri idempotent olmayan transactionlarda mükerrer işleme yol açabilir

Beklenen ÇıktıLog satırlarında PID termination sebebi ve disconnect süresinin net tespiti; 57P01 vs 57P02/57P05 ayrımı

Geri Dönüş (Rollback) Planı:log_disconnections ayarını geri alma ve PgBouncer server_idle_timeout yapılandırmasını normalize etme

PostgreSQL Docs: Error Codes & Session Signals

İ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: terminating connection due to administrator command

Uygulama tarafında (Node.js pg, Go pgx, Python psycopg2, JDBC) genellikle şu hata fırlatılır:

plaintext

server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

SQLSTATE hata kodu: 57P01 (admin_shutdown).

ÖNEMLİ

Kritik Yanılgı: "Administrator Command" Bir DBA Komutu Değildir! Mesajdaki *"administrator command"* ifadesi neredeyse her zaman yanlış okunur. Bir veritabanı yöneticisinin elle pg_terminate_backend() çalıştırdığı anlamına gelmez. PostgreSQL bu metni, bir backend sürecine işletim sistemi düzeyinde bir SIGTERM (signal 15) ulaştığında yazar. Sinyali kimin veya hangi servisin gönderdiği hata metninde yer almaz — bu yüzden teşhis, hata mesajını değil PostgreSQL engine log'unun komşu satırlarını okumakla başlar.

▸1. Önce Hangi Olay Olduğunu Ayırın

Aynı 57 sınıfı altındaki dört farklı mesaj, dört tamamen farklı olayı temsil eder. Bunları birbirine karıştırmak en sık yapılan teşhis hatasıdır:

Log Metni	Gerçekte Ne Oldu?	SQLSTATE
`terminating connection due to administrator command`	Sürece SIGTERM geldi: `pg_terminate_backend`, `pg_ctl stop/restart`, systemd servis yöneticisi, bulut failover'ı	`57P01`
`terminating connection because of crash of another server process`	Başka bir backend çöktü (Segmentation Fault vb.), postmaster paylaşımlı belleği korumak için tüm süreçleri anında düşürdü	`57P02`
`terminating connection due to idle-session timeout`	`idle_session_timeout` aşıldı (PostgreSQL 14+)	`57P05`
`terminating connection due to idle-in-transaction timeout`	İşlem içinde açık bekleyen oturum sınırı (`idle_in_transaction_session_timeout`) aşıldı	`25P03`

Eğer 57P01 görüyorsanız, neden bir süre aşımı (timeout) değildir: birinin veya bir dış orkestratörün o oturuma açıkça son verdiği kesindir. Soru artık "neden koptu" değil, "bağlantıyı kim sonlandırdı" sorusudur.

▸2. Adım Adım Teşhis Akışı

Adım 1: Log'da Eşleşen Kapanış Satırını ve Son Sorguyu Bulun

PostgreSQL, bir backend SIGTERM aldığında olayı ayrıntılandırır:

plaintext

LOG:  server process (PID 48213) was terminated by signal 15: Terminated
DETAIL:  Failed process was running: SELECT * FROM rapor_aylik WHERE ay = '2026-09'

DETAIL satırı altın değerindedir: kopan oturumun çalıştırmakta olduğu son SQL ifadesini verir. Uzun süren bir analitik sorgu görüyorsanız, bir izleme aracı (watchdog), PgBouncer havuz zaman aşımı veya cron scripti bu sorguyu kasten öldürmüş olabilir.

Adım 2: Tüm Oturumlar Aynı Anda mı Düştü, Birkaçı mı?

Canlı sunucuda oturum başlangıç sürelerini inceleyin:

sql

SELECT count(*) FILTER (WHERE state = 'active') AS aktif,
       count(*) FILTER (WHERE state = 'idle')   AS bos,
       min(backend_start) AS en_eski,
       max(backend_start) AS en_yeni
FROM pg_stat_activity
WHERE backend_type = 'client backend';

•Tüm oturumlar aynı anda düştüyse: Sunucu yeniden başlatılmıştır (restart/crash-recovery). PostgreSQL logunda received fast shutdown request veya database system is shut down satırlarını arayın.
•Sadece birkaç oturum düştüyse: Sunucu ayaktadır ve SIGTERM hedefe yönelik olarak gönderilmiştir.

Adım 3: Sunucu Ayaktaysa Bağlantı Kesilmelerini Görünür Kılın

PostgreSQL, pg_terminate_backend çağrısını varsayılan olarak loglamaz. Gelecek olaylarda çağıranı ve süreyi yakalamak için şu ayarı açın:

sql

ALTER SYSTEM SET log_disconnections = on;
SELECT pg_reload_conf();

Bu ayar, her oturum sonlandığında oturumun süresini, istemci IP'sini ve oturum kapatma nedenini log dosyasına kaydeder.

Adım 4: En Sık Üç Kaynağı Sırayla Eleyin

1Yönetimli Bulut Servisleri (AWS RDS / Aurora / GCP Cloud SQL / Azure Database): Sağlayıcının otomatik minor versiyon güncellemesi, depolama alanı genişletme failover'ı veya Multi-AZ bakım geçişi tam olarak bu 57P01 mesajını üretir. Sağlayıcınızın konsolundaki Olay Geçmişini (Event Log) mutlaka kontrol edin.
2Bağlantı Havuzlayıcılar (PgBouncer / Odyssey): PgBouncer gibi bir katman arka uç bağlantılarını kendi politikasıyla döndürür. Havuzun server_idle_timeout değeri sunucunun bekleme süresinden kısaysa, havuz "sağlıklı" sandığı ölü bir bağlantıyı uygulamaya teslim eder ve hata uygulama tarafında patlar.
3Otomatik İzleme ve Uzun Sorgu Öldürücüler: Uygulama bağlantı dizgilerine mutlaka application_name ekleyin:

postgresql://user:pass@host:5432/db?application_name=siparis_api_v2 Bu sayede pg_stat_activity üzerinden kimin kimi sonlandırdığı netleşir.

▸3. Çözüm ve Dayanıklılık Standartları

1. Uygulama Katmanında Doğru Retry Sınıflandırması

57P01 geçici bir bağlantı kopmasıdır; ancak körlemesine retry yapmak tehlikelidir:

plaintext

57P01, 57P02, 08006  → Bağlantı koptu: Yalnızca IDEMPOTENT sorgularda (SELECT vb.) yeni bağlantıyla yeniden dene.
57P03                → Sunucu başlatılıyor (startup): Üstel geri çekilme (exponential backoff) ile bekle.
25P03, 57P05         → Politika zaman aşımı: Retry yapma; işlem mantığını optimize et.

UYARI

Bir INSERT veya UPDATE işlemi sırasında bağlantı 57P01 ile koptuğunda, işlemin sunucuda COMMIT edilip edilmediği istemci tarafından bilinemez. İstemci tarafında tekil bir işlem kimliği (Idempotency Key) yoksa retry mükerrer fatura/sipariş oluşturabilir!

2. Bağlantı Havuzunda "Ölü Bağlantı" Doğrulaması

Havuzdan ödünç alınan (borrow) bağlantının ayakta olup olmadığını kontrol edin:

sql

SELECT 1;

HikariCP veya PgBouncer kullanıyorsanız, maxLifetime değerini güvenlik duvarının ve PostgreSQL'in boşta kalma eşiklerinden en az 30 saniye daha kısa ayarlayın. Altın kural: Bağlantıyı sunucu veya güvenlik duvarı değil, her zaman havuzlayıcı emekliye ayırmalıdır.

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

•PostgreSQL Connection Refused (H-07) — Ağ ve port erişim sorunları
•PostgreSQL Conflict with Recovery (H-11) — Standby replikasyon sorgu çakışmaları
•PostgreSQL Too Many Clients Already (H-01) — Bağlantı sınırı tükenmesi
•PostgreSQL Hub — PostgreSQL mimari ve runbook rehberleri

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 "terminating connection due to administrator command" — Bağlantıyı Kim Kesti?

Operasyonel Doğrulama & Güvenilirlik Standardı

▸Belirti

▸1. Önce Hangi Olay Olduğunu Ayırın

▸2. Adım Adım Teşhis Akışı

Adım 1: Log'da Eşleşen Kapanış Satırını ve Son Sorguyu Bulun

Adım 2: Tüm Oturumlar Aynı Anda mı Düştü, Birkaçı mı?

Adım 3: Sunucu Ayaktaysa Bağlantı Kesilmelerini Görünür Kılın

Adım 4: En Sık Üç Kaynağı Sırayla Eleyin

▸3. Çözüm ve Dayanıklılık Standartları

1. Uygulama Katmanında Doğru Retry Sınıflandırması

2. Bağlantı Havuzunda "Ölü Bağlantı" Doğrulaması

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

Diğer Veritabanı Hata Teşhisleri

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

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

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