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:
| Rol | Yetki | Kim kullanır |
|---|---|---|
siteNNN_okur | Yalnızca okuma (SELECT) | Yayın süreci ve panelin okuma tarafı |
siteNNN_yazar | Okuma + 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ğinsite007_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/yazarrolleri 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şen | Nerede | Ne tutar / ne yapar |
|---|---|---|
Site veritabanı siteNNN | İçerik kümesi, 5433 portu | O 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 |
pgbouncer | 6432 portu | Yayının okuma köprüsü; isteği doğru veritabanına yönlendirir |
siteler.json | Eş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