Dokümantasyon
KEYDAL

Veri Topolojisi ve Site İzolasyonu

Her sitenin kendi veritabanında nasıl yalıtıldığını, panelin yazıp yayının okuduğu tek doğruluk kaynağını ve pgbouncer köprüsünü anlatır.

Son güncelleme: 5 Eylül 2026

Genel bakış

Her KEYDAL sitesi verisini kendi ayrı veritabanında tutar. Sizin haberleriniz, kadronuz, okur kayıtlarınız ve sayaçlarınız başka hiçbir müşterinin verisiyle aynı tabloda durmaz. Bu sayfa, verinizin fiziksel olarak nerede durduğunu, panelde yaptığınız değişikliğin yayına nasıl ulaştığını ve sitelerin birbirinden nasıl yalıtıldığını anlatır.

İki cümlelik özet: Siteniz için tek bir veritabanı açılır; panel o veritabanına yazar, ziyaretçiye sayfayı üreten yayın süreci aynı veritabanından okur. Araya konan bağlantı köprüsü dışında ikisi tam olarak aynı yeri gösterir — yani gördüğünüz önizleme ile yayındaki sayfa aynı kaynaktan gelir.

Her sitenin kendi veritabanı

Yeni bir site açıldığında sistem, içerik kümesindeki (PostgreSQL, 5433 portu) o siteye özel bir veritabanı oluşturur. Veritabanları sırayla adlandırılır: site001, site002, site003 ve devamı. Bir siteye ait bütün içerik yalnızca o veritabanının içindedir.

Aynı anda iki rol (kullanıcı) üretilir ve yalnızca o veritabanına yetkilendirilir:

RolYetkiKim kullanır
siteNNN_okurYalnızca okuma (SELECT)Yayın süreci ve panelin okuma tarafı
siteNNN_yazarOkuma + yazma (INSERT/UPDATE/DELETE)Panelin yazma ucu

Okuma rolü hiçbir şey değiştiremez; yalnızca veriyi okuyabilir. Sayfayı ziyaretçiye üreten süreç bu okuma rolüyle bağlanır, bu yüzden yayın tarafında kazara bir yazma bile mümkün değildir. İçeriği değiştiren tek yol paneldir ve panel bunu ayrı yazma rolüyle yapar.

Not: Rol adlarındaki NNN, sitenizin veritabanı numarasıdır (örneğin site007_okur). Bu adlar iç altyapıya aittir; panelde görünmez.

Panel yazar, yayın okur: tek doğruluk kaynağı

Bir haberi panelden kaydettiğinizde değişiklik doğrudan sitenizin veritabanına yazılır. Ziyaretçi siteyi açtığında sayfayı üreten süreç aynı veritabanından okur. Arada içeriği kopyalayan, eşitleyen ya da geciktiren ikinci bir kopya yoktur. Bu yüzden panelde yaptığınız değişiklik yayında da tek doğruluk kaynağından görünür.

Bunun pratik sonucu: “panelde başka, sitede başka” durumu yapısal olarak oluşmaz. Panel ile yayın farklı roller kullanır ama tek bir veritabanını paylaşır.

pgbouncer köprüsü

Sayfayı üreten süreç, güvenlik gereği veritabanı sunucusuna doğrudan bağlanamaz. Bunun yerine pgbouncer adındaki bağlantı havuzlayıcısına (6432 portu) bağlanır; pgbouncer isteği tam eşleşmeyle sitenizin kendi veritabanına yönlendirir. Yani yayın süreci pgbouncer/siteNNN üzerinden bağlanır, arka tarafta bu 5433 portundaki siteNNN veritabanına gider — panelin yazdığı veritabanının aynısı.

Bu köprü iki işe yarar:

  • Bağlantı havuzlama: Çok sayıda eşzamanlı ziyaretçi isteğini az sayıda veritabanı bağlantısıyla karşılar; her istek yeni bağlantı açmaz.
  • Yalıtım katmanı: Yayın süreci veritabanı sunucusunun tamamını değil, yalnızca kendi havuzunu görür. Yanlış bir veritabanına bağlanma yolu açık bırakılmaz.

Sitenizin verisi diğerlerinden nasıl ayrılır

Yalıtım tek bir önleme değil, üst üste binen birkaç katmana dayanır:

  • Ayrı veritabanı. Her sitenin verisi kendi veritabanındadır. Bir siteden diğerinin verisine SQL ile geçmek mümkün değildir; farklı veritabanları arasında sorgu çalıştırılamaz.
  • Ayrı roller, dar yetki. Her siteye özel okur/yazar rolleri yalnızca o sitenin veritabanına yetkilidir. Bir sitenin kimliğiyle başka bir sitenin verisine erişilemez.
  • Tekillik kısıtı. Eşleme defterinde, iki farklı sitenin aynı veritabanına işaret etmesini engelleyen bir benzersizlik kısıtı vardır (sunucu, port, veritabani üçlüsü benzersizdir). Bu, bir yapılandırma hatasının bile iki kiracıyı aynı veritabanına bağlamasını önler.
  • Türetme yok, açık eşleme. Sistem “site-007 → site007” gibi bir kural türetmez; hangi sitenin hangi veritabanına gittiği açık bir eşleme kütüğünde (siteler.json) yazılıdır. Türeten bir kural, geçerli görünüp yanlış veritabanını gösterebilirdi; bu risk tasarımdan çıkarılmıştır.
  • Yayın düğümü eşleme kaynağını göremez. Sayfayı üreten düğüm, tüm filonun bağlantı defterine erişmez; yalnızca kendi ihtiyacı olan eşlemenin izdüşümünü okur. Böylece bir web açığı, “sayfa bozuldu”nun ötesine geçip filonun bağlantı bilgilerine ulaşamaz.

Bir müşteri ayrıldığında teslim edilen ya da silinen şey de tam olarak o sitenin veritabanıdır — başka hiçbir müşterinin verisi o veri setinde bulunmaz.

Site başka sunucuya taşınırsa

Eşlemede her sitenin veritabanı adının yanında bir kapı (sunucu adresi ve port) bilgisi de tutulur. Bir site ileride başka bir sunucuya alınırsa yalnızca bu kapı değeri güncellenir; panel ve yayın tarafı yeni adresi eşleme kütüğünden çözer.

Eşleme ve kimlik dosyaları değişiklik zamanına göre sıcak okunur: yeni bir site eklendiğinde ya da bir site taşındığında servisleri yeniden başlatmak gerekmez, değişiklik kendiliğinden devreye girer.

Not: Site taşıma işlemi operatör tarafından yürütülen bir altyapı işlemidir; müşteri panelinden yapılan bir ayar değildir.

Referans

BileşenNeredeNe tutar / ne yapar
Site veritabanı siteNNNİçerik kümesi, 5433 portuO sitenin tüm içeriği, kadrosu, okur ve sayaç verisi
siteNNN_okur rolüAynı veritabanıYalnızca okuma; yayın ve panel okuma tarafı
siteNNN_yazar rolüAynı veritabanıOkuma + yazma; panelin yazma ucu
pgbouncer6432 portuYayının okuma köprüsü; isteği doğru veritabanına yönlendirir
siteler.jsonEşleme kütüğüSite kodu → veritabanı ve kapı eşlemesi

İlgili konular

  • Veritabanı yedekleme ve saklama süreleri
  • Yayın performansı ve önbellekleme
  • Panel rolleri ve yetki yönetimi