PostgreSQL’i Okumak Değil, Anlamak – Config Dosyaları – postgresql.conf – Bölüm 1
Öncelikle merhabalar , sqlekibi.com’a hoş geldin.
Bu serimizde PostgreSQL içerisindeki hayati öneme sahip CONF dosyalarını önce temel inşa edip ardından detaya inecek şekilde kafanda netleştirme hedefiyle klavye başına geçmiş bulunuyorum.
3 büyük config dosyasını tek bir makalede ele alıp yüzeysel olarak geçmek yerine her bir config dosyasının içindeki kritik noktaları ayrı ayrı bölümler halinde ele alacağım.
Amacım içi boş ve sıkıcı bir yazı okuyarak vakit kaybetmen değil , bir meslektaşım olarak senin hayatına pozitif anlamda dokunabilmek olacak.
O halde lafı daha fazla uzatmadan konuma giriş yapıyorum.
postgresql.conf: Config Dosyaları Ne Anlama Gelir ve Neden Bu Kadar Kritiktir?
Bu yazı biraz alıştığınız PostgreSQL yazılarından farklı olacak. Çünkü ben burada “şu parametre şudur, bu parametre budur” diye kuru kuru anlatmak istemiyorum. Aksine, zaman içinde şunu fark ettim :
PostgreSQL’de sorun yaşayan, performans problemi yaşayan ya da “ben bunu değiştirdim ama bir şey olmadı” diyen insanların büyük kısmı aslında config dosyalarını ezberlemiş ama mantığını hiç oturtmamış oluyor.
O yüzden bu seriye başlarken amacım çok net:
PostgreSQL’in config dosyalarını okumayı değil, gerçekten anlamayı sağlamak.
Bu seri boyunca üç ana config dosyasını ele alacağız:
- postgresql.conf → Sunucunun beyni
- pg_hba.conf → Güvenliğin kapısı
- pg_ident.conf → Kimlik eşleştirme katmanı
En başında da söylediğim gibi kuru kuru alışılmış bir anlatım görmeyeceksiniz. Bu yüzden daha da derine inip hangi ayar restart ister, hangisi reload ile devreye girer, hangisi ise hiçbir şey yapmadan anında etkili olur… Bunları net net ayıracağım. Çünkü gerçek hayatta PostgreSQL yöneten biri için bu farklar teorik değil, doğrudan üretim riski demek.
PostgreSQL Config Dosyaları Neden Bu Kadar Hayati?
PostgreSQL’i bir bina gibi düşünürsek, config dosyaları bu binanın statik hesabı gibidir. Dışarıdan bakınca her şey ayakta duruyor gibi görünür ama içeride yanlış bir kolon varsa, o bina ilk sarsıntıda çöker.
postgresql.conf özelinde konuşursak , bu dosya olmadan PostgreSQL ayağa kalkamaz. Porttan dinleyeceği adresi, kaç bağlantıya izin vereceğini, belleği nasıl kullanacağını, logları nereye yazacağını, WAL mekanizmasını nasıl yöneteceğini… Hepsini buradan öğrenir.
Bu yüzden seriye bilinçli olarak postgresql.conf ile başlıyorum. Çünkü diğer iki config dosyasının (pg_hba ve pg_ident) varlığı ve yeri bile aslında buradan belirleniyor.
PostgreSQL Config Dosyaları Nasıl Okunur ?
Bu noktada çok kritik bir detayı en baştan söylemem gerekiyor:
PostgreSQL config dosyalarında yorum satırını geri açmak, varsayılana dönmek anlamına gelmez.
Dosyanın en başında çok net bir uyarı var:
Bir parametreyi yoruma almak, onu otomatik olarak default değere döndürmez. Eğer daha önce farklı bir değer aldıysa, reload ya da restart olmadan PostgreSQL o eski değeri kullanmaya devam eder.
Ayrıca bu dosya:
- Sunucu ilk açılırken okunur.
- Çalışırken SIGHUP, pg_ctl reload ya da SELECT pg_reload_conf() ile yeniden yüklenebilir.
- Ama bazı parametreler için kesin restart şarttır.
Bu ayrımı kafaya koymadan config dosyası kurcalamak, özellikle canlı sistemlerde, açık söyleyeyim riskli iştir.
Biz DBA’ler olarak bu tür gerekmeyen risklerin altına girmek yerine , araştırıp öğrenip bilgi sahibi olarak işlemlerimizi yapmayı tercih ederiz değil mi 😊
O halde konumuza temel hatlarıyla giriş yaptığımıza göre yavaş yavaş ilk config dosyamız olan postgresql.conf içerisindeki bölümlere sıra sıra giriş yapalım.
1- FILE LOCATIONS – PostgreSQL Nerede Yaşıyor?
İlk bölüm olan FILE LOCATIONS, PostgreSQL’in dosya sistemindeki adres defteridir.
Burada PostgreSQL’e şunu söylersin:
- Verilerim nerede?
- Kimlik doğrulama dosyalarım nerede?
- Gerekirse PID dosyasını nereye yazayım?
Örneğin :
- data_directory
PostgreSQL’in tüm veri dizininin nerede olduğunu söyler. Bunu değiştirmek demek, PostgreSQL’e “evini taşı” demek gibidir. O yüzden restart şarttır. Zaten fark ettiysen bunları kolayca fark etmemiz için parantez içinde “change requires restart” diye eklemişler. - hba_file
Serinin ilerleyen bölümlerinde uzun uzun anlatacağım pg_hba.conf dosyasının nerede olduğunu buradan belirlersin. PostgreSQL bağlantı güvenliğini buradan okur. - ident_file
Aynı şekilde inceleyeceğimiz diğer bir conf dosyası olan pg_ident.conf dosyasının konumunu da burada tanımlarız.
Özetlemek gerekirse şu anda içerisinde bulunduğumuz postgresql.conf dosyası veri tabanımızın beyni diyebiliriz.
Bu bölümün ortak özelliği şu:
Buradaki ayarların tamamı PostgreSQL’in temel mimarisini ilgilendirir ve bu yüzden neredeyse hepsi restart gerektirir.
2- CONNECTIONS AND AUTHENTICATION – PostgreSQL Dış Dünya ile Nasıl Konuşur?
PostgreSQL tarafında yaşanan problemlerin çok büyük bir kısmı, sanılanın aksine ne indeksle ne de sorguyla başlar. Genelde olay şu cümleyle gelir:
“Bağlanamıyoruz.”
“Bağlantılar doldu.”
“Sunucuya erişim var ama database cevap vermiyor.”
İşte bu noktada, doğrudan CONNECTIONS AND AUTHENTICATION bölümüne bakılır. Çünkü burası PostgreSQL’in dış dünya ile kurduğu ilişkinin tamamını belirler.
Kim bağlanabilir, nereden bağlanabilir, kaç kişi aynı anda bağlanabilir ve bu bağlantılar ne kadar sağlıklıdır… Hepsi burada şekillenir.
a) listen_addresses – PostgreSQL Kimi Dinliyor?
Bu parametreyi doğru anlamadan PostgreSQL güvenliği konuşmak mümkün değil.
listen_addresses = ‘*’
Varsayılan olarak PostgreSQL sadece localhost üzerinden bağlantı kabul eder. Yani aynı makinedeki uygulamalar bağlanabilir ama dışarıdan kimse ulaşamaz.'*' yaptığın anda ise PostgreSQL’e şunu söylersin :
“Ağ kartımda tanımlı tüm IP adreslerini dinle.”
Bu ayar:
- Uygulama sunucularının bağlanabilmesi için zorunludur
- Ama tek başına çok tehlikelidir
Çünkü:
listen_addressessadece “dinleme”yi açar- Asıl güvenlik pg_hba.conf tarafındadır
Yani burada kapıyı açarsın, ama içeri kimin gireceğine henüz karar verilmemiştir.
Kritik not:
Bu parametre restart gerektirir. Çalışan bir PostgreSQL’e reload ile yeni bir IP dinletmeye başlayamazsın.
b) port – PostgreSQL Nereden Konuşuyor ?
port = 5432
Bu ayar basit gibi görünür ama üretimde değiştirildiğinde etkisi büyüktür.
- PostgreSQL’in TCP/IP üzerinden hangi porttan hizmet verdiğini belirler
- Aynı makinede birden fazla PostgreSQL instance çalıştırıyorsan hayati hale gelir
Port değiştiğinde :
- PostgreSQL restart ister
- Tüm uygulama connection string’leri güncellenmelidir
- Firewall ve load balancer tarafı kontrol edilmelidir
Bu yüzden port değişikliği “küçük bir ayar” değil, koordinasyon gerektiren bir operasyondur.
c) max_connections – Aynı Anda Kaç Kişi İçeri Alınır?
max_connections = 100
Bu parametre PostgreSQL tarafında en sık yanlış kullanılan ayarlardan biridir.
Çünkü çoğu kişi şunu düşünür :
“Bağlantı yetmiyor, artır gitsin.”
Ama işin gerçeği şu :
Her PostgreSQL bağlantısı bellek tüketir. Ve bu bellek, çoğu zaman sandığından fazladır.
Bağlantı başına:
- Backend process
- Çeşitli buffer’lar
work_memihtimali oluşur.
Altın kural:max_connections artırıyorsan, connection pooling (PgBouncer gibi) düşünmeden bu işi yapma.
Bu ayar da restart gerektirir ve plansız artırıldığında:
- RAM yetmez
- Sistem swap’e düşer
- Performans çöker
d) reserved_connections & superuser_reserved_connections
“Sistem Kilitlendi Ama Ben Gireyim” Ayarları
Bu iki parametre genelde gözden kaçar ama kriz anlarında hayat kurtarır.
reserved_connections = 0
superuser_reserved_connections = 3
Mantık şu :
max_connectionsdolduğunda- Normal kullanıcılar artık bağlanamaz
- Ama superuser hala bağlanabilsin istersin
İşte bu ayarlar tam olarak bunu sağlar.
Özellikle :
- Canlı sistemlerde
- Yoğun trafik alan veritabanlarında
en azından birkaç bağlantının sadece DBA’ler için saklı olması ciddi avantajdır.
Bu ayarlar da restart gerektirir.
e) TCP Ayarları – Çoğu Zaman Dokunma, Bilmen Yeter
Bu ayarlar TCP seviyesinde bağlantıların ne kadar sürede “ölü” sayılacağını belirler.
Genel kural şudur:
- Eğer özel bir network problemi yoksa
- Load balancer / firewall tarafında özel gereksinim yoksa
👉 Dokunma.
Ama bil ki :
- Idle bağlantıların temizlenmemesi
- “Ghost connection” dediğimiz, aslında kopmuş ama PostgreSQL tarafında hala açık görünen bağlantılara yol açabilir
Bu ayarlar reload ile devreye girer.
f) Authentication Ayarları – Şifreleme Tarafı
password_encryption = scram-sha-256
Bu ayar PostgreSQL’de oluşturulan yeni kullanıcıların şifrelerinin hangi algoritmayla saklanacağını belirler.
Modern PostgreSQL dünyasında:
scram-sha-256→ olması gerekenmd5→ sadece legacy sistemler için
Önemli detay:
- Bu ayar mevcut kullanıcıların şifrelerini otomatik dönüştürmez
- Sadece bundan sonra oluşturulan ya da şifresi değiştirilen kullanıcıları etkiler
Reload yeterlidir.
authentication_timeout = 1min
Bağlanmaya çalışan bir client’ın, doğrulama sürecini tamamlaması için tanınan süredir.
Brute force veya yarım kalan bağlantılara karşı koruyucu bir ayardır.
g) SSL Ayarları – Üretimde “Opsiyonel” Değil
ssl = off
Geliştirme ortamında kapalı olabilir ama:
- Uzak sunucular
- Cloud ortamları
- İnternet üzerinden erişilen PostgreSQL’ler
için SSL olması gerekendir.
SSL açmak:
- Sertifika yönetimi
- Client tarafı ayarları
- Performans etkileri
gibi konuları da beraberinde getirir. O yüzden bunu “tek satır aç kapa” olarak görmemek gerekir.
SSL ayarlarının büyük bölümü restart gerektirir.
Burayı Özetleyecek Olursam
CONNECTIONS AND AUTHENTICATION bölümü sana şunu öğretir:
- PostgreSQL nereden dinliyor
- Kaç kişiyi aynı anda içeri alıyor
- Bağlantılar ne kadar sağlıklı
- Kimlik doğrulama hangi standartta
- Kriz anında sen içeri girebiliyor musun
Bu bölümü gerçekten anlayan biri:
- “Bağlanamıyoruz” denildiğinde panik yapmaz
- Sorunun PostgreSQL mi, network mü, uygulama mı olduğunu ayırabilir
Bir sonraki adımda artık:
- Memory
- Resource usage
- Ve yavaş yavaş performans tarafına
girmeye başlamak çok daha anlamlı hale gelir.
PostgreSQL’i Okumak Değil , Anlamak adlı serimizin ilk bölümünün sonuna gelmiş olduk.
Bu bölümde sağlam bir temel attın ve config dosyalarının önemini artık biliyorsun , sonraki bölümlerle kendini geliştirmeye devam edebilirsin.
Yazan : Nedim Akıl ( https://www.linkedin.com/in/ndmakl/ )